>>>Just went through the archives....
>>>
>>> I tried to recreate the compile-failure (was some time ago since
>>> it
>>> happened) when using min()/max() in a struct but it happily compiled it
>>> so (thankfully) you are correct, just need to use min()/max(). :)
>>>
>>> Richard Knutsson
>>>
>>>Do you mean to say that you were able to compile when the macros were used inside struct?
>>>Im still not able to get that to happen...
>>>
>>>I tried that change in linux-2.6/fs/lockd/mon.c
>>>
>>>static struct rpc_procinfo nsm_procedures[] = {
>>>[SM_MON] = {
>>> .p_proc = SM_MON,
>>> .p_encode = (kxdrproc_t) xdr_encode_mon,
>>> .p_decode = (kxdrproc_t) xdr_decode_stat_res,
>>> .p_bufsiz = max(SM_mon_sz, SM_monres_sz) << 2,
Will work since both SM_mon_sz and SM_monres_sz are compile-time
constants, not true?
[ ... snip ... ]
So...
The patch actually modifies the macro's last line in kernel.h
- _x < _y ? _x : _y; })
+ __min(_x, _y); })
But what I am unable to understand is why is the compiler unhappy with
* _x < _y ? _x : _y; })*
and happy with new macro been called internally *__min(_x,_y);*
Mehul