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

Reuben Thomas wrote: > Karl just pointed out to me that, as per: > > http://www.gnu.org/prep/maintain/html_node/Announcements.html > > non-stable release announcements should only go to info-gnu in > exceptional circumstances. Therefore, the hardwired To: address in > maint.mk is wrong, and should

Re: proposed support for C1X-style static_assert

Here's what I pushed. Thanks to Bruno and Eric for the reviews. --- ChangeLog | 22 +++ doc/posix-headers/assert.texi | 21 ++- lib/assert.in.h | 28 + lib/verify.h | 130 + m4/asser

proposed new module intoverflow

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. --- intoverflow: new module This is being put in for Emacs; I think coreutils can use it too. See

better use of AC_LIBOBJ, part 1

For reasons explained in [1], I'm starting to move all AC_LIBOBJ invocations to the module description. In particular, this will make it possible again to use AC_REQUIRE in an unlimited way without introducing subtle bugs. Here are the proposed first 7 patches, along with a normal bug fix. [1] ht

Re: two semantics of fclose()

On 05/05/2011 04:44 PM, 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 b

Re: two semantics of fclose()

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. fclose + fflush - guarantee that

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

Karl just pointed out to me that, as per: http://www.gnu.org/prep/maintain/html_node/Announcements.html non-stable release announcements should only go to info-gnu in exceptional circumstances. Therefore, the hardwired To: address in maint.mk is wrong, and should be set differently for alpha, bet

proper use of AC_LIBOBJ, fclose and fflush

Another use of AC_LIBOBJ of a file in a different module is in fflush.m4. Once I fix this, suddenly there is no need any more for a dependency from 'fflush' to 'fclose' (where everyone would have expected the dependency in the opposite sense). 2011-05-05 Bruno Haible fclose, fflush: R

proper use of AC_LIBOBJ, fflush and fseeko

We learned in [1] that it doesn't generally work to use AC_LIBOBJ of a file in module X from within the m4 macros of module Y. Eric agreed [2] that this is "sane". The first fix in this direction: fflush vs. fseeko. In the mentioned situation, where 'fclose' and 'fseeko' are imported in lib/ but

Re: proposed support for C1X-style static_assert

On 05/05/11 10:48, Bruno Haible wrote: > But with gnulib, we have three territories: the C implementation, gnulib, > and the application. From the point of the C implementation, gnulib is > application code. From the point of the application, gnulib is part of the > C implementation. So we have to

Re: proposed support for C1X-style static_assert

On 05/05/11 10:24, Eric Blake wrote: >> +In C99, @code{assert} can be applied to any scalar expression. >> > +In C89, the argument to @code{assert} is of type @code{int}. > Is it worth trying to fix that in gnulib, as an independent fix? Are > there any implementations where assert(0x1LL)

Re: Relicensing of modules for libposix branch

On 05/05/2011 11:37 AM, Bruno Haible wrote: > Here's the list of modules, list of files in lib/, relevant authors, > agreements so far: > So we're complete with the agreements. I am pushing the license change: > > > 2011-05-05 Bruno Haible > > tzset: Relicense under LGPL. > * mod

Re: proposed support for C1X-style static_assert

Hi Paul, > > Identifiers starting with __ are in the namespace of compiler and libc > > implementation. > > Identifiers starting with "_G" are also reserved In the terminology of the standards, there's only the C implementation and the application. The term "reserved" draws the borderline be

Re: Relicensing of modules for libposix branch

Here's the list of modules, list of files in lib/, relevant authors, agreements so far: Modules: acosl asinl atanl cosl expl logl sinl sqrtl tanl isfinite tmpfile fflush futimens nanosleep getgroups tzset - no agreement needed, since no file in lib/ strto

Re: proposed support for C1X-style static_assert

On 05/05/2011 11:15 AM, Paul Eggert wrote: > On 05/05/11 01:10, Bruno Haible wrote: >> - A doc update of doc/posix-headers/assert.texi would be useful. > > Thanks for catching that. A further draft patch is below. It also > notes a minor difference between C89 and C99 'assert'. > >> Identifie

Re: proposed support for C1X-style static_assert

On 05/05/11 01:10, Bruno Haible wrote: > - A doc update of doc/posix-headers/assert.texi would be useful. Thanks for catching that. A further draft patch is below. It also notes a minor difference between C89 and C99 'assert'. > Identifiers starting with __ are in the namespace of compiler an

Re: Feature Request: define sighandler_t

Markus Steinborn wrote: > Works well on RHEL 5 (-Clones) and on Mac OS X. Thanks for your testing. I've committed the patch now. Bruno -- In memoriam Peter van Pels

Re: gl_MODULE_INDICATOR

On 05/05/2011 08:28 AM, Bruno Haible wrote: > Hi Eric, > >> I have a condition (namely, test-fclose), where I only want to test >> a particular behavior of fclose if I know that fflush was replaced at >> the same level as fclose. That is, if fclose is in lib, but fflush is >> only in tests, then

Re: rebasing topic/libposix

Eric Blake wrote: > The question then comes on how to incorporate the branch back into > master. For libposix, the approach I favour is that individual patches that address individual issues (Gary and I have listed 9 issues) get proposed for master, get reviewed, and then get committed. Individual

Re: gl_MODULE_INDICATOR

Hi Eric, > I have a condition (namely, test-fclose), where I only want to test > a particular behavior of fclose if I know that fflush was replaced at > the same level as fclose.  That is, if fclose is in lib, but fflush is > only in tests, then the test is likely to fail and so I want to compile

Re: [PATCH 1/2] maint: remove useless REPLACE_*_H macros

On 05/05/2011 03:20 AM, Bruno Haible wrote: > Hi Eric, > >> There are still a few modules, like iconv_h.m4, that still >> use older paradigms where GNULIB_POSIXCHECK is unsupported >> and where gl_REPLACE__H is still essential. But since >> we are moving away from that style, I see no reason to k

Re: rebasing topic/libposix

On 05/04/2011 11:11 PM, Gary V. Vaughan wrote: > Howdy Bruce, > > On 5 May 2011, at 03:22, Bruce Korb wrote: >> Not being a GIT guru, I had previously done "git merge" to >> synchronize topic/libposix with master. Seemed straight >> forward and obvious to me. However, "rebase" is a better >> sp

Re: help in deciphering a gnulib-tool/bootstrap issue

Hi Eric, > >>> ./bootstrap: aclocal -I m4 --force -I 'gnulib/m4' ... > >>> missing file gnulib/tests/fseeko.c > >>> configure.ac:80: error: expected source file, required through > >>> AC_LIBSOURCES, not found > ... > the relaxation of fclose > dependencies changed fflush from mandatory to test

Re: [PATCH 1/2] maint: remove useless REPLACE_*_H macros

Hi Eric, > There are still a few modules, like iconv_h.m4, that still > use older paradigms where GNULIB_POSIXCHECK is unsupported > and where gl_REPLACE__H is still essential. But since > we are moving away from that style, I see no reason to keep > the idiom for the modules that don't need it.

Re: Licensing of modules for libposix

Bruce Korb wrote: ... > Is it a "small" thing if a half dozen engineers spend days > exchanging emails trying to figure it out? Not so small to me. Fortunately, this doesn't happen often, and once it does for a given module, it's not likely to happen again, unless someone has a good argument

Re: proposed support for C1X-style static_assert

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 { > ... > + int __gl_dummy; \ > ... > +

proposed support for C1X-style static_assert

Here's a proposed refactoring of the guts of verify.h so that it can be used to support C1X-style static_assert. I prefer gnulib's 'verify (FOO)' to C1X's 'static_assert (FOO, "FOO didn't work")', but it's also nice to support the standard syntax. assert-h: new module, which supports C1X-style s