bug-gnulib
[Top][All Lists]
Advanced

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

Re: size_max: remove it?


From: Bruno Haible
Subject: Re: size_max: remove it?
Date: Thu, 27 Apr 2006 19:22:36 +0200
User-agent: KMail/1.5

Simon Josefsson wrote:
> There is size_max, which does:
>
> # include <limits.h>

This is needed to avoid a "macro redefined" warning e.g. on Solaris 7.

> # if HAVE_STDINT_H
> #  include <stdint.h>
> # endif

This is needed to avoid a "macro redefined" warning e.g. on glibc systems.

> that doesn't seem compatible with the stdint.h module (I'm assuming
> that the stdint module doesn't define HAVE_STDINT_H).

More explanations please? I cannot follow. If the system does not have a
<stdint.h> file but gnulib creates its own, it won't be used - since
HAVE_STDINT_H is 0 or undefined. If the system has a <stdint.h>, and
gnulib 'stdlib' decides to provide its own nevertheless, then gnulib's
will be used at compile time while the system's one was used at configure
time; this is not perfect but I don't see how it could lead to an error.

> So if there is
> no stdint.h, and limits.h doesn't define SIZE_MAX, this module doesn't
> work.

In this case the size_max.m4 macro will have written a SIZE_MAX definition
into config.h. The one in gnulib's stdint.h will not be used then, since it's
#ifdefed out.

> Is there a reason to keep size_max?

We don't want "config.h" to #include any system headers.

> The stdint module defines SIZE_MAX too, and appear to be more robust.

I doubt that stdint.h is more robust; it's hardly used so far.

> Alternatively, I think the size_max.h should contain:
>
> #ifndef SIZE_MAX
> # define SIZE_MAX ((size_t)~(size_t)0)
> #endif

Then it would need to #include yet another header, such as <stddef.h>.

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]