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