Re: [PATCH] fatal-signal: silence coverity warning

On 29/04/11 22:15, Pádraig Brady wrote: > On 29/04/11 22:00, Jim Meyering wrote: >> Eric Blake wrote: >>> On a glibc system, Coverity gives this warning: >>> >>> Error: UNINIT: >>> m4-1.4.16/lib/fatal-signal.c:183: var_decl: Declaring variable "action" >>> without initializer. >>> m4-1.4.16/lib/fa

Re: Emacs local variables

Reuben Thomas wrote: > On 29 April 2011 21:48, Bruno Haible wrote: >> >> But first, did you try / are you using the code from gnulib/README? >> >>      ;; In gnulib, indent with spaces everywhere (not TABs). >>      ;; Exceptions: Makefile and ChangeLog modes. >>      (add-hook 'find-file-hook '(

Re: announce-gen

Reuben Thomas wrote: > On 29 April 2011 21:48, Jim Meyering wrote: >> >> Please make that a separate change. > > Attached a patch made with vc-dwim :) ... > Subject: [PATCH] announce-gen: cosmetic improvement > > * build-aux/announce-gen: strip any leading ./ from the NEWS file. Thanks. Pushed w

Re: [PATCH] fatal-signal: silence coverity warning

Eric Blake wrote: > On 04/29/2011 05:18 PM, Pádraig Brady wrote: I think the case for clearing the bits is a little stronger than the one for leaving them uninitialized, and would be even more in favor, it if only this initialization were portable: struct sigaction action

Re: Emacs local variables

On 29 April 2011 21:58, Reuben Thomas wrote: > > And now I cannot get whitespace-mode to work with ChangeLogs, because > while the body of ChangeLog entries require leading tabs, the second > and subsequent lines of author headers require leading spaces. So I > guess I have to turn off whitespace-

Re: [PATCH] fatal-signal: silence coverity warning

Eric Blake wrote: > On a glibc system, Coverity gives this warning: > > Error: UNINIT: > m4-1.4.16/lib/fatal-signal.c:183: var_decl: Declaring variable "action" > without initializer. > m4-1.4.16/lib/fatal-signal.c:198: uninit_use_in_call: Using uninitialized > value "action": field "action".sa_

Re: announce-gen

If no one else feels strongly enough about this to speak up, I'm willing to drop the "-", I don't feel strongly about it either way, but FWIW, the majority of Subject: lines in the info-gnu archives for this month use the real package name and a space. So, as long as we're talking "coreu

gnulib fclose caused m4 regression for mingw

I imported the fclose module into m4 just prior to releasing m4 1.4.16, on the advice of GNULIB_POSIXCHECK. The gnulib fclose module replaces fclose if and only if close is also replaced, which is the case on mingw if sockets might be involved. However, the fclose module blindly calls fflush(), e

Re: [PATCH] fatal-signal: silence coverity warning

On 04/29/2011 05:18 PM, Pádraig Brady wrote: >>> I think the case for clearing the bits is a little >>> stronger than the one for leaving them uninitialized, and would >>> be even more in favor, it if only this initialization were portable: >>> >>> struct sigaction action = {0,}; What would make

Re: VC-tag again

On 29 April 2011 20:51, Reuben Thomas wrote: > On 29 April 2011 20:49, Jim Meyering wrote: >> >> Hmm... in grep's README-release, I count five URLs containing >> the package name: >> >>    http://hydra.nixos.org/jobset/gnu/grep-master >>    https://savannah.gnu.org/projects/grep/ >>    https://sa

Re: [PATCH] fatal-signal: silence coverity warning

On 29/04/11 22:00, Jim Meyering wrote: > Eric Blake wrote: >> On a glibc system, Coverity gives this warning: >> >> Error: UNINIT: >> m4-1.4.16/lib/fatal-signal.c:183: var_decl: Declaring variable "action" >> without initializer. >> m4-1.4.16/lib/fatal-signal.c:198: uninit_use_in_call: Using unini

Re: announce-gen

On 29 April 2011 21:48, Jim Meyering wrote: > > Please make that a separate change. Attached a patch made with vc-dwim :) > If no one else feels strongly enough about this to > speak up, I'm willing to drop the "-", but let's defer > that change until README-release is in gnulib, so that > you c

Re: Emacs local variables

On 29 April 2011 22:02, Eric Blake wrote: > On 04/29/2011 02:58 PM, Reuben Thomas wrote: >> And now I cannot get whitespace-mode to work with ChangeLogs, because >> while the body of ChangeLog entries require leading tabs, the second >> and subsequent lines of author headers require leading spaces

Re: [PATCH] fatal-signal: silence coverity warning

On 04/29/2011 02:46 PM, Eric Blake wrote: > On a glibc system, Coverity gives this warning: > > Error: UNINIT: > m4-1.4.16/lib/fatal-signal.c:183: var_decl: Declaring variable "action" > without initializer. > m4-1.4.16/lib/fatal-signal.c:198: uninit_use_in_call: Using uninitialized > value "act

Re: Emacs local variables

On 04/29/2011 02:58 PM, Reuben Thomas wrote: > And now I cannot get whitespace-mode to work with ChangeLogs, because > while the body of ChangeLog entries require leading tabs, the second > and subsequent lines of author headers require leading spaces. Huh? Where is that requirement written? I'v

Re: [PATCH] fatal-signal: silence coverity warning

Eric Blake wrote: > On a glibc system, Coverity gives this warning: > > Error: UNINIT: > m4-1.4.16/lib/fatal-signal.c:183: var_decl: Declaring variable "action" > without initializer. > m4-1.4.16/lib/fatal-signal.c:198: uninit_use_in_call: Using uninitialized > value "action": field "action".sa_r

Re: Emacs local variables

On 29 April 2011 21:48, Bruno Haible wrote: > > But first, did you try / are you using the code from gnulib/README? > >      ;; In gnulib, indent with spaces everywhere (not TABs). >      ;; Exceptions: Makefile and ChangeLog modes. >      (add-hook 'find-file-hook '(lambda () >        (if (and bu

Re: Emacs local variables

Hi Reuben, > Basically, the bug (at least in 23.3) is that when a file's mode is > set by its local variables, as in the case for example of > announce-gen, then any directory-local variables are ignored. > > To work around this, would it be alright to add a setting for > indent-tabs-mode to such

Re: announce-gen

Reuben Thomas wrote: > On 29 April 2011 21:21, Jim Meyering wrote: >> Reuben Thomas wrote: >>> I'm trying to prepare a small cosmetic patch to fix up a couple of >>> things I find myself manually fixing up: >>> >>> 1. "./NEWS". I considered replacing this with the basename of the NEWS >>> file, bu

[PATCH] fatal-signal: silence coverity warning

On a glibc system, Coverity gives this warning: Error: UNINIT: m4-1.4.16/lib/fatal-signal.c:183: var_decl: Declaring variable "action" without initializer. m4-1.4.16/lib/fatal-signal.c:198: uninit_use_in_call: Using uninitialized value "action": field "action".sa_restorer is uninitialized when c

Re: announce-gen

On 29 April 2011 21:21, Jim Meyering wrote: > Reuben Thomas wrote: >> I'm trying to prepare a small cosmetic patch to fix up a couple of >> things I find myself manually fixing up: >> >> 1. "./NEWS". I considered replacing this with the basename of the NEWS >> file, but in fact it seems to me it's

Re: announce-gen

Reuben Thomas wrote: > I'm trying to prepare a small cosmetic patch to fix up a couple of > things I find myself manually fixing up: > > 1. "./NEWS". I considered replacing this with the basename of the NEWS > file, but in fact it seems to me it's better to use the literal "NEWS" > since that makes

--disable-rpath does not work for me

Hi, I am trying to create a configure / autotools setup for my package in which the --disable-rpath option avoids any hardcoded rpaths in the final program output. I have a simple testcase that I'd like to get this working in: http://pages.netdirect.ca/~cdfrey/disable-rpath-0.1.tar.gz I

Re: announce-gen

Jim Meyering wrote: > Eric Blake wrote: >> On 04/29/2011 01:51 PM, Reuben Thomas wrote: >>> I'm trying to prepare a small cosmetic patch to fix up a couple of >>> things I find myself manually fixing up: >>> >>> 1. "./NEWS". I considered replacing this with the basename of the NEWS >>> file, but in

Re: announce-gen

On 04/29/2011 02:02 PM, Jim Meyering wrote: > Hmm... vc-list-files has the same problem, > though in its case I'll convert only the leading TABs, > since some are used to align backslashes, and I have > a slight preference for TABs there. Leading tab indentation is different than mid-line tab usag

Re: announce-gen

Eric Blake wrote: > On 04/29/2011 01:51 PM, Reuben Thomas wrote: >> I'm trying to prepare a small cosmetic patch to fix up a couple of >> things I find myself manually fixing up: >> >> 1. "./NEWS". I considered replacing this with the basename of the NEWS >> file, but in fact it seems to me it's be

Re: announce-gen

On 04/29/2011 01:51 PM, Reuben Thomas wrote: > I'm trying to prepare a small cosmetic patch to fix up a couple of > things I find myself manually fixing up: > > 1. "./NEWS". I considered replacing this with the basename of the NEWS > file, but in fact it seems to me it's better to use the literal

Re: VC-tag again

On 29 April 2011 20:49, Jim Meyering wrote: > > Hmm... in grep's README-release, I count five URLs containing > the package name: > >    http://hydra.nixos.org/jobset/gnu/grep-master >    https://savannah.gnu.org/projects/grep/ >    https://savannah.gnu.org/project/admin/editgroupfeatures.php?grou

announce-gen

I'm trying to prepare a small cosmetic patch to fix up a couple of things I find myself manually fixing up: 1. "./NEWS". I considered replacing this with the basename of the NEWS file, but in fact it seems to me it's better to use the literal "NEWS" since that makes more sense in the email. What d

Re: VC-tag again

Reuben Thomas wrote: > On 29 April 2011 19:40, Jim Meyering wrote: >> Do you want to create a gnulib module? > > Sure. > >> It would arrange in its modules file to include a template (via Files:), >> and add a Makefile rule (via its Makefile.am: section) to substitute >> the package name into the

Emacs local variables

I've just been puzzling out a bug in Emacs which stops me correcting my setting of indent-tabs-mode to t for GNU files (I have it customized to nil). Basically, the bug (at least in 23.3) is that when a file's mode is set by its local variables, as in the case for example of announce-gen, then any

Re: VC-tag again

On 29 April 2011 19:40, Jim Meyering wrote: > Do you want to create a gnulib module? Sure. > It would arrange in its modules file to include a template (via Files:), > and add a Makefile rule (via its Makefile.am: section) to substitute > the package name into the numerous slots in the template

Release of version 4.11.1 of sharutils

GNU sharutils consists of two pairs of utilities: shar and unshar, and uuencode and uudecode. "shar" makes so-called shell archives out of many files, preparing them for transmission by electronic mail services (converting binary data to ascii representations, breaking the text into multiple shar

Re: VC-tag again

Reuben Thomas wrote: > On 29 April 2011 19:26, Jim Meyering wrote: >> >> I think it's time, if you're interested. > > I am. Is there anything for me to do here? I can't quite tell from > reading what you wrote. Do you want to create a gnulib module? It would arrange in its modules file to includ

Re: VC-tag again

On 29 April 2011 19:26, Jim Meyering wrote: > > I think it's time, if you're interested. I am. Is there anything for me to do here? I can't quite tell from reading what you wrote. -- http://rrt.sc3d.org

Re: sharutils-4.11 does not compile on Solaris

On 04/26/11 12:48, Bruce Korb wrote: 1. call autopoint 2. call gnulib-tool --import 3. call "AUTOPOINT=true autoreconf ..." Done. Please be kind enough to test the version you can find here: ftp://ftp.gnu.org/gnu/sharutils/sharutils-4.11.1.tar.bz2 Announcement is forthcoming.

Re: VC-tag again

Reuben Thomas wrote: > On 29 April 2011 18:00, Jim Meyering wrote: >> Not sure what the question is. >> I don't think we need to replace it with anything. > > My question was, is it worth putting (coreutils's?) README-release > into gnulib as a general template README-release? I think it's time,

Re: VC-tag again

On 29 April 2011 18:00, Jim Meyering wrote: > Not sure what the question is. > I don't think we need to replace it with anything. My question was, is it worth putting (coreutils's?) README-release into gnulib as a general template README-release? -- http://rrt.sc3d.org

Re: [PATCH] quotearg: avoid uninitialized variable use

On 04/29/2011 10:55 AM, Jim Meyering wrote: >> When custom_quoting_style was introduced in commit 12247f77, >> this method was not updated, so any caller that passed >> the new enum value to any of the existing quotearg_*style >> functions could trigger a crash from the uninitialized memory. >> Tha

Re: VC-tag again

Reuben Thomas wrote: > On 14 March 2011 15:45, Jim Meyering wrote: >> Reuben Thomas wrote: >>> This line in maint.mk: >>> >>> VC-tag = git tag -s -m '$(VERSION)' -u '$(gpg_key_ID)' >>> >>> does appear to be unused, because its syntax is wrong: there's no >>> message (argument to -m), or equivalent

Re: [PATCH] quotearg: avoid uninitialized variable use

Eric Blake wrote: > Coverity correctly deduced: > > Error: UNINIT: > m4-1.4.16/lib/quotearg.c:171: var_decl: Declaring variable "o" without > initializer. > m4-1.4.16/lib/quotearg.c:175: uninit_use: Using uninitialized value "o": > field "o".right_quote is uninitialized. > > When custom_quoting_s

Re: update-copyright

Thanks, I'd forgotten about the more general mechanisms. -- http://rrt.sc3d.org

Re: update-copyright

On 04/29/2011 08:32 AM, Reuben Thomas wrote: > Two small niggles: > > 1. No option to turn off updating to the current year. I do take care > not to add years in which I don't change files (I know that this is > fussy), and I was just using update-copyright to compress year ranges. Using UPDATE_C

Re: update-copyright

Reuben Thomas wrote: > Two small niggles: > > 1. No option to turn off updating to the current year. I do take care > not to add years in which I don't change files (I know that this is > fussy), and I was just using update-copyright to compress year ranges. There is no longer any need for that. S

update-copyright

Two small niggles: 1. No option to turn off updating to the current year. I do take care not to add years in which I don't change files (I know that this is fussy), and I was just using update-copyright to compress year ranges. 2. No way to exclude files that are under VC but not from the project

Re: [PATCH] getaddrinfo: fix gai_strerror signature

On 04/29/2011 06:09 AM, Bruno Haible wrote: > Eric Blake wrote: >> +getaddrinfo: fix gai_strerror signature >> +* m4/getaddrinfo.m4 (gl_GETADDRINFO): Detect broken signatures, >> +and work around mingw with UNICODE defined. >> +(gl_PREREQ_GETADDRINFO): Drop redundant decl check. >>

Re: replace gai_strerror on mingw?

On 04/29/2011 01:17 AM, Simon Josefsson wrote: >> test-getaddrinfo.c:28:1: warning: initialization from incompatible >> pointer type > > Improving this seems like a good idea to me. > > Couldn't you use the same approach as getaddrinfo.c does to find the > function? Mingw's inline prototype seem

Re: [PATCH] getaddrinfo: fix gai_strerror signature

Eric Blake wrote: > + getaddrinfo: fix gai_strerror signature > + * m4/getaddrinfo.m4 (gl_GETADDRINFO): Detect broken signatures, > + and work around mingw with UNICODE defined. > + (gl_PREREQ_GETADDRINFO): Drop redundant decl check. > + * m4/netdb_h.m4 (gl_NETDB_H_DEFAULTS): Ad

Re: [PATCH] getaddrinfo: fix gai_strerror signature

On 04/29/2011 01:34 AM, Eric Blake wrote: Worse, on mingw, if UNICODE is defined, it is defined to return WCHAR*, which means the result is in unicode but an application expecting bytes for characters will only see a one-byte answer. AFAIR, Bruno didn't like introducing special hacks for the mi

Re: attributes pure and const

Jim Meyering wrote: > Bruno Haible wrote: >> I would think that >> >> is higher priority. > > I investigated a little and reported it to the git list. > This reply makes me think a release will soon include the fix: > > http:/

[PATCH] test-getcwd.c: avoid new set-but-not-used warning

Eric Blake wrote: > * gnulib: Update to latest. > * bootstrap.conf (gnulib_modules): Add xgetgroups. > --- > > Okay to push? > > * gnulib a81348d...d6d01fd (70): Thanks, but not yet. That would pull in changes that induce two build failures when configuring coreutils with --enable-gcc-warnings:

[PATCH] test-hash.c: avoid a new shadowing warning

FYI, >From 20abe9a92c71d7ccb46484543e874f8b357d5f4f Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 29 Apr 2011 09:38:14 +0200 Subject: [PATCH] test-hash.c: avoid a new shadowing warning * tests/test-hash.c (main): Don't shadow "dup". --- ChangeLog |5 + tests/test-hash.c

Re: [PATCH] getaddrinfo: fix gai_strerror signature

Eric Blake writes: > Several platforms declare gai_strerror to return char* rather than > const char*. Worse, on mingw, if UNICODE is defined, it is defined > to return WCHAR*, which means the result is in unicode but an > application expecting bytes for characters will only see a one-byte > ans

Re: replace gai_strerror on mingw?

Eric Blake writes: > On mingw, gai_strerror has two different return types, depending on > whether UNICODE was defined at the time the header was included. Both > types (char* and WCHAR*) are incompatible with the POSIX return type of > const char*. Furthermore, a WCHAR* return renders the retu