From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Henderson To: law@cygnus.com Cc: "David S. Miller" , egcs@cygnus.com Subject: Re: Remaining generic bits from sparc64-linux merge Date: Sat, 18 Oct 1997 11:32:00 -0000 Message-id: <19971018113450.53928@dot.cygnus.com> References: <199710021950.PAA04406@jenolan.rutgers.edu> <19375.877155402@hurl.cygnus.com> X-SW-Source: 1997-10/msg00818.html On Sat, Oct 18, 1997 at 12:16:42AM -0600, Jeffrey A Law wrote: > > * tree.c (TYPE_HASH): Type of hash val is unsigned long. > Why are you changing these variables from a HOST_WIDE_INT to > unsigned longs? To be more efficient when define HOST_WIDE_INT as long long for crossing from a 32 to 64-bit platform. We later and off all but the low 31 bits anyway. > The inclusion of stdlib.h should be conditional on HAVE_STDLIB_H. > > You also can't just delete the atol extern -- I would think you > would want to have autoconf determine if it's needed. Reasonable points. > I would advise against using atoq since I doubt it's a function we > can really depend on. It's been in the linux libcs for a while, but I now understand that atoll is what made the ISO C 9x draft, so another autoconf test is perhaps in order. > Is %llx something you can really rely upon? I don't think so. Is there > some way to handle this using standard format strings? I suppose you could shift and mask, but there's no drop-in replacement for the one argument other than %llx. Again, it is something that has been in the Linux libc for years; Ulrich would know if it's been sanctioned by the ISO draft. Whether we really want to limit ourselves to generic functions here is going to depend on how supported we want to make setting HOST_WIDE_INT to long long. My reaction is you can only do it if your libc is friendly enough. It shouldn't really have been needed at all, but it was an expedient way to get around some bugs in the sparc64 support at the time. r~