headers
Jim Meyering | 2 Feb 2006 22:35
Gravatar

Re: module 'fts-lgpl' not complete

Bruno Haible <bruno <at> clisp.org> wrote:
>> Regarding the second patch, I see no explanation for why it
>> makes such a fundamental change (not appending `.'?).
>
> Actually the end of that function was a bit incomplete. It should probably
> look like this:
...

Thanks for the suggestion.
I've applied a similar patch for coreutils.
One difference is the use of ENOTDIR rather than EINVAL,
since that what lstat does for names like "non-dir/.".

I don't particularly like using stat to simulate lstat, but
in this case it seems worthwhile and safe.
I'll propagate this change to gnulib once it's undergone a little testing.

2006-02-02  Jim Meyering  <jim <at> meyering.net>

	Eliminate the unwelcome (albeit unlikely) possibility of xmalloc
	failure on deficient systems, and simplify gnulib lgpl dependencies.
	* lstat.c (rpl_lstat): Rewrite to use stat() in place of the
	xmalloc/lstat combination.  Based on a patch from Bruno Haible.

Index: lib/lstat.c
===================================================================
RCS file: /fetish/cu/lib/lstat.c,v
retrieving revision 1.10
retrieving revision 1.11
diff -c -r1.10 -r1.11
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bruno Haible | 4 Feb 2006 18:15

Re: module 'fts-lgpl' not complete

Jim Meyering wrote:
> One difference is the use of ENOTDIR rather than EINVAL,
> since that what lstat does for names like "non-dir/.".

You're right. Thanks.

Bruno
Permalink | Reply | 0 comments |
headers
Paul Eggert | 6 Feb 2006 06:29
Favicon

extensions.m4 patch for Solaris 10 Sun C 5.7 c89 and some -D options

In <http://lists.gnu.org/archive/html/bug-bison/2005-09/msg00021.html>
Nelson H. F. Beebe summarized the following problem with building
Bison 2.1 on Solaris 10 with Sun C 5.7 c89 -D_XOPEN_SOURCE
-D_XOPEN_SOURCE_EXTENDED:

/opt/SUNWspro/bin/c89 -DHAVE_CONFIG_H -I. -I. -I..   -I/usr/local/include  -D_XOPEN_SOURCE
-D_XOPEN_SOURCE_EXTENDED=1 -I/usr/local/include -c subpipe.c
"/usr/include/sys/types.h", line 487: warning: useless declaration
"/usr/include/sys/types.h", line 487: warning: typedef declares no type name
"/usr/include/sys/regset.h", line 304: syntax error before or at: uint64_t
"/usr/include/sys/regset.h", line 307: syntax error before or at: uint64_t
c89: acomp failed for subpipe.c

I tracked this down, I think, to a bug in Solaris 10's system headers
when compiled with c89 -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED
-D__EXTENSIONS__.  With that combination, you cannot compile a simple
file containing only "#include <stdlib.h>" because types like uint64_t
are used without being defined.

I installed this patch to work around the problem: it causes
"configure" to not defined __EXTENSIONS__ in this case.  This
is installed into both gnulib and coreutils.

2006-02-05  Paul Eggert  <eggert <at> cs.ucla.edu>

	* extensions.m4 (gl_USE_SYSTEM_EXTENSIONS): Don't #define
	__EXTENSIONS__ if this causes compilation to fail.  Problem
	reported by Nelson H. F. Beebe with Solaris 10 and Sun C 5.7
	c89 -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Eggert | 8 Feb 2006 01:06
Favicon

closeout portability fix for pre-C99 stdbool.h

I installed this into gnulib (and soon into coreutils):

2006-02-07  Paul Eggert  <eggert <at> cs.ucla.edu>

	* closeout.c (close_stdout): Don't assume 'bool' converts nonzero
	ints to 0 or 1, as this isn't true for the stdbool.h substitute.

--- closeout.c	19 Sep 2005 17:28:14 -0000	1.18
+++ closeout.c	8 Feb 2006 00:04:23 -0000	1.19
 <at>  <at>  -1,7 +1,7  <at>  <at> 
 /* closeout.c - close standard output

-   Copyright (C) 1998, 1999, 2000, 2001, 2002, 2004 Free Software
-   Foundation, Inc.
+   Copyright (C) 1998, 1999, 2000, 2001, 2002, 2004, 2006 Free
+   Software Foundation, Inc.

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
 <at>  <at>  -73,9 +73,9  <at>  <at>  close_stdout_set_file_name (const char *
 void
 close_stdout (void)
 {
-  bool prev_fail = ferror (stdout);
-  bool none_pending = (0 == __fpending (stdout));
-  bool fclose_fail = fclose (stdout);
+  bool none_pending = (__fpending (stdout) == 0);
+  bool prev_fail = (ferror (stdout) != 0);
+  bool fclose_fail = (fclose (stdout) != 0);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Eggert | 8 Feb 2006 01:07
Favicon

closeout doesn't depend on atexit

I installed this to fix an overdependency in gnulib:

2006-02-07  Paul Eggert  <eggert <at> cs.ucla.edu>

	* modules/closeout (Depends-on): Remove atexit.

--- modules/closeout	6 Jul 2005 15:58:47 -0000	1.12
+++ modules/closeout	8 Feb 2006 00:04:08 -0000	1.13
 <at>  <at>  -7,7 +7,6  <at>  <at>  lib/closeout.c
 m4/closeout.m4

 Depends-on:
-atexit
 gettext-h
 error
 quotearg
Permalink | Reply | 0 comments |
headers
Simon Josefsson | 8 Feb 2006 12:04

Re: socket.h

Jim Meyering <jim <at> meyering.net> writes:

>> I agree.  I wish 'indent' could fix this
>> too.  Maybe it can?  Even if I agree many code writing ideas given
>> here, I forget them all the time.
>
> I tend to forget, too, so have automated quite a few policy checks,
> over the years.  You might try adding some checks like those in coreutils'
> Makefile.maint.  Here are the syntax-check (sc) target names:

These are very useful tests.  I'd like to adopt them in my projects.
Is there some way they could be moved to gnulib?  And perhaps
modularize them somewhat.  For example, even if I currently use CVS
for my projects, separating out the tests that assume CVS seems like a
good idea.

Scripts like gnupload, announce-gen, etc may also be useful to move to
gnulib?
Permalink | Reply | 8 comments |
headers
Jim Meyering | 8 Feb 2006 14:16
Gravatar

rules, rules, and more (code policy) rules

Simon Josefsson <jas <at> extundo.com> wrote:
> Jim Meyering <jim <at> meyering.net> writes:
>> I tend to forget, too, so have automated quite a few policy checks,
>> over the years.  You might try adding some checks like those in coreutils'
>> Makefile.maint.  Here are the syntax-check (sc) target names:
>
> These are very useful tests.  I'd like to adopt them in my projects.
> Is there some way they could be moved to gnulib?  And perhaps
> modularize them somewhat.  For example, even if I currently use CVS
> for my projects, separating out the tests that assume CVS seems like a
> good idea.

Hi Simon,

Nearly all of those rules -- certainly the new ones -- require a version
control system.  For coreutils, I'm still using cvs, but it should be easy
to adapt to others.  The main functionality required is to be able to list
all of the version-controlled files so that we don't get false positives
on non-version-controlled (e.g., generated) files that happen to be in a
working directory.  Currently that's done by the build-aux/cvsu script.
Tweaking things to work also for svn, monotone, git, arch, mercurial, svk,
etc. shouldn't be hard.

You're welcome to generalize/modularize/whatever things and put the
result in gnulib.  Be aware that some of the rules enforce controversial
(to Bruno, at least :-) policies, so it may not be reasonable to apply
them to all of gnulib.  But that's why every rule has an exclusion mechanism.

Also, if you want to skip some of these syntax-check tests altogether,
just define a Make variable, local-checks-to-skip, and set it to the
(Continue reading)

Permalink | Reply | 7 comments |
headers
Simon Josefsson | 10 Feb 2006 18:43

Re: rules, rules, and more (code policy) rules

A lot of the tests look like:

sc_cast_of_argument_to_free:
	 <at> grep -E '\<free \(\(' $(srcdir)/{lib,src}/*.[chly] &&		\

I.e., the paths and filenames are hardcoded.

Using 'find . -name *.[chly]` seem more appropriate.  Or?

Some tests do:

sc_space_tab:
	 <at> ( $(CVS_LIST) ) > /dev/null 2>&1 || : &&			\

where CVS_LIST is:

# cvsu is part of the cvsutils package: http://www.red-bean.com/cvsutils/
CVS_LIST = $(srcdir)/build-aux/cvsu --find --types=AFGM

This has the problem of being tied to cvs.  Even if that could be
fixed, I'm not sure there is any advantage over the above solution.
Sometimes testing generated source code files is useful too.  I'm
thinking of foo.h.in and generated source code files (libidn has a few
of these).  You won't get that if you only test all files in CVS.

I'll go with

C_SOURCE_LIST=`find . -name *.[chly]'

unless someone has better ideas.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jim Meyering | 10 Feb 2006 23:49
Gravatar

Re: rules, rules, and more (code policy) rules

Simon Josefsson <jas <at> extundo.com> wrote:

> A lot of the tests look like:
>
> sc_cast_of_argument_to_free:
> 	 <at> grep -E '\<free \(\(' $(srcdir)/{lib,src}/*.[chly] &&		\
>
> I.e., the paths and filenames are hardcoded.

Some are definitely tailored to the classic gnu lib,src lay-out --
or were just written a long time ago :-)
Just using $(CVS_LIST) might be better.

> Using 'find . -name *.[chly]` seem more appropriate.  Or?
>
> Some tests do:
>
> sc_space_tab:
> 	 <at> ( $(CVS_LIST) ) > /dev/null 2>&1 || : &&			\
>
> where CVS_LIST is:
>
> # cvsu is part of the cvsutils package: http://www.red-bean.com/cvsutils/
> CVS_LIST = $(srcdir)/build-aux/cvsu --find --types=AFGM
>
> This has the problem of being tied to cvs.  Even if that could be
> fixed, I'm not sure there is any advantage over the above solution.
> Sometimes testing generated source code files is useful too.

It's useful if you `own' the tool that does the generating or otherwise
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jim Meyering | 10 Feb 2006 18:48
Gravatar

Re: rules, rules, and more (code policy) rules

Simon Josefsson <jas <at> extundo.com> wrote:
> I'm going through Coreutils GNUmakefile and Makefile.maint to identify
> useful rules.  Some question pop up:
>
> 1)
>
> Is this rule generally safe?  Does it assume GNU tar?  Is there a real
> problem solved by this, or is it just "nice"?
>
> # Make tar archive easier to reproduce.
> export TAR_OPTIONS = --owner=0 --group=0 --numeric-owner

Those options help minimize unnecessary differences between tar archives.

> Further, shouldn't automake set this, if it is safe?

They're all gnu-tar-specific.
In Makefile.maint, I've tried to keep things simple, and
independent of automake/autoconf/etc.  However, I do assume
that you (the developer) have GNU tools like tar, grep, and make.

> 2)
>
> The following is not safe, --rsyncable is a new feature.
>
> # Do not save the original name or timestamp in the .tar.gz file.
> GZIP_ENV = '--no-name --best --rsyncable'
>
> Perhaps this, and the previous case, should be moved to a m4 macro, to
> find out whether the parameters are supported or not.  Thoughts?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane