This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] Merge status


In message <Pine.LNX.4.58.0403171344520.8991@digraph.polyomino.org.uk>, "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)
 >(v)))
 >
 >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.

jeff



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]