[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new snapshot available: coreutils-7.6.63-addb6
From: |
Simon Josefsson |
Subject: |
Re: new snapshot available: coreutils-7.6.63-addb6 |
Date: |
Tue, 06 Oct 2009 12:50:19 +0200 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) |
Pádraig Brady <address@hidden> writes:
> Jim Meyering wrote:
>> Pádraig Brady wrote:
>>
>>> Jim Meyering wrote:
>>>> Eric Blake wrote:
>>>>> According to Pádraig Brady on 10/5/2009 3:53 PM:
>>>>>>>>> This is a new test, but FC5 is soooo old,
>>>>>>>>> that I'm not sure it's worth worrying about.
>>>>>>>> March 2006?
>>>>>>> The failure is probably a function of the kernel.
>>>>>>> Which is it?
>>>>>> In summary this is what fails:
>>>>>>
>>>>>> $ touch a
>>>>>> $ ln -s a symlink
>>>>>> $ ln -L symlink hardlink
>>>>>> ln: creating hard link `hardlink' => `symlink': Invalid argument
>>>>>>
>>>>>> `man linkat` says that AT_SYMLINK_FOLLOW is only supported since 2.6.18
>>>>>> and my FC5 system is 2.6.17
>>>>> This should fix it. I don't have access to FC5, but I tested the new code
>>>>> path by priming the cache (gl_cv_func_linkat_follow=runtime ./configure)
>>>>> along with a temporary setting of have_follow_really=-1 in linkat.c. I
>>>>> also verified that the replacement is not picked up on cygwin 1.7, where
>>>>> AT_SYMLINK_FOLLOW was implemented at the same time as linkat.
>>>>>
>>>>> The patch copies from areadlink.c, as well as link_follow earlier in
>>>>> linkat.c, to create two new fd-relative helpers. For now, I didn't see
>>>>> any reason to expose them, but areadlinkat may someday be worth making
>>>>> into a full-blown module.
>>>> Wow, that was quick. Thanks.
>>>> I should have read this first.
>>>>
>>>> I was just reviewing the changes in gnulib and
>>>> see a few that should be included in the imminent coreutils
>>>> beta release, so will probably take this one, too.
>>> Needs a couple of tweaks..
>>>
>>> This needs to be added to linkat.c
>>> (seems like it should be refactored somewhere?)
>>>
>>> #ifndef SIZE_MAX
>>> # define SIZE_MAX ((size_t) -1)
>>> #endif
>>> #ifndef SSIZE_MAX
>>> # define SSIZE_MAX ((ssize_t) (SIZE_MAX / 2))
>>> #endif
>>
>> This should do it:
>>
>>>From 6f6420cc9705dcfa545a28c674fddf5703e72c86 Mon Sep 17 00:00:00 2001
>> From: Jim Meyering <address@hidden>
>> Date: Tue, 6 Oct 2009 11:11:39 +0200
>> Subject: [PATCH] linkat: avoid compilation failure
>>
>> * lib/linkat.c: Include <stdint.h> for use of SIZE_MAX.
>
> That works thanks.
>
> I suppose these should include stdint.h also?
>
> areadlink.c:# define SIZE_MAX ((size_t) -1)
> areadlink-with-size.c:# define SIZE_MAX ((size_t) -1)
> backupfile.c:# define SIZE_MAX ((size_t) -1)
> fnmatch.c:# define SIZE_MAX ((size_t) -1)
> quotearg.c:# define SIZE_MAX ((size_t) -1)
> striconv.c:# define SIZE_MAX ((size_t) -1)
Note that stdint.h may not be sufficient to get SIZE_MAX, quoting
size_max.h:
/* Get SIZE_MAX declaration on systems like Solaris 7/8/9. */
# include <limits.h>
/* Get SIZE_MAX declaration on systems like glibc 2. */
# if HAVE_STDINT_H
# include <stdint.h>
# endif
/* On systems where these include files don't define it, SIZE_MAX is defined
in config.h. */
However given that SIZE_MAX should be in stdint.h according to POSIX,
maybe it makes more sense to make sure gnulib's stdint.h replacement is
enabled when SIZE_MAX is not provided by the system's stdint.h? And
then deprecate size_max.h in favor of stdint.
> While these already include stdint.h so should probably not redefine
>
> fts.c:# define SIZE_MAX ((size_t) -1)
> getdelim.c:# define SSIZE_MAX ((ssize_t) (SIZE_MAX / 2))
> getndelim2.c:# define SSIZE_MAX ((ssize_t) (SIZE_MAX / 2))
SSIZE_MAX should be provided by limit.h, see:
http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html
The stdint.h documentation doesn't mention SSIZE_MAX:
http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html
/Simon
- Re: new snapshot available: coreutils-7.6.63-addb6, (continued)
- Re: new snapshot available: coreutils-7.6.63-addb6, Pádraig Brady, 2009/10/05
- Re: new snapshot available: coreutils-7.6.63-addb6, Jim Meyering, 2009/10/05
- Re: new snapshot available: coreutils-7.6.63-addb6, Pádraig Brady, 2009/10/05
- Re: new snapshot available: coreutils-7.6.63-addb6, Eric Blake, 2009/10/05
- Re: new snapshot available: coreutils-7.6.63-addb6, Jim Meyering, 2009/10/06
- Re: new snapshot available: coreutils-7.6.63-addb6, Eric Blake, 2009/10/05
- Re: new snapshot available: coreutils-7.6.63-addb6, Jim Meyering, 2009/10/06
- Re: new snapshot available: coreutils-7.6.63-addb6, Pádraig Brady, 2009/10/06
- Re: new snapshot available: coreutils-7.6.63-addb6, Jim Meyering, 2009/10/06
- Re: new snapshot available: coreutils-7.6.63-addb6, Pádraig Brady, 2009/10/06
- Re: new snapshot available: coreutils-7.6.63-addb6,
Simon Josefsson <=
- Re: new snapshot available: coreutils-7.6.63-addb6, Paolo Bonzini, 2009/10/06
- Re: new snapshot available: coreutils-7.6.63-addb6, Pádraig Brady, 2009/10/06
- areadlinkat (was: new snapshot available: coreutils-7.6.63-addb6), Eric Blake, 2009/10/07
- Re: areadlinkat, Jim Meyering, 2009/10/07
Re: new snapshot available: coreutils-7.6.63-addb6, Eric Blake, 2009/10/05