Bruno Haible | 1 Sep 2010 01:29

Re: failure to build due to ignoring fwrite() result

Karl, all,

>    <at> pindex lint
> ! Don't make the program ugly to placate  <at> code{lint}.  Please don't insert any
> ! casts to  <at> code{void}.  Zero without a cast is perfectly fine as a null
> ! pointer constant, except when calling a varargs function.

Here is a proposed wording that
  - acknowledges the fact that there are different opinions among GNU
    maintainers (Chet Ramey wants few warnings, I use just -Wall, Jim
    uses also -Wshadow and some more, and Simon uses many more),
  - nevertheless tries to give reasonable advice.

Paul's mention of valgrind is a good one, because just like some people
ask us to remove all warnings that occur with -Wundef, others ask to
free all memory before a program exits, as a way to placate valgrind.

At first I wanted to propose this new paragraph:

-------------------------------------------------------------------------
 <at> cindex warnings, dealing with
 <at> pindex gcc
 <at> pindex valgrind
 <at> pindex clang
 <at> pindex lint
Don't make the program ugly just to placate warnings from tools other
than those that you use on a daily basis.   <at> code{gcc}'s warnings,
 <at> code{valgrind}'s memory leak checker,  <at> code{clang}'s static analysis
facilities, and code style checkers like  <at> code{lint} can be valuable
tools.  But if you try to placate too many warnings, the readability
(Continue reading)

Ludovic Courtès | 1 Sep 2010 14:30
Picon

Re: failure to build due to ignoring fwrite() result

Hi Bruno,

FWIW I’d prefer more “neutral” wording, which couldn’t be interpreted as
discouraging use of static analysis tools, and at the same time try to
discuss trade-offs rather than taste:

Bruno Haible <bruno <at> clisp.org> writes:

> --- doc/standards.texi.orig	Wed Sep  1 01:25:45 2010
> +++ doc/standards.texi	Wed Sep  1 01:24:09 2010

[...]

> + <at> pindex clang
> + <at> pindex lint
> +Don't make the program ugly just to placate warnings from tools other
> +than those that you use on a daily basis.  Extra GCC warnings options,
> + <at> code{clang}'s static analysis facilities, and code style checkers like
> + <at> code{lint} can be valuable tools.

(Shouldn’t it refer to Splint since I think the historical Lint isn’t
free?)

> But if you try to placate too many
> +warnings, the readability of the code will deteriorate.

What about something like this?

  However, placating warnings emitted by such tools should not be done
  at the expense of readability and maintainability.
(Continue reading)

Sam Steingold | 1 Sep 2010 22:04
Picon

module request: sockets.m4

Hi,
I want to include sockets.m4 and nothing else (I need LIBSOCKET to replace 
clisp/src/m4/socket.m4).
Is it possible to add a module which would only include that one file?
thanks
Sam.

Paul Eggert | 1 Sep 2010 22:49
Favicon

[PATCH] fcntl-h, etc.: prefer O_SEARCH to O_RDONLY when applicable

POSIX 2008 specifies a new 'open' flag O_SEARCH, which can be used
when one needs search access to a directory but not read access.
On systems where it is available, it works in some cases where
O_RDONLY does not, namely on directories that are searchable but
not readable, and which need only to be searchable.  If O_SEARCH
is not available, fall back to the traditional method of using
O_RDONLY.

* lib/fcntl.in.h (O_SEARCH): #define to O_RDONLY if not defined.
* lib/chdir-long.c (cdb_advance_fd): Use O_SEARCH, not O_RDONLY,
when opening a directory that needs only to be searchable.
* lib/chdir-safer.c (chdir_no_follow): Likewise.
* lib/fts.c (diropen, fts_open, fd_ring_check): Likewise.
* lib/openat-proc.c (openat_proc_name): Likewise.
* lib/openat.c (openat_needs_fchdir): Likewise.
* lib/save-cwd.c (save_cwd): Likewise.
* lib/savewd.c (savewd_save, savewd_chdir): Likewise.
---
 ChangeLog         |   22 ++++++++++++++++++++++
 lib/chdir-long.c  |    2 +-
 lib/chdir-safer.c |   11 +++++++----
 lib/fcntl.in.h    |    4 ++++
 lib/fts.c         |    6 +++---
 lib/openat-proc.c |    2 +-
 lib/openat.c      |    2 +-
 lib/save-cwd.c    |    2 +-
 lib/savewd.c      |    4 ++--
 9 files changed, 42 insertions(+), 13 deletions(-)

diff --git a/ChangeLog b/ChangeLog
(Continue reading)

Bruno Haible | 1 Sep 2010 22:52

Re: module request: sockets.m4

Hi Sam,

> I want to include sockets.m4 and nothing else (I need LIBSOCKET to replace 
> clisp/src/m4/socket.m4).
> Is it possible to add a module which would only include that one file?

You can get this file by invoking
   gnulib-tool --copy-file m4/sockets.m4 src/m4/socket.m4

But note that we don't guarantee stability (modulo changes listed in the NEWS
file) only for entire modules. In other words, the naming and contents of a .m4
file may change without notice.

Bruno

Jim Meyering | 1 Sep 2010 22:59
Gravatar

Re: [PATCH] fcntl-h, etc.: prefer O_SEARCH to O_RDONLY when applicable

Paul Eggert wrote:
> POSIX 2008 specifies a new 'open' flag O_SEARCH, which can be used
> when one needs search access to a directory but not read access.
> On systems where it is available, it works in some cases where
> O_RDONLY does not, namely on directories that are searchable but
> not readable, and which need only to be searchable.  If O_SEARCH
> is not available, fall back to the traditional method of using
> O_RDONLY.
>
> * lib/fcntl.in.h (O_SEARCH): #define to O_RDONLY if not defined.
> * lib/chdir-long.c (cdb_advance_fd): Use O_SEARCH, not O_RDONLY,
> when opening a directory that needs only to be searchable.
> * lib/chdir-safer.c (chdir_no_follow): Likewise.
> * lib/fts.c (diropen, fts_open, fd_ring_check): Likewise.
> * lib/openat-proc.c (openat_proc_name): Likewise.
> * lib/openat.c (openat_needs_fchdir): Likewise.
> * lib/save-cwd.c (save_cwd): Likewise.
> * lib/savewd.c (savewd_save, savewd_chdir): Likewise.

By the way, thanks for doing all of this (haven't looked in detail yet).
Once O_SEARCH hits systems we care about, these uses will plug what
should be the final hole in some directory-traversal code.
I.e., once this functionality is ubiquitous enough (and native *at
syscalls), there is no longer an argument to use chdir in a module like fts.

Paul Eggert | 1 Sep 2010 23:00
Favicon

Re: [PATCH] fcntl-h, etc.: prefer O_SEARCH to O_RDONLY when applicable

On 09/01/10 13:55, Jim Meyering wrote:

> I thought this was only a POSIX invention, so far.
> Does some system support it, now?

Cygwin claims to.

http://www.cygwin.com/cygwin-ug-net/ov-new1.7.html

I think Ulrich worked on this on the POSIX level, but
I don't know whether it'd be right to say that it's
Ulrich's invention.

Sam Steingold | 1 Sep 2010 22:57
Picon

Re: module request: sockets.m4

Hi Bruno,

On 9/1/10, Bruno Haible <bruno <at> clisp.org> wrote:
>
>  > I want to include sockets.m4 and nothing else (I need LIBSOCKET to replace
>  > clisp/src/m4/socket.m4).
>  > Is it possible to add a module which would only include that one file?
>
> You can get this file by invoking
>    gnulib-tool --copy-file m4/sockets.m4 src/m4/socket.m4

thanks.

>  But note that we don't guarantee stability (modulo changes listed in the NEWS
>  file) only for entire modules. In other words, the naming and contents of a .m4
>  file may change without notice.

Ok, so please do create a module and guarantee the stability. :-)

--

-- 
Sam Steingold <http://sds.podval.org>

Jim Meyering | 1 Sep 2010 22:55
Gravatar

Re: [PATCH] fcntl-h, etc.: prefer O_SEARCH to O_RDONLY when applicable

Paul Eggert wrote:
> POSIX 2008 specifies a new 'open' flag O_SEARCH, which can be used
> when one needs search access to a directory but not read access.
> On systems where it is available, ...

I thought this was only a POSIX invention, so far.
Does some system support it, now?

Jim Meyering | 1 Sep 2010 23:14
Gravatar

Re: [PATCH] fcntl-h, etc.: prefer O_SEARCH to O_RDONLY when applicable

Paul Eggert wrote:
> On 09/01/10 13:55, Jim Meyering wrote:
>> I thought this was only a POSIX invention, so far.
>> Does some system support it, now?
>
> Cygwin claims to.
>
> http://www.cygwin.com/cygwin-ug-net/ov-new1.7.html

Looks like Solaris may have it, too:

  http://opensolaris.org/jive/message.jspa?messageID=494761#494761

I hope Linux isn't too far behind.


Gmane