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.
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
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
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 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
"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
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
> 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
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
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
14 matches
Mail list logo
