headers
Jim Meyering | 1 Jul 2005 01:06
Gravatar

Re: proposal: lib/verify.h

Paul Eggert <eggert <at> CS.UCLA.EDU> wrote:
> Jim Meyering <jim <at> meyering.net> writes:
>
>>   #define GL_CONCAT...
>>   #define VERIFY(assertion) \
>>     struct GL_CONCAT (compile_time_assert_, __LINE__) \
>>       { char a[(assertion) ? 1 : -1]; }
>
> This trick won't work if VERIFY is used in two different files with
> the same line number.  Typically the problem would occur if there are
> multiple headers that use VERIFY, or a header and a source file that
> both use VERIFY.

That's true, but maybe it won't matter in practice?
All of my uses of the statement-form have ended up being
expanded in .c files.

> Admittedly it's a bit of a pain to have to come up with a name for
> each requirement, as is the case with mktime.c now.
>
> So, how about if we simply dump the named-requirement variant, and
> stick only with the unnamed variant?  If there is a need to verify
> stuff at the top level, we can do something like this:
>
> static inline void
> verify_mktime_requirements (void)
> {
>   verify (TYPE_IS_INTEGER (time_t));
>   verify (TYPE_TWOS_COMPLEMENT (int));
>   ...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Eggert | 1 Jul 2005 19:33
Favicon

xnanosleep.c port to OpenBSD 3.4

I installed the following to fix a porting problem with OpenBSD 3.4.
Its <time.h> declares 'struct timespec' but does not define it,
i.e., it says only "struct timespec;".  (That's pretty usesless, hun?)

2005-07-01  Paul Eggert  <eggert <at> cs.ucla.edu>

	* xnanosleep.c: Include timespec.h, since OpenBSD 3.4 <time.h>
	declares only 'struct timespec;' (!).

Index: lib/xnanosleep.c
===================================================================
RCS file: /cvsroot/gnulib/gnulib/lib/xnanosleep.c,v
retrieving revision 1.5
diff -p -u -r1.5 xnanosleep.c
--- lib/xnanosleep.c	14 May 2005 06:03:58 -0000	1.5
+++ lib/xnanosleep.c	1 Jul 2005 17:23:52 -0000
 <at>  <at>  -33,6 +33,7  <at>  <at> 
 #include <time.h>

 #include "intprops.h"
+#include "timespec.h"

 #ifndef TIME_T_MAX
 # define TIME_T_MAX TYPE_MAXIMUM (time_t)
Permalink | Reply | 0 comments |
headers
Jim Meyering | 1 Jul 2005 23:17
Gravatar

FYI: removing HAVE_FCNTL_H tests

I've just removed all tests for HAVE_FCNTL_H from coreutils.
It's been gone in at least one place since coreutils-5.0 (2004-04-02)
and no one has complained, so I think it's safe to say every system
we care about has fcntl.h, now.

If you know of a system (reasonable portability target)
that lacks fcntl.h, speak now.

Tomorrow I plan to remove all #if HAVE_FCNTL_H tests,
retaining only the `if' branch.  Likewise, there is no
need to check for fcntl.h in .m4 macros.
Permalink | Reply | 6 comments |
headers
Jim Meyering | 2 Jul 2005 00:20
Gravatar

Re: FYI: removing HAVE_FCNTL_H tests

Jim Meyering <jim <at> meyering.net> wrote:
> I've just removed all tests for HAVE_FCNTL_H from coreutils.
> It's been gone in at least one place since coreutils-5.0 (2004-04-02)

The same applies to HAVE_UNISTD_H and unistd.h,
but I haven't yet made the change in coreutils.
I'll do it over the weekend, too.

> and no one has complained, so I think it's safe to say every system
> we care about has fcntl.h, now.
>
> If you know of a system (reasonable portability target)
> that lacks fcntl.h, speak now.
Permalink | Reply | 3 comments |
headers
Jim Meyering | 2 Jul 2005 08:17
Gravatar

Re: FYI: removing HAVE_FCNTL_H tests

Jim Meyering <jim <at> meyering.net> wrote:
> I've just removed all tests for HAVE_FCNTL_H from coreutils.
> It's been gone in at least one place since coreutils-5.0 (2004-04-02)
> and no one has complained, so I think it's safe to say every system
> we care about has fcntl.h, now.

FYI, that date should have been (2003-04-02).
Permalink | Reply | 0 comments |
headers
Jim Meyering | 2 Jul 2005 12:05
Gravatar

Re: FYI: removing HAVE_FCNTL_H tests

I wrote:
> I've just removed all tests for HAVE_FCNTL_H from coreutils.
> It's been gone in at least one place since coreutils-5.0 (2003-04-02)
> and no one has complained, so I think it's safe to say every system
> we care about has fcntl.h, now.
>
> If you know of a system (reasonable portability target)
> that lacks fcntl.h, speak now.
>
> Tomorrow I plan to remove all #if HAVE_FCNTL_H tests,
> retaining only the `if' branch.  Likewise, there is no
> need to check for fcntl.h in .m4 macros.

I've just done the same for gnulib:

[lib]
2005-07-01  Jim Meyering  <jim <at> meyering.net>

	* chown.c, cloexec.c, dup-safer.c, dup2.c, fsusage.c, getcwd.c:
	* getloadavg.c, mountlist.c, openat.h, pagealign_alloc.c:
	* save-cwd.c, tempname.c:
	Assume HAVE_FCNTL_H (i.e., include <fcntl.h> unconditionally,
	and don't include <sys/file.h>).

[m4]
2005-07-02  Jim Meyering  <jim <at> meyering.net>

	* chown.m4, cloexec.m4, dup2.m4, fsusage.m4:
	* getcwd-path-max.m4, getcwd.m4, mkstemp.m4, mountlist.m4:
	* pagealign_alloc.m4, save-cwd.m4, unistd-safer.m4:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrice Dumas | 3 Jul 2005 16:20
Picon
Favicon

Use of the m4 macros and standard package

Hi,

I think that the gnulib manual isn't very clear about the use of the macros
provided by gnulib-tool. My understanding, after reading the macros is that 
whenever gl_EARLY and gl_INIT are used there is no need to explicitely call 
macros like
AC_FUNC_ALLOCA
nor to use the specific gnulib macro, like gl_FUNC_ALLOCA or AM_FUNC_GETLINE.
I think it should be stated more clearly. 

I also think that "complete" configure.ac and Makefile.am used as examples
for a virtual very simple project using gnulib are missing.

If my interpretation is right and such examples are really needed I can do a 
patch to gnulib.texi, with the example too.

Last I think that gnulib is not advertised enough nor easy to install
enough, although it is a very natural companion for autoconf. Without 
gnulib, using macros like AC_FUNC_ALLOCA or AC_FUNC_MEMCMP requires 
too much work rendering those macros almost useless. And if this work
is done it is a wasted effort as it allready exists in gnulib.

Now the only way to install gnulib is to get it from CVS and run 
gnulib-tool from the CVS sources, this is not standard for GNU things.
In my opinion it should be much simpler if the scripts went to ${bindir}
the m4, lib and modules dir went to ${pkgdatadir} and the package
was available as a standard and very very simple autoconf/automake 
package. It would be even better if this was backward compatible, ie the
scripts still could be called from the source directory.
(Continue reading)

Permalink | Reply | 8 comments |
headers
James Youngman | 3 Jul 2005 16:33
Picon
Gravatar

Gnulib's regex.c appears to ignore RE_ICASE

Hello all, 

I've just noticed that Gnulib's regex.c implementation appears to
ignore the RE_ICASE flag.  The regexec() function it provides takes
notice of REG_ICASE (and sets up a translation table), but the
re_compile_pattern() and re_search() family ignore the RE_ICASE flag
(and of course they also ignore REG_ICASE, as they should I suppose).

The RE_ICASE flag appears to work with glibc's implementation of
re_match().  My system is using libc6 from Debian (2.3.2.ds1-22).

$ cvs -z3 update regex.[ch]
$ grep _ICASE *.[ch]
regex.c:     If REG_ICASE is set, then we considers upper- and lowercase
regex.c:  if (cflags & REG_ICASE)
regex.h:#define RE_ICASE (RE_INVALID_INTERVAL_ORD << 1)
regex.h:#define REG_ICASE (REG_EXTENDED << 1)
regex.h:#define REG_NEWLINE (REG_ICASE << 1)
$ cat CVS/Root
:ext:anoncvs <at> savannah.gnu.org:/cvsroot/gnulib
$ cvs -z3 status regex.[ch]
===================================================================
File: regex.c           Status: Up-to-date

   Working revision:    1.89
   Repository revision: 1.89    /cvsroot/gnulib/gnulib/lib/regex.c,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Youngman | 3 Jul 2005 17:01
Picon
Gravatar

Re: Use of the m4 macros and standard package

On Sun, Jul 03, 2005 at 04:20:30PM +0200, Patrice Dumas wrote:
> Hi,
> 
> I think that the gnulib manual isn't very clear about the use of the macros
> provided by gnulib-tool. My understanding, after reading the macros is that 
> whenever gl_EARLY and gl_INIT are used there is no need to explicitely call 
> macros like
> AC_FUNC_ALLOCA
> nor to use the specific gnulib macro, like gl_FUNC_ALLOCA or AM_FUNC_GETLINE.
> I think it should be stated more clearly. 

When I changed findutils from using a 'built-in' (and very out of
date) version of gnulib to using CVS gnulib with gnulib-tool, I found
this transition difficult.  Not just initially, but in terms of
ironing out wrinkles.  

Certainly at that point, most GNU projects using gnulib kept gnulib
modules in their own CVS repository, using some additinal process to
keep these in sync.   I think coreutils still does this.

The memebers of this list were very helpful during my transition.  I
derive significant benefits also from the fact that the other members
of the list are intensive users of the gnulib functionality.

One of the things I found most persistently difficult to figure out
(though my code has reached a steady-state at the moment) was what
needs to go before gl_EARLY, between gl_EARLY and gl_INIT, and what's
incompatible with both.  I've ended up with this in the configure.in
for findutils, which works for me:-
(Continue reading)

Permalink | Reply | 6 comments |
headers
Patrice Dumas | 3 Jul 2005 18:45
Picon
Favicon

strftime LGPL depends on GPL modules

Hi,

strftime which may be LGPL depends on tzset which dependes on gettimeofday and
both are GPL. Maybe it would be better to flag strftime as GPL or distribute 
tzset and gettimeofday as LGPL.

--
Pat
Permalink | Reply | 1 comment |

Gmane