On 08/31/11 20:30, Kevin Brott wrote:
> Attached are the full truss outputs. It *looks* like a lot of extra/failed
> seeks in the fstatat-enabled tar?
I think that's AIX doing its security thing. Perhaps it matters,
but perhaps it's irrelevant. Without knowing AIX internals it's
hard to say.
On Wed, Aug 31, 2011 at 19:35, Kevin Brott wrote:
> On Wed, Aug 31, 2011 at 17:34, Paul Eggert wrote:
>
>> On 08/31/11 07:06, Kevin Brott wrote:
>> > If we do not use fstatat then tar builds and passes almost all of the
>> checks (only the two sparse file ones fail).
>> > If we use fstatat, then
On Wed, Aug 31, 2011 at 17:34, Paul Eggert wrote:
> On 08/31/11 07:06, Kevin Brott wrote:
> > If we do not use fstatat then tar builds and passes almost all of the
> checks (only the two sparse file ones fail).
> > If we use fstatat, then almost all of the checks fail - because the
> resulting bi
On 08/31/11 07:06, Kevin Brott wrote:
> If we do not use fstatat then tar builds and passes almost all of the checks
> (only the two sparse file ones fail).
> If we use fstatat, then almost all of the checks fail - because the resulting
> binary is dropping zero-byte files into the archives, and
Bastien ROUCARIES wrote:
> >> - hpux has pstat
> >
> > More details, please? pstat_getfiledetails does not return a file name.
>
> See pstat_getpathname()
I can't find a definition of pst_fid anywhere. Also, this function only
accesses a cache; it may fail. Also, what if fd is a pipe or socket?
On Wed, Aug 31, 2011 at 9:54 PM, Bruno Haible wrote:
> Bastien ROUCARIES wrote:
>> More means to retrieve file name
>> - linux /proc/self/fd
>> - windows FileInformation of GetFileInformationByHandleEx
>> - freebsd using FDESCFS /dev/fd or proc
>> - solaris using FDESCFS or proc
>> - osx as /dev/
Pádraig Brady wrote:
> On 08/31/2011 04:48 PM, Jim Meyering wrote:
>> The test-float test is failing on ppc64 with:
>>
>> gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC)
>> (albeit an aging Fedora 12 system)
>>
>> due to the failure of this assertion:
>>
>> ASSERT (LDBL_MIN_EXP <=
Bastien ROUCARIES wrote:
> More means to retrieve file name
> - linux /proc/self/fd
> - windows FileInformation of GetFileInformationByHandleEx
> - freebsd using FDESCFS /dev/fd or proc
> - solaris using FDESCFS or proc
> - osx as /dev/fd
> - irix has /dev/fd
Interesting, yes. That would work.
>
Bruno Haible wrote:
> Jim Meyering wrote:
>> I propose to comment out that test for now, just prior
>> to the coreutils-8.13 pre-release snapshot.
>
> But you are not done with commenting out the assertion.
>
> The programs 'printf', 'seq', and 'sort' assume that a 'double' number
> can be lossles
Jim Meyering wrote:
> I propose to comment out that test for now, just prior
> to the coreutils-8.13 pre-release snapshot.
But you are not done with commenting out the assertion.
The programs 'printf', 'seq', and 'sort' assume that a 'double' number
can be losslessly converted to a 'long double'.
On 08/31/2011 04:48 PM, Jim Meyering wrote:
> The test-float test is failing on ppc64 with:
>
> gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC)
> (albeit an aging Fedora 12 system)
>
> due to the failure of this assertion:
>
> ASSERT (LDBL_MIN_EXP <= DBL_MIN_EXP);
>
> It fails b
The test-float test is failing on ppc64 with:
gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC)
(albeit an aging Fedora 12 system)
due to the failure of this assertion:
ASSERT (LDBL_MIN_EXP <= DBL_MIN_EXP);
It fails because of these numbers:
$ :|gcc -dD -E -include stddef.h -
Pádraig Brady wrote:
> On 08/31/2011 03:25 PM, Jim Meyering wrote:
>
>> diff --git a/lib/parse-datetime.y b/lib/parse-datetime.y
>
>> +iso_8601_time:
>> +tUNUMBER zone_offset
>> + {
>> +set_hhmmss (pc, $1.value, 0, 0, 0);
>> +pc->meridian = MER24;
>
> There is a tab introduced
On 08/31/2011 03:25 PM, Jim Meyering wrote:
> diff --git a/lib/parse-datetime.y b/lib/parse-datetime.y
> +iso_8601_time:
> +tUNUMBER zone_offset
> + {
> +set_hhmmss (pc, $1.value, 0, 0, 0);
> + pc->meridian = MER24;
There is a tab introduced above.
cheers,
Pádraig.
Eric Blake wrote:
> On 08/31/2011 08:44 AM, Jim Meyering wrote:
>> @@ -93,21 +93,21 @@ tm_diff (struct tm const *a, struct tm const *b)
>> }
>> #endif /* ! HAVE_TM_GMTOFF */
>>
>> -long
>> -gmt_offset()
>> +static long
>> +gmt_offset ()
>
> Shouldn't this be:
>
> static long
> gmt_offset (void
On 08/31/2011 08:44 AM, Jim Meyering wrote:
@@ -93,21 +93,21 @@ tm_diff (struct tm const *a, struct tm const *b)
}
#endif /* ! HAVE_TM_GMTOFF */
-long
-gmt_offset()
+static long
+gmt_offset ()
Shouldn't this be:
static long
gmt_offset (void)
to avoid yet more warnings about K&R declarati
Using this new code in coreutils exposed a minor problem,
due to its use of -Werror=missing-declarations:
test-parse-datetime.c:97:1: error: no previous declaration for \
'gmt_offset' [-Werror=missing-declarations]
cc1: all warnings being treated as errors
I fixed it and some style
I've just pushed this.
Documentation coming in the next few days, one way or another.
>From c2ecbc9a8262595b27f741e41375d06213a30fb6 Mon Sep 17 00:00:00 2001
From: "J.T. Conklin"
Date: Wed, 17 Aug 2011 16:40:49 -0700
Subject: [PATCH] parse-datetime: accept ISO 8601 date and time rep with "T"
sep
On Wed, Aug 31, 2011 at 01:10, Bruno Haible wrote:
> Hi Paul,
>
> > > Return code on that as compiled comes back as "1" .
> >
> > OK, thanks, to move forward on that part, I installed the following
> > patch into gnulib.
> > ... check for the AIX 7.1 bug
>
> But there is no AIX 7.1 bug. If fstata
On Wed, Aug 31, 2011 at 11:13 AM, Bastien ROUCARIES
wrote:
> On Wed, Aug 31, 2011 at 10:49 AM, Bruno Haible wrote:
>> Claudio Bley wrote:
>>> Furthermore, using NULL as filename does not work at all using the MS
>>> C runtime library (debug assertion violation).
>>>
>>>
>>> -
On Wed, Aug 31, 2011 at 10:49 AM, Bruno Haible wrote:
> Claudio Bley wrote:
>> Furthermore, using NULL as filename does not work at all using the MS
>> C runtime library (debug assertion violation).
>>
>>
>> --- freopen.c.1 2011-08-25 21:05:34 +0200
>> +++ freopen.c 2011
Claudio Bley wrote:
> Furthermore, using NULL as filename does not work at all using the MS
> C runtime library (debug assertion violation).
>
>
> --- freopen.c.1 2011-08-25 21:05:34 +0200
> +++ freopen.c 2011-08-25 21:08:52 +0200
> @@ -38,6 +38,9 @@
> rpl_freopen (cons
Claudio Bley wrote:
> When calling
>
> freopen(NULL, mode, stream);
>
> on MS Windows using MinGW segfaults because it tries to strcmp(NULL,
> "/dev/null")... *ouch*
>
>
> --- freopen.c.orig2011-08-03 14:22:15 +0200
> +++ freopen.c 2011-08-25 21:01:46 +0200
> @@ -38,7 +
Hi Paul,
> > Return code on that as compiled comes back as "1" .
>
> OK, thanks, to move forward on that part, I installed the following
> patch into gnulib.
> ... check for the AIX 7.1 bug
But there is no AIX 7.1 bug. If fstatat would return wrong st_size fields,
the return code would have been
24 matches
Mail list logo
