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 dholl...@netbsd.org