Re: CVS commit: src/crypto/external/bsd/netpgp/dist/src/lib

[David Holland <dholland-sourcechanges%netbsd.org@localhost>]

On Sun, Jun 27, 2010 at 08:10:41PM +0200, Joerg Sonnenberger wrote:
 > > Compromising the autoconfiguration not work properly in the name of
 > > cross-compilation, though, is misguided. Can't you have it run the
 > > test if it's not a cross-compiler and only if it is fall back to the
 > > platform test? Or is this one of the things where autoconf falls apart
 > > because it's not written in a programming language?
 > 
 > You can by using AC_RUN_IFELSE directly. The fourth argument is the
 > cross-compiling test.

That seems like a better approach then, especially in this context.

 > > I suppose the best available comprehensive solution is to use PRIu***
 > > garble in the code and then if necessary have autoconf figure out what
 > > the garble should expand to based on SIZE_MAX.
 > 
 > The trivial example was FreeBSD 4.x, but I would expect platforms with
 > %zu to fall into this category too.

...huh?

What you wrote doesn't relate to what you quoted, and also isn't an
answer to what I asked, which was:

 : Are there non-theoretical platforms that are missing both SIZE_MAX and
 : SIZE_T_MAX defines where it isn't either 0xffffffff or
 : 0xffffffffffffffff?

which certainly does not include FreeBSD 4.x unless they grew a PDP-10
port or something while we weren't looking.

You can easily distinguish the 32-bit vs. 64-bit case by trying to
compile something like

   typedef char foo[((size_t)0xffffffffUL)+1];

If size_t is 32 bits it'll fail trying to declare a zero-length array
type. It might conceivably also fail for other reasons but again I
don't think there are non-theoretical platforms where this is an
issue, except for 16-bit DOS which we explicitly do not care about.

 > > (not counting where it might technically be 0x7fffffff because someone
 > > was unclear on it being unsigned -- that doesn't affect printf)
 > 
 > SSIZE_MAX is surprisingly a lot better supported...

Since ssize_t is required to be the same size as size_t, why not
leverage that?

 > >  > > I still don't understand why autoconf is passing C pre-processor
 > >  > > directives down.
 > >  > > 
 > >  > > #if sizeof(size_t) == sizeof(int)
 > >  > > ...
 > >  > > #elif sizeof(size_t) == sizeof(long)
 > >  > > ...
 > >  > > #endif
 > >  > > 
 > >  > > directly in the code is much more readable.
 > > 
 > > It would be nice if that worked... it did in Borland's compiler back
 > > in the day. I suppose someone on the standards committee thought it
 > > was OK to have to teach the preprocessor the entire expression syntax
 > > but not the type name syntax...
 > 
 > The problem is that you can't really evuluate the above with
 > interpreting all of the C code before. size_t is not a "keyword" type in
 > the sense that it is hard-coded into the compiler. Doing so would
 > violate the layering design of the preprocessor.

As it's a standard type, however, it could be made known to the
preprocessor via some other mechanism. (And you'll find that it is
actually hard-coded into the compiler in gcc anyway; if your libc
headers don't agree with gcc on what it should be you'll get assorted
static on stderr.)

That won't work in general, but I suspect most or all of the cases
where #if sizeof would actually be useful involve standard types.

-- 
David A. Holland
dholland%netbsd.org@localhost