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


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)).

I'm not familiar with RPC, but the correct fix for an lvalue cast isn't
necessarily to replicate the lvalue cast's semantics.  Sometimes - as it
looks like here - the interface to the code doesn't need the cast, and
sometimes the author may have written an lvalue cast by accident and meant
something else (but the bug not been detected).

-- 
Joseph S. Myers
jsm@polyomino.org.uk


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