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
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:
> 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
compiling 6.12.70-4f470 with 64-bit gcc (with -m64) and 64-bit gnu ld on
Solaris 9:
===
1 of 346 tests failed
(46 tests were not run)
See tests/test-suite.log
Please report it to bug-coreutils@gnu.org
> From: Poor Yorick <>
> compiling 6.12.70-4f470 with 64-bit gcc (with -m64) and 64-bit gnu ld on
> Solaris 9:
>
> ===
> 1 of 346 tests failed
> (46 tests were not run)
> See tests/test-suite.log
> Please report it to bug-co
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
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
"Peter O'Gorman" <[EMAIL PROTECTED]> wrote:
> When building coreutils-6.12 with some patches from git, we noticed that
> the mkdir/selinux test fails. AIX-5.3 output:
>
> failed to set default file creation context to `invalid-selinux-context':
> Unsupported attribute value
>
> The misc/shred-exac
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
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
Poor Yorick wrote:
> compiling 6.12.70-4f470 with 64-bit gcc (with -m64) and 64-bit gnu ld on
> Solaris 9:
So on this system `timeout 4294967296 sleep 0` is invalid
but `timeout 49711d sleep 0` is OK?
The apply_time_suffix() function should be returning an
error for the latter case but is not.
I
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
Fabrizio Gabbiani wrote:
> cp: preserving permissions for `/localdirectory/targetfile': Operation not
> supported
This is likely a consequence of the recent ACL related changes. ("cp -p" now
attempts to copy the ACLs.)
To make it easier for us to fix the issue, can you please say:
- What is you
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.
14 matches
Mail list logo
