On 01/02/2012 07:52 PM, Bruno Haible wrote:
> Pádraig Brady wrote:
>> This is for use in a proposed coreutils `realpath` command.
>
> The comment in the .c file is now not in sync with the one in the .h file,
> and it has a typo.
>
> Are you ok with this amendment?
Yes.
thanks Bruno
Pádraig Brady wrote:
> This is for use in a proposed coreutils `realpath` command.
The comment in the .c file is now not in sync with the one in the .h file,
and it has a typo.
Are you ok with this amendment?
2012-01-02 Bruno Haible
canonicalize: Tweak 2011-12-29 commit.
* l
Eric Blake wrote:
> I'd welcome a patch to gnulib to prove me wrong by fixing rpl_stat to be
> an object-like instead of function-like macro, all while still allowing
> compilation to succeed in all interfaces that take 'struct stat *' as a
> parameter, including when using those interfaces via fun
On 12/30/2011 12:19 PM, Paul Eggert wrote:
> On 12/30/11 08:36, Eric Blake wrote:
>
>> unless you can declare struct rpl_stat with the same layout
>> as struct stat, you have an API incompatibility that can cause
>> compilation errors in various circumstances.
>
> Ah, sorry, I was assuming that w
On 12/30/11 08:36, Eric Blake wrote:
> unless you can declare struct rpl_stat with the same layout
> as struct stat, you have an API incompatibility that can cause
> compilation errors in various circumstances.
Ah, sorry, I was assuming that we '#define stat rpl_stat'
before including the system
On 12/30/2011 09:10 AM, Paul Eggert wrote:
> On 12/30/11 05:49, Eric Blake wrote:
>> the gnulib replacement for stat on some platforms has to be a function-like
>> macro (no thanks to 'struct stat')
>
> Why does the gnulib replacement do that?
> If gnulib instead did "#define stat rpl_stat",
> tha
On 12/30/11 05:49, Eric Blake wrote:
> the gnulib replacement for stat on some platforms has to be a function-like
> macro (no thanks to 'struct stat')
Why does the gnulib replacement do that?
If gnulib instead did "#define stat rpl_stat",
that would rename 'struct stat' to 'struct rpl_stat',
but
Jim Meyering wrote:
> Pádraig Brady wrote:
>> On 12/30/2011 01:49 PM, Eric Blake wrote:
>>> On 12/30/2011 04:04 AM, Jim Meyering wrote:
> - if (lstat (rname, &st) != 0)
> + if ((logical?stat:lstat) (rname, &st) != 0)
Please add spaces around operators:
Pádraig Brady wrote:
> On 12/30/2011 02:43 PM, Pádraig Brady wrote:
>> On 12/30/2011 01:49 PM, Eric Blake wrote:
>>> On 12/30/2011 04:04 AM, Jim Meyering wrote:
> - if (lstat (rname, &st) != 0)
> + if ((logical?stat:lstat) (rname, &st) != 0)
Please add spaces aro
On 12/30/2011 02:43 PM, Pádraig Brady wrote:
> On 12/30/2011 01:49 PM, Eric Blake wrote:
>> On 12/30/2011 04:04 AM, Jim Meyering wrote:
- if (lstat (rname, &st) != 0)
+ if ((logical?stat:lstat) (rname, &st) != 0)
>>>
>>> Please add spaces around operators:
>>>
>>>
Pádraig Brady wrote:
> On 12/30/2011 01:49 PM, Eric Blake wrote:
>> On 12/30/2011 04:04 AM, Jim Meyering wrote:
- if (lstat (rname, &st) != 0)
+ if ((logical?stat:lstat) (rname, &st) != 0)
>>>
>>> Please add spaces around operators:
>>>
>>> if ((logical ? st
On 12/30/2011 01:49 PM, Eric Blake wrote:
> On 12/30/2011 04:04 AM, Jim Meyering wrote:
>>> - if (lstat (rname, &st) != 0)
>>> + if ((logical?stat:lstat) (rname, &st) != 0)
>>
>> Please add spaces around operators:
>>
>> if ((logical ? stat : lstat) (rname, &st) != 0)
On 12/30/2011 04:04 AM, Jim Meyering wrote:
>> - if (lstat (rname, &st) != 0)
>> + if ((logical?stat:lstat) (rname, &st) != 0)
>
> Please add spaces around operators:
>
> if ((logical ? stat : lstat) (rname, &st) != 0)
Better yet, don't write this as a function poi
On 12/30/2011 11:04 AM, Jim Meyering wrote:
> Pádraig Brady wrote:
>> +
>> +/* Modify the original (Not yet supported). */
>> +CAN_NOALLOC = 8
>
> Would it be better to add it along with the
> change that adds support?
Yes probably.
I'll add a comment on the possibility instead.
Thanks
od.
Some nits:
> Subject: [PATCH] canonicalize: add support for not resolving symlinks
>
> This will initially be used by a new coreutils realpath command.
>
> * lib/canonicalize.h: Add the CAN_NOLINKS flag to
> indicate we don't want to follow symlinks. Also
>
p 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?=
Date: Thu, 29 Dec 2011 23:49:53 +
Subject: [PATCH] canonicalize: add support for not resolving symlinks
This will initially be used by a new coreutils realpath command.
* lib/canonicalize.h: Add the CAN_NOLINKS flag to
indicate we don
16 matches
Mail list logo