Constant byteorder macros.

[Francois-Rene Rideau]

On Thu, Jan 20, 2000 at 12:59:49PM +0000, David Woodhouse wrote:
> hpa en transmeta.com said:
>> Given that gcc has a __builtin_constant_p(x), you ought to be able to
>> do:
> 
>> #define cpu_to_le16(x) ( __builtin_constant_p(x) ? \
>>	__constant_cpu_to_le16(x) : __cpu_to_le16(x) ) 
>
> I didn't really explore this avenue very deeply - I assumed that because
> it's been done with a separate __constant_x macro in the htonl() case,
> there was a problem with doing it in the way you suggest.

Such optimization as hpa en foo proposes is already done, at a lower level
(see include/linux/swab.h). However, the whole point of a __constant_FOO
macros is to stay independent from GCC proper (since __builtin_constant_p
is GNU C specific). If this is a goal (and I guess it is, since we do have
such interface in the htonl case), then indeed, new interfaces have to be
provided.

Hum. Ok, as byteorder janitor, I'm the one meant to do it. So, patch attached.
Use at your own risk: I've only compiled it on my i386 laptop, not even run it.
Applies to any recent 2.2.x; I never really tried a 2.3.x, but should do as
well. All bugs are mine (except for below issue).

Of course, it might take more than that to make (excerpts from) the kernel
compatible with other compilers; but at least, the patch provides a sensible
interface to do it in a clean way (as far as byteorder stuff is concerned).

NB: someone, somewhere, has put a cast to (long) in htonl, that I preserved;
but I think this is Wrong(tm), and if the htonl interface is broken, then it
is _it_ that should be fixed (if not already); our code should not reproduce
and propagate that bug. Of course, I am in no position to make that decision
myself; only a kernel maintainer who masters the compatibility issues may
take it. It looks like YABDTBLUKH: Yet Another Bug Due To Brain-damaged LIBC
Using Kernel Headers. Happily, this particular bug is rather unlikely to do
any damage, except burden our code with legacy work-arounds.

Regards,

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
You may have original good ideas, but it is no excuse
for not learning good ideas that are already common knowledge.
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: byteorder-2.2.14.patch.gz
Type: application/octet-stream
Size: 1757 bytes
Desc: no disponible
URL: <https://lists.srvr.mx/pipermail/ayuda/attachments/20000121/9c0abbf1/attachment.obj>