Jim Meyering <[EMAIL PROTECTED]> wrote:
> Paul Eggert <[EMAIL PROTECTED]> wrote:
>
>> Pádraig Brady <[EMAIL PROTECTED]> writes:
>>
>>> Yes I suppose %z and PRIdMAX are C99 specific.
>>
>> %z is C99 specific, and should not be relied on, but PRIdMAX is fine,
>> since the inttypes module backports P
Pádraig Brady <[EMAIL PROTECTED]> wrote:
> Paul Eggert wrote:
>> Pádraig Brady <[EMAIL PROTECTED]> writes:
>>
>>> diff --git a/src/truncate.c b/src/truncate.c
>>> index 02d4102..fd321c6 100644
>>> --- a/src/truncate.c
>>> +++ b/src/truncate.c
>>> @@ -189,9 +189,9 @@ do_ftruncate (int fd, char cons
Paul Eggert wrote:
> Pádraig Brady <[EMAIL PROTECTED]> writes:
>
>> diff --git a/src/truncate.c b/src/truncate.c
>> index 02d4102..fd321c6 100644
>> --- a/src/truncate.c
>> +++ b/src/truncate.c
>> @@ -189,9 +189,9 @@ do_ftruncate (int fd, char const *fname, off_t ssize,
>> rel_mode_t rel_mode)
>>
Pádraig Brady <[EMAIL PROTECTED]> writes:
> diff --git a/src/truncate.c b/src/truncate.c
> index 02d4102..fd321c6 100644
> --- a/src/truncate.c
> +++ b/src/truncate.c
> @@ -189,9 +189,9 @@ do_ftruncate (int fd, char const *fname, off_t ssize,
> rel_mode_t rel_mode)
> }
>
>if (r
Pádraig Brady <[EMAIL PROTECTED]> wrote:
> Rather than relying on code inspection to find places
> where signed ints would be erroneously promoted to unsigned,
> I went looking for a gcc option to automatically detect this.
> It's -Wsign-compare which is automatically included in -Wextra.
> Note it
Rather than relying on code inspection to find places
where signed ints would be erroneously promoted to unsigned,
I went looking for a gcc option to automatically detect this.
It's -Wsign-compare which is automatically included in -Wextra.
Note it might be good to add to README-hacking to run conf
Pádraig Brady <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>>> Jim Meyering wrote:
By the way, does %zu work reliably everywhere now?
In the past, we've converted such values to strings via umaxtostr,
to accommodate older systems.
Jim Meyering asked:
> By the way, does %zu work reliably everywhere now?
gnulib's documentation contains the answer. From
doc/posix-functions/printf.texi:
This function does not support size specifiers as in C99 (@code{hh},
@code{ll},
@code{j}, @code{t}, @code{z}) on some platforms:
AIX 5
Jim Meyering wrote:
> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>> Jim Meyering wrote:
>>> By the way, does %zu work reliably everywhere now?
>>> In the past, we've converted such values to strings via umaxtostr,
>>> to accommodate older systems.
>>>
>>> For ssize and nsize, I have a slight preferen
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Pádraig Brady <[EMAIL PROTECTED]> writes:
>
>> Yes I suppose %z and PRIdMAX are C99 specific.
>
> %z is C99 specific, and should not be relied on, but PRIdMAX is fine,
> since the inttypes module backports PRIdMAX to older hosts.
>
> More generally, there's
Pádraig Brady <[EMAIL PROTECTED]> writes:
> Yes I suppose %z and PRIdMAX are C99 specific.
%z is C99 specific, and should not be relied on, but PRIdMAX is fine,
since the inttypes module backports PRIdMAX to older hosts.
More generally, there's not that much use for imaxtostr nowadays,
since the
Pádraig Brady <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> By the way, does %zu work reliably everywhere now?
>> In the past, we've converted such values to strings via umaxtostr,
>> to accommodate older systems.
>>
>> For ssize and nsize, I have a slight preference for the
>> cast-free appr
Jim Meyering wrote:
> By the way, does %zu work reliably everywhere now?
> In the past, we've converted such values to strings via umaxtostr,
> to accommodate older systems.
>
> For ssize and nsize, I have a slight preference for the
> cast-free approach of using %s with imaxtostr.
Yes I suppose
Pádraig Brady <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>>> Jim Meyering wrote:
Here's a tentative patch:
>> ...
>>> I reviewed all uses of off_t in the code and came up with
>>> an almost identical patch, so I'm happy to go with the above.
>>
Jim Meyering wrote:
> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>> Jim Meyering wrote:
>>> Here's a tentative patch:
> ...
>> I reviewed all uses of off_t in the code and came up with
>> an almost identical patch, so I'm happy to go with the above.
>
> Hi Pádraig,
> Thanks for checking.
> Here's wh
On Wed, Jun 25, 2008 at 11:39:50PM +0100, Pádraig Brady wrote:
> There may be nothing wrong with your system, I'm just speculating.
> For example on 64 bit systems which I don't have access to,
> there may be a mismatch between intmax_t and off_t which is not
> obvious to me? Anyway it would be goo
Pádraig Brady <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> Here's a tentative patch:
...
> I reviewed all uses of off_t in the code and came up with
> an almost identical patch, so I'm happy to go with the above.
Hi Pádraig,
Thanks for checking.
Here's what I've pushed:
[I added the IF_LINT
Michael Geng wrote:
> On Wed, Jun 25, 2008 at 08:19:56PM +0100, Pádraig Brady wrote:
>> Micheal there still is something wrong with your system I think.
>> Did you perhaps compile glibc from scratch and didn't pass
>> a required configure option for Large File Support?
>
> I didn't compile glibc m
On Wed, Jun 25, 2008 at 08:19:56PM +0100, Pádraig Brady wrote:
> Micheal there still is something wrong with your system I think.
> Did you perhaps compile glibc from scratch and didn't pass
> a required configure option for Large File Support?
I didn't compile glibc myself. So I don't know what's
On Wed, Jun 25, 2008 at 07:21:51PM +0200, Jim Meyering wrote:
> Pádraig Brady <[EMAIL PROTECTED]> wrote:
> > Michael Geng wrote:
> >> Hi,
> >>
> >> When I'm running make distcheck on the Coreutils I get an error message
> >>
> >> ...
> >> gcc -std=gnu99 -I. -I../lib -I../lib -Werror -ansi -Wno-
Jim Meyering wrote:
> Here's a tentative patch:
>
> diff --git a/src/truncate.c b/src/truncate.c
> index 8febd58..52500d2 100644
> --- a/src/truncate.c
> +++ b/src/truncate.c
> @@ -74,10 +74,21 @@ static int
> parse_len (char const *str, off_t *size)
> {
>enum strtol_error e;
> - /* OFF_T_M
On Wed, Jun 25, 2008 at 05:29:57PM +0100, Pádraig Brady wrote:
> Michael Geng wrote:
> > Hi,
> >
> > When I'm running make distcheck on the Coreutils I get an error message
> >
> > ...
> > gcc -std=gnu99 -I. -I../lib -I../lib -Werror -ansi -Wno-long-long -MT
> > truncate.o -MD -MP -MF .deps/
Pádraig Brady <[EMAIL PROTECTED]> wrote:
> Michael Geng wrote:
>> Hi,
>>
>> When I'm running make distcheck on the Coreutils I get an error message
>>
>> ...
>> gcc -std=gnu99 -I. -I../lib -I../lib -Werror -ansi -Wno-long-long -MT
>> truncate.o -MD -MP -MF .deps/truncate.Tpo -c -o truncate.o t
Michael Geng wrote:
> Hi,
>
> When I'm running make distcheck on the Coreutils I get an error message
>
> ...
> gcc -std=gnu99 -I. -I../lib -I../lib -Werror -ansi -Wno-long-long -MT
> truncate.o -MD -MP -MF .deps/truncate.Tpo -c -o truncate.o truncate.c
> cc1: warnings being treated as error
Hi,
When I'm running make distcheck on the Coreutils I get an error message
...
gcc -std=gnu99 -I. -I../lib -I../lib -Werror -ansi -Wno-long-long -MT
truncate.o -MD -MP -MF .deps/truncate.Tpo -c -o truncate.o truncate.c
cc1: warnings being treated as errors
truncate.c: In function 'parse_len
25 matches
Mail list logo
