bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnulib support for st_birthtime (second revision of patch)


From: Bruno Haible
Subject: Re: gnulib support for st_birthtime (second revision of patch)
Date: Tue, 27 Mar 2007 13:04:12 +0200
User-agent: KMail/1.5.4

James Youngman wrote:
> Needs testing on everything else, notably including:
>       Cygwin CVS (i.e. version 1.7 or later)
>       mingw
>       Systems completely lacking nanosecond timestamps

Thanks for the patch. So it can be tested by everyone easily, I applied
the patch, with trivial modifications to use the common gnulib style:
  - use spaces before opening parentheses, as in GNU coding style,
  - avoid parentheses after 'if defined',
  - put the specification header to be tested second, after <config.h>,
  - use temporary file names that are not likely to collide with other tests.
  - use a signal handler so the temporary files are removed when the test
    gets aborted by Ctrl-C.

Changed test_birthtime's return value to 'void', since the function falls
off without providing a return value, and since the return value is effectively
not used.

Changed NFILES from 5 to 4, to avoid using uninitialized values.

Removed the "1 || " in the test, that disabled the test_birthtime test,
probably a leftover from your tests.

Avoided gcc warnings like
../gllib/stat-time.h:56: Warnung: `struct stat' declared inside parameter list
../gllib/stat-time.h:56: Warnung: its scope is only this definition or declarati
test-stat-time.c: Dans la fonction « cleanup »:
test-stat-time.c:37: Warnung: implicit declaration of function `unlink'
(CPPFLAGS=-Wall is the default for me.)

> Style issue:
>       The test case perhaps should not ASSERT that the test 
>       files can be created.   It should arguably skip the test 
>       withough failing if that happens.

Other tests also assume write access to the current directory. Tests don't
need to be 100% foolproof; 99.9% is ok. These are things that can be fixed
later, when someone stumbles on them.

Bruno






reply via email to

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