Re: [PATCH] maintainer-makefile: make sc_po_check easier to tune

On 05/06/2011 04:54 PM, Eric Blake wrote: > On 05/06/2011 04:43 PM, Bruno Haible wrote: >> Eric Blake wrote: >>> ... want to ensure xgettext scans some generated files not in git. >> >> Normally it is recommended [1] to list in POTFILES.in the actual source >> files, >> not the generated files. >

Re: [PATCH] maintainer-makefile: make sc_po_check easier to tune

On 05/06/2011 04:43 PM, Bruno Haible wrote: > Eric Blake wrote: >> ... want to ensure xgettext scans some generated files not in git. > > Normally it is recommended [1] to list in POTFILES.in the actual source files, > not the generated files. I tend to agree, for .y or .l files where the C strin

Re: [PATCH] maintainer-makefile: make sc_po_check easier to tune

Eric Blake wrote: > ... want to ensure xgettext scans some generated files not in git. Normally it is recommended [1] to list in POTFILES.in the actual source files, not the generated files. Bruno [1] http://www.gnu.org/software/gettext/manual/html_node/po_002fPOTFILES_002ein.html -- In memori

Re: [PATCH] fclose: guarantee behavior on seekable stdin

Eric Blake wrote: > Well, I didn't see it go in yet, so I pushed the same thing. Oops, I forgot to push. Thanks for doing it. > Then I followed up with this, which passes testing on libvirt. Perfect! Bruno -- In memoriam Pim Fortuyn

[PATCH] maintainer-makefile: make sc_po_check easier to tune

* top/maint.mk (sc_po_check): Allow overriding which non-VC files to probe for strings, such as an alternate location for gnulib. Signed-off-by: Eric Blake --- Needed for (and tested with) libvirt, where gnulib files live in $(srcdir)/gnulib/lib/*.[ch] rather than the default, and where we also

Re: [PATCH 1/2] tests: allow tests to learn where a module is present

On 05/04/2011 04:39 PM, Eric Blake wrote: > Set up framework to tell from within a test whether a module > exists in just tests or also in libs. > > * m4/gnulib-common.m4 (gl_MODULE_INDICATOR): Refine definition. > * gnulib-tool (func_note_Makefile_am_edit): Update condition > output. > > Signed-

[PATCH] fclose: guarantee behavior on seekable stdin

* modules/fclose (Depends-on): Add fflush. * doc/posix-functions/fclose.texi (fclose): Document this. * tests/test-fclose.c (main): Make test for this unconditional. Signed-off-by: Eric Blake --- > OK, I've applied the license change. Eric, you can now let 'fclose' depend on > 'fflush'. Well, I

Re: shrinking "assert (X)" and "abort ()"

On 05/06/11 11:03, Bruno Haible wrote: as this is good enough if you have a debugger Honestly, I think this would be a misfeature. I completely agree, but without any conditions. The problem is that most distros nowadays disable core dumps. So you don't get a message and you don't get a core

Re: two semantics of fclose()

Eric Blake wrote: > > lib/fflush.c - needs the permission of you, me, and Jim. > > lib/fpurge.c - needs the permission of you and me. > > > > I agree to relax these two modules to LGPLv2+. > > As do I. Jim Meyering wrote: > Relaxing fflush.c to LGPLv2+ is fine with me. OK, I've applied the l

Re: shrinking "assert (X)" and "abort ()"

Hi Paul, > Sometimes I'd rather have something smaller and faster > in production code, something like this: > >   #if __GNUC__ < 3 || (__GNUC__ == 3 && __GNUC_MINOR__ < 3) >    #define __builtin_trap() abort () >   #endif > >   #define assert(X) ((void) ((X) || (__builtin_trap (), 0))) > > as

Re: shrinking "assert (X)" and "abort ()"

On 05/06/2011 11:21 AM, Paul Eggert wrote: > Of course I could do this with a new macro (assert_trap, say), > but that'd be an intrusive change into the source code. Yeah, making assert() smaller, for a single developer run, seems useful. > > I'm thinking of adding a new module, "assert-trap" sa

shrinking "assert (X)" and "abort ()"

When NDEBUG is not set, standard implementations of "assert" do something like this: #define assert(X) ((void) ((X) || __assert_fail (#X, __FILE__, __LINE__, __func__)) Sometimes I'd rather have something smaller and faster in production code, something like this: #if __GNUC__ < 3 || (__GNU

Re: rebasing topic/libposix

On 05/06/2011 11:02 AM, Gary V. Vaughan wrote: > On Fri, May 06, 2011 at 09:07:22AM -0700, Bruce Korb wrote: >> I have forgotten why GIT tends to hang up without telling you why: >> >>> $ git push >>> fatal: The remote end hung up unexpectedly >> >> so I haven't pushed the 180 commit merge. >

Re: rebasing topic/libposix

On Fri, May 06, 2011 at 09:07:22AM -0700, Bruce Korb wrote: > I have forgotten why GIT tends to hang up without telling you why: > > >$ git push > >fatal: The remote end hung up unexpectedly > > so I haven't pushed the 180 commit merge. If memory serves that happens when you make a read-only

Re: proposed new module intoverflow

Paul Eggert writes: > I am adding some integer overflow checking to GNU Emacs, and RMS > suggested that I make it a gnulib module, which sounds like a good > suggestion, so here's a proposed module. They seem like a good idea. Did you consider adding some checking for their constraints, such as

Re: rebasing topic/libposix

On 05/05/11 07:20, Eric Blake wrote: Rebasing a public branch is only acceptable if you make it equally public that you are doing the rebase. Otherwise, you are better off doing a merge rather than a rebase. OK, I did it as a merge. There was a strange conflict in modules/inttypes wherein Mak

Re: two semantics of fclose()

Bruno Haible wrote: > Hi Eric, > >> > What is the semantic of fclose() that you want to test? >> > Basically, you have two possible behaviours of fclose(), one is probably >> > stricter POSIX compliant than the other. >> >> 1. fclose alone - guarantee that fdopen(sockfd) can be fclose'd >> 2. fclos

Re: proposed support for C1X-style static_assert

On Thu 05 May 2011, Bruno Haible wrote: > Hi Paul, > >> it's also nice to support the standard syntax. > > Nice work, thanks. Just three remarks: > > - A doc update of doc/posix-headers/assert.texi would be useful. > > - Use of __ prefixed identifiers: >> + struct __gl_verify_type { >> ... >> +

Re: proposed new module intoverflow

Hi Paul, Paul Eggert wrote: > integer overflow checking ... a gnulib module, which sounds like a good > suggestion Yes, it's definitely a good idea. How often will the min and max arguments be chosen to be different from the minimum and maximum of the type? I'd like to see variants which take th

Re: Alpha & beta announcements shouldn't go to info-gnu by default

I forgot that make has if, and I keep forgetting that in maint.mk we are writing GNU make in any case (even when reading ?= !). Thanks for the patch, Jim!