Re: [bug-gnulib] Re: stdint_.h vs intmax_t & uintmax_t

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bruno Haible <address@hidden> writes:

> Mark D. Baushke wrote on 2005-11-15:
> > it would be more portable to use this:
> > 
> >     #ifndef SIZE_MAX
> >     # define SIZE_MAX ((size_t)-1)
> >     #endif
> > 
> > because ((size_t)-1) will work even if size_t is narrower than int.
> 
> Yes. As explained on 2005-07-11, I prefer to write this as
>   ((size_t)~(size_t)0)
> because this way we don't need to refer to ISO C 99 6.3.1.3.(2).

Hmmm... let me see.

ISO C 99 6.3.1.3.(2) says:
| 2 Otherwise, if the new type is unsigned, the
|   value is converted by repeatedly adding or
|   subtracting one more than the maximum value that
|   can be represented in the new type until the
|   value is in the range of the new type. 49)
| 
| 49) The rules describe arithmetic on the
|     mathematical value, not the value of a given
|     type of expression.

I guess I didn't see the ISO C 99 reference in the
2005-07-11 posting. Perhaps, I didn't find the one
you referenced...

Bruno wrote on 2005-07-11 (Subject: Re: [bug-gnulib] Re: size_max):
|> Paul Eggert wrote:
|> > Also, while we're on the subject of size_max.m4, I have a pedantic
|> > point: its use of ~(size_t)0 isn't portable in general.  For example,
|> > if size_t is narrower than int, then ~(size_t)0 might evaluate to -1,
|> > which isn't correct.
|> 
|> Ah, right. I'm changing it to (size_t)~(size_t)0. Although I know that
|> (size_t)~0 and (size_t)-1 in theory yield the same value. I find it
|> more confusing to cast a negative number to an unsigned type, than to
|> use two casts.
|> 
|> 2005-07-10  Bruno Haible  <address@hidden>
|> 
|>      * size_max.m4 (gl_SIZE_MAX): Cast ~(size_t)0 back to size_t.
|>      Needed when size_t is smaller than 'unsigned int'.
|>      Reported by Paul Eggert.


I have no problems with either
((size_t)~(size_t)0) or ((size_t)-1) being used.
However, the previous definition in stdint_.h of
'#define SIZE_MAX (~(size_t)0)' seemed wrong to
me.

I suspect that as this issue is often raised,
adding a comment to the ISO C 99 section may
actually be wise regardless of which definition
is used.

        Thanks!
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFDwreJCg7APGsDnFERAhTqAJ9JfIxXiFhFWrob3wP77iFYKeGDJgCePrNU
+cZcvMkPmH/RJaUFVo5QtIU=
=6bi7
-----END PGP SIGNATURE-----