Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



On Sat, Jun 26, 2010 at 11:21:37PM +0000, David Holland wrote:
> On Sat, Jun 26, 2010 at 06:25:23AM +0200, Joerg Sonnenberger wrote:
>  > > It would be better to make this a check which is size_t dependent,
>  > > rather than platform-dependent.
>  > 
>  > The idea is to black list platforms that don't do %zu and there is no
>  > way to do that without breaking cross-compilation. It is still
>  > preferable to use that if it is available, e.g. to help format string
>  > checks.
> 
> 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.

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

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

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

Joerg


Home | Main Index | Thread Index | Old Index