On 05/03/11 00:09, Gary V. Vaughan wrote:
> However, I'm still none-the-wiser over what needs changing in gnulib
> to take this into account correctly.
What is the output of gcc -E -dU test-stdint.c? That may help you
debug who defines what where.
Hi Paul,
On Mon, May 02, 2011 at 09:24:46AM -0700, Paul Eggert wrote:
> On 05/02/11 05:09, Gary V. Vaughan wrote:
> >> example, it could be that (which intprops.h includes)
> >> > redefines UINT_FAST8_MAX to the wrong value.
> > That seems to me to be what is happening. Is this something that gn
On 05/02/11 05:09, Gary V. Vaughan wrote:
>> example, it could be that (which intprops.h includes)
>> > redefines UINT_FAST8_MAX to the wrong value.
> That seems to me to be what is happening. Is this something that gnulib
> stdint.h can fix? It looks like a stupid mistake on the part of the
> H
Hi Paul,
Thanks for following up.
On Sun, May 01, 2011 at 10:52:48AM -0700, Paul Eggert wrote:
> On 05/01/11 10:15, Gary V. Vaughan wrote:
> > $ cat ,t.c
> > #include
> > #include "intprops.h"
> > int main (int argc, char **argv) {
> > printf("%lu\n", (unsigned long) ULONG_MAX);
> > printf("
On 05/01/11 10:15, Gary V. Vaughan wrote:
> $ cat ,t.c
> #include
> #include "intprops.h"
> int main (int argc, char **argv) {
> printf("%lu\n", (unsigned long) ULONG_MAX);
> printf("%lu\n", (unsigned long) UINT_FAST8_MAX);
> return 0;
> }
> $ cc -I. -I../lib -o ,t ,t.c && ./,t
> 4294967295
Hi Paul,
Thanks for the pointers.
On Sun, May 01, 2011 at 09:15:01AM -0700, Paul Eggert wrote:
> So, the problem is that TYPE_MAXIMUM (uint_fast8_t)
> expands to 2**32 - 1, whereas it should expand to
> 2**64 - 1.
On the contrary, it looks TYPE_MAXIMUM (uint_fast8_t) is working in
both ABIs (2**
So, the problem is that TYPE_MAXIMUM (uint_fast8_t)
expands to 2**32 - 1, whereas it should expand to
2**64 - 1. Can you use cc -E to find what expression
TYPE_MAXIMUM (uint_fast8_t) expands to, and
investigate why that expansion evaluates to the
wrong value? My impression is that TYPE_MAXIMUM (u
Hi Paul,
Thanks for the response.
On Sat, Apr 30, 2011 at 10:55:24PM -0700, Paul Eggert wrote:
> On 04/30/11 22:10, Gary V. Vaughan wrote:
> > test-stdint.o test-stdint.c
> >> "test-stdint.c", line 189: error #2105: invalid size for bit field
> >> verify (TYPE_MAXIMUM (uint_fast8_t) == UI
On 04/30/11 22:10, Gary V. Vaughan wrote:
> test-stdint.o test-stdint.c
>> "test-stdint.c", line 189: error #2105: invalid size for bit field
>> verify (TYPE_MAXIMUM (uint_fast8_t) == UINT_FAST8_MAX);
>> ^
>>
This would appear to be a bug in stdint, not in verify.
What is the value o
Ping?
On Sat, Apr 23, 2011 at 11:52:30AM +, Gary V. Vaughan wrote:
> I'm trying to build a 64bit libunistd on ia64-hpux11.23, but it fails
> while building it's gnulib tests with:
>
> source='test-stdint.c' object='test-stdint.o' libtool=no \
> DEPDIR=.deps depmode=hp2 /opt/fsw/bash32/bin
I'm trying to build a 64bit libunistd on ia64-hpux11.23, but it fails
while building it's gnulib tests with:
source='test-stdint.c' object='test-stdint.o' libtool=no \
DEPDIR=.deps depmode=hp2 /opt/fsw/bash32/bin/bash ../build-aux/depcomp \
cc -DHAVE_CONFIG_H -I. -I. -I../lib -I.. \
-DIN_L
11 matches
Mail list logo
