Re: untabify - last call for objections

Bruno Haible wrote: >> *** NEWS.orig2009-12-09 20:16:50.0 +0100 >> --- NEWS 2009-12-09 19:39:00.0 +0100 >> *** >> *** 6,11 >> --- 6,15 >> >> DateModules Changes >> >> + 2009-12-09 * Most source code files have been c

Re: add pipe2-safer

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 12/10/2009 6:19 PM: > Is there any reason why the pipe2_safer code is not in a file of its own? Only because unistd-safer didn't split fd_safer_flag and dup_safer_flag into separate files. > Here is a proposed patch: It

Re: add pipe2-safer

Eric Blake wrote on 2009-12-06: > pipe2-safer: new module > Add pipe2_safer, and use it in the pipe module. Is there any reason why the pipe2_safer code is not in a file of its own? It's nice to be able to guess the file which contains a particular function, without resorting to 'grep -r'. A

Re: [PATCH] non-null declarations

Hi Dmitry, > Potential drawback of this approach is that these declarations may affect > the implementation as well: there is a risk that compiler may optimize out > NULL checks. In other projects where this issue arose before it was > worked around by disabling non-null declarations in implement

Re: non-null declarations, recvfrom, sendto

On 12/11/2009 12:44 AM, Bruno Haible wrote: But this also means that our recvfrom wrapper makes invalid memory accesses. Here is a proposed patch: 2009-12-10 Bruno Haible * lib/recvfrom.c (rpl_recvfrom): Allow the from argument to be NULL. --- lib/recvfrom.c.orig 2009-12-11 00:33:28.

Re: non-null declarations, recvfrom, sendto

Hi Eric, Paolo, Simon, About sendto, I wrote: > > > -extern int rpl_sendto (int, const void *, int, int, struct sockaddr *, > > > int); > > > +extern int rpl_sendto (int, const void *, int, int, struct sockaddr *, > > > int) > > > + _GL_ARG_NONNULL ((2, 5)); > > > > Bug: Arg 5 can be NULL,

fcntl for mingw

Here's what I'm currently playing with. I'll wait another day or two for any comments, first; but it passes for me on Linux, cygwin 1.5, cygwin 1.7, and mingw. Eric Blake (4): [1/4] fcntl: support F_DUPFD_CLOEXEC on systems with fcntl Provide POSIX semantics (minus the atomicity factor) i

Re: pty.h replacement

Bruno Haible writes: > The reason is that libgnu.a is not being included in the link > line. This fixes it: Thanks. Strange that it didn't happen on my system. /Simon

Re: [PATCH] non-null declarations

Hi, On Thu, Dec 10, 2009 at 03:36:18PM +0100, Bruno Haible wrote: > > Here's a proposed patch for introducing some __nonnull__ declarations. For > a start, I'm focusing on gnulib's replacement files lib/*.in.h, because these > declare the most often used functions. Potential drawback of this app

Re: [PATCH] non-null declarations

Eric Blake writes: > Ben Pfaff cs.stanford.edu> writes: >> ISO C99 requires that memchr's argument be nonnull even if __c is >> zero, as follows. 7.21.1 "String function conventions" says that >> pointer arguments must be valid even if the number of bytes is 0: > > But POSIX made the requiremen

Re: untabify - last call for objections

> *** NEWS.orig 2009-12-09 20:16:50.0 +0100 > --- NEWS 2009-12-09 19:39:00.0 +0100 > *** > *** 6,11 > --- 6,15 > > DateModules Changes > > + 2009-12-09 * Most source code files have been converted to > +

getenv relaxation (was: [PATCH] non-null declarations)

Bruno Haible clisp.org> writes: > > [about setenv and unsetenv] > > given the Austin Group feedback, I'll go ahead and relax our > > setenv implementation to no longer reject BSD solely on the basis of failure to > > handle null, and our testsuite to no longer call setenv(NULL,,). > > Yes, th

Re: [PATCH] non-null declarations

Ben Pfaff cs.stanford.edu> writes: > >> extern void *memchr (void const *__s, int __c, size_t __n) > >> - __attribute__ ((__pure__)); > >> + __attribute__ ((__pure__)) _GL_ARG_NONNULL ((1)); > > > > This one I'm fuzzy on. On one hand, the POSIX definition is that the function > > reads a

Re: untabify - last call for objections

I'm not sure `indent` is being kept up to date TBH. As Simon mentioned, David Ingamells released indent 2.2.10 early this year after a lapse of some years. So perhaps sending a report to bug-indent about the missing type definitions, etc. would have some effect. -l80 I strongly suggest

Re: [PATCH] non-null declarations

On Thu, Dec 10, 2009 at 19:41, Bruno Haible wrote: > Paolo Bonzini wrote: >> accept4 has to be fixed to use ((2, 3)). :-) > > No, the second arg of accept4 can be NULL. See >   >  "When addr is NULL, nothing is filled in; in thi

Re: [PATCH] non-null declarations

Paolo Bonzini wrote: > accept4 has to be fixed to use ((2, 3)). :-) No, the second arg of accept4 can be NULL. See "When addr is NULL, nothing is filled in; in this case, addrlen is not used, and should also be NULL." I

Re: [PATCH] non-null declarations

Eric Blake wrote: > [about scandir] > > > Is there any desire to provide guaranteed extension semantics that cmp > > > can be > > > NULL in order to get an unsorted subset returned? > > > > I don't think this would be portable. You can in any case get an unsorted > > result by passing a cmp func

Re: pty.h replacement

Simon Josefsson wrote: > > Subject: [PATCH] Add pty module for forkpty and openpty. > > I have pushed that patch I get a link error when building all of gnulib together: gcc -std=gnu99 -g -O2 -Wl,--as-needed -o test-pty test-pty.o -lutil -lm test-pty.o: In function `main': /home/bruno/

Re: [PATCH] non-null declarations

Bruno Haible clisp.org> writes: > > > extern int scandir (const char *dir, struct dirent ***namelist, > > > int (*filter) (const struct dirent *), > > > - int (*cmp) (const struct dirent **, const struct dirent **)); > > > + int (*cmp) (const struct dirent

Re: [PATCH] non-null declarations

Hi Eric, Thanks for the detailed review! Eric Blake wrote: > > - Is it worth putting the macro definition (always the same 10 lines of > > code) > > into a separate file, like done with link-warning.h? > > I'd go one step further - I'd like to see it in config.h The reason for putting it

Re: [PATCH] non-null declarations

On Thu, Dec 10, 2009 at 18:12, Bruno Haible wrote: > Paolo Bonzini wrote: >> do you plan on adding 2-argument versions of the macro, such as >> _GL_ARG_NONNULL2? > > The macro already supports multiple parameter indices. Example: > > extern int scandir (const char *dir, struct dirent ***namelist,

Re: [PATCH] non-null declarations

Eric Blake writes: >> extern void *memchr (void const *__s, int __c, size_t __n) >> - __attribute__ ((__pure__)); >> + __attribute__ ((__pure__)) _GL_ARG_NONNULL ((1)); > > This one I'm fuzzy on. On one hand, the POSIX definition is that the > function > reads at most __c bytes, so when

Re: [PATCH] non-null declarations

Paolo Bonzini wrote: > do you plan on adding 2-argument versions of the macro, such as > _GL_ARG_NONNULL2? The macro already supports multiple parameter indices. Example: extern int scandir (const char *dir, struct dirent ***namelist, int (*filter) (const struct dirent *),

Re: [PATCH] non-null declarations

Bruno Haible clisp.org> writes: > Two points I'm not sure about: > - Should the macro be called _GL_ARG_NONNULL or GL_ARG_NONNULL? _GL_ARG_NONNULL is in the implementation-reserved namespace, so it is less likely to collide, but it is also more to type. I don't really care one way or anothe

Re: untabify - last call for objections

Pádraig Brady writes: >> I don't care much about coding styles conventions, but I care about >> consistency. Moving away from the default style of GNU indent in gnulib >> seems a bit inconsistent to me. I can't find anything about tab vs >> space in the coding standard though. Thoughts? > > I'

Re: untabify, coding standards

Bruno Haible writes: > Simon Josefsson wrote: >> Is this style something we want to try push into the GNU Coding Standard >> and/or into the GNU indent default? >> >> I don't care much about coding styles conventions, but I care about >> consistency. Moving away from the default style of GNU in

Re: [PATCH] non-null declarations

>> I put __nonnull__ declarations >>   1) in places where passing a NULL pointer leads to undefined behaviour, >>   2) in places where POSIX says that the function will always fail when a >> NULL >>      pointer is passed. (For example: tsearch.) >> glibc uses __nonnull__ declarations only for cas

Re: untabify - last call for objections

On 10/12/09 14:33, Simon Josefsson wrote: Bruno Haible writes: Simon Josefsson wrote: Is there a need to modify how 'indent' works here? Or document how to make indent do the right thing? When making substantial changes to gnulib code, I tend to run 'indent' on the code to make sure I'm fol

Re: [PATCH] non-null declarations

Bruno Haible wrote: > Here's a proposed patch for introducing some __nonnull__ declarations. For > a start, I'm focusing on gnulib's replacement files lib/*.in.h, because these > declare the most often used functions. > > I put __nonnull__ declarations > 1) in places where passing a NULL pointer

Re: untabify, coding standards

Simon Josefsson wrote: > Is this style something we want to try push into the GNU Coding Standard > and/or into the GNU indent default? > > I don't care much about coding styles conventions, but I care about > consistency. Moving away from the default style of GNU indent in gnulib > seems a bit i

Re: [PATCH] non-null declarations

Bruno Haible writes: > Opinions? Objections? Looks fine to me. I didn't test it, but obviously I'll report back if it breaks anything. /Simon

Re: untabify - last call for objections

Bruno Haible writes: > Simon Josefsson wrote: >> Is there a need to modify how 'indent' works here? Or document how to >> make indent do the right thing? When making substantial changes to >> gnulib code, I tend to run 'indent' on the code to make sure I'm >> following the right style -- but th

Re: __nonnull__ declarations

Jim Meyering wrote: > > Arguments for doing it: > > - Allows GCC to produce its warning when passed a literal NULL value. > > - An added piece of documentation (but only when done completely, > > throughout gnulib). > > - Allows tools like the clang static analyzer to avoid warning abo

Re: untabify - last call for objections

Simon Josefsson wrote: > Is there a need to modify how 'indent' works here? Or document how to > make indent do the right thing? When making substantial changes to > gnulib code, I tend to run 'indent' on the code to make sure I'm > following the right style -- but that would add tabs, wouldn't i

Re: pty.h replacement

Simon Josefsson writes: > Subject: [PATCH] Add pty module for forkpty and openpty. I have pushed that patch -- it added a new module, so it should have minimal impact on existing code. If there is any problem with it, we'll find out when InetUtils starts to use it. /Simon

Re: windows.h: No such file or directory

Eric Blake wrote on 2009-09-07: > I'm pushing this, which improves the rename module (after first making the > stdio module easier to modify) to cross-compile to non-mingw scenarios. > ... > --- a/lib/stdio.in.h > +++ b/lib/stdio.in.h > @@ -416,6 +416,20 @@ extern int putchar (int c); > extern int

Re: untabify - last call for objections

Simon Josefsson wrote: > Is there a need to modify how 'indent' works here? Or document how to > make indent do the right thing? When making substantial changes to > gnulib code, I tend to run 'indent' on the code to make sure I'm > following the right style -- but that would add tabs, wouldn't i

Re: untabify - last call for objections

Is there a need to modify how 'indent' works here? Or document how to make indent do the right thing? When making substantial changes to gnulib code, I tend to run 'indent' on the code to make sure I'm following the right style -- but that would add tabs, wouldn't it? /Simon

Re: add license to link-warning.h

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 12/10/2009 4:37 AM: > Well, as a matter of readability, I use a '-e' (or '-f') option in every 'sed' > invocation. And the autoconf manual recommends against blindly using -e: http://www.gnu.org/software/autoconf/manual/a

Re: add license to link-warning.h

Eric Blake wrote: > > Plus a useless use of cat, for a total of 3 processes? Come on, we can do > > better than that. In Makefile rules that are executed exactly once per build, I focus on correctness and maintainability, not on optimization. > > sed -n '/GL_LINK_WARNING/,$$ p' $(top_srcdir)/bu

[PATCH] mgetgroups: do not write bytes beyond end of malloc'd buffer

FYI, without this patch, coreutils' "./id" would have written past end-of-malloc'd buffer when using the latest from gnulib: >From 51d5e813e9ee6cf23af6c3e96082dc6ecd46d194 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 10 Dec 2009 12:17:19 +0100 Subject: [PATCH] mgetgroups: do not write b

Re: doc vs. README

Hi Karl, > *** README.orig 2009-12-09 20:16:50.0 +0100 > --- README2009-12-09 19:36:18.0 +0100 > > How about adding everything in README to gnulib.texi, and generating it? > > The README grows and grows, in both length and importance ... Yes, you are right. 2/3

Re: untabify - last call for objections

Pádraig Brady wrote: > s/Spacer/Spaces/ > > Spaces make me much happier. > Note after this patch `git blame` is useless without the -w option > so I would mention that somewhere. Good point. I'll add this sentence to the README: When you use "git annotate" or "git blame" with gnulib, it's reco