This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Merge status
- From: law at redhat dot com
- To: "Joseph S. Myers" <jsm at polyomino dot org dot uk>
- Cc: Andreas Jaeger <aj at suse dot de>, Ian Lance Taylor <ian at wasabisystems dot com>, Jason Merrill <jason at redhat dot com>, Diego Novillo <dnovillo at redhat dot com>, Paolo Bonzini <bonzini at gnu dot org>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 17 Mar 2004 07:33:37 -0700
- Subject: Re: [tree-ssa] Merge status
- Reply-to: law at redhat dot com
In message <Pine.LNX.email@example.com>, "Joseph
S. Myers" writes:
>On Wed, 17 Mar 2004, Andreas Jaeger wrote:
>> These two (and similar ones):
>> #define IXDR_GET_INT32(buf) ((int32_t)ntohl((uint32_t)*(buf)++))
>> #define IXDR_PUT_INT32(buf, v) (*(buf)++ = (int32_t)htonl((uint32_t)
>These don't seem to use lvalue casts (and presume that the buf argument
>points to integers of the right width so that they don't need to).
>IXDR_GET_LONG and IXDR_PUT_LONG use such casts, but I don't really see the
>need for them to do so; it looks like they are (apart from being obsolete)
>meant to have exactly the same interface as IXDR_GET_INT32 and
>IXDR_PUT_INT32, only return long if that differs from int32_t. In
>particular, all the uses of them in libc/sunrpc have buf of type int32_t
>*, which doesn't need the casts. If these macros are documented the
>documentation isn't in glibc, but does anything break if you define
>#define IXDR_GET_LONG(buf) ((long)IXDR_GET_INT32(buf))
>#define IXDR_PUT_LONG(buf, v) ((long)IXDR_PUT_INT32(buf, (long)(v)))
>? Solaris 9 uses similar definitions, that expect buf to point to a type
>of appropriate width (and are only defined if !defined(_LP64)).
But if you define them in that way you're going to get warnings.
The *_LONG macros are used by the *_SHORT, *_ENUM, etc macros. And if
you get warnings you break packages which build with -Werror.