bug-gnulib
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]