Re: libposix - is it done yet?

Hallo Ralf, On 11 Oct 2010, at 12:20, Ralf Wildenhues wrote: > --- a/modules/stdlib > +++ b/modules/stdlib > @@ -18,7 +18,7 @@ configure.ac: > gl_STDLIB_H > > Makefile.am: > -BUILT_SOURCES += stdlib.h > +posix_headers += stdlib.h > > # We need the following in order to create when the system >

Re: installable gnulib library

gt;> >> Are you implying that libtool is complicated? ;) > > Not at all. It is, but I was saying that gnulib-tool is complicated: > $ ./gnulib-tool --help|wc -l > 158 I was kidding! Libtool certainly *is* complicated :) >>>> AC_INIT([libposix], [20101010], [bug

Re: libposix - is it done yet?

* Bruce Korb wrote on Mon, Oct 11, 2010 at 07:08:56AM CEST: > On Sun, Oct 10, 2010 at 10:04 PM, Ralf Wildenhues wrote: > >> Just to be completely clear, the BUILT_SOURCES in Makefile.am is now > >> overloaded.  Not only does it mean (to automake anyway) that the > >> source gets built first, but al

Re: libposix - is it done yet?

Hi Ralf, On Sun, Oct 10, 2010 at 10:08 PM, Ralf Wildenhues wrote: > >> then you wind up with these choices: >> >> 1. immutable, with the noted problem >> 2. Use version $YEAR$MONTH$DAY:0:0 necessitating a recompile >>    of everything that uses it with every new libposix installation. >>    Proba

Re: libposix - is it done yet?

Hi Ralf, On Sun, Oct 10, 2010 at 10:04 PM, Ralf Wildenhues wrote: >> > $ for module in `./posix-modules`; do grep '^BUILT_SOURCES += \$(.*_H)$' >> > modules/$module; done >> >> Just to be completely clear, the BUILT_SOURCES in Makefile.am is now >> overloaded.  Not only does it mean (to automake

Re: libposix - is it done yet?

* Bruce Korb wrote on Sun, Oct 10, 2010 at 11:45:43PM CEST: > However, since folks fixing the modules are highly unlikely > to be thinking about miniscule perturbations of libposix > interfaces, Why not? They are thinking of adding a NEWS entry, too, for incompatible changes? Bumping the library

Re: installable gnulib library

f gnulib modules, so you might as well take the > path of least resistance, and implement --avoid-posix rather than some > complex solution. You are likely right. I'd like to put some effort into avoiding that. >>> AC_INIT([libposix], [20101010], [bug-gnu...@gnu.org]) >&g

Re: libposix - is it done yet?

* Bruce Korb wrote on Mon, Oct 11, 2010 at 02:59:04AM CEST: > On Sun, Oct 10, 2010 at 3:34 PM, Bruno Haible wrote: > > Bruce Korb wrote: > >> Having looked > >> through the module sources, there is no clear way of > >> deriving the list of header macro names. > > > So you can recognize it through

Re: installable gnulib library

Hi Bruce, On 10 Oct 2010, at 22:26, Bruce Korb wrote: >> The common way to get rid of these warnings is to insert an invocation of >> gl_USE_SYSTEM_EXTENSIONS at the appropriate place in configure.ac. > > Could you explicitly define "appropriate place" in the sample above? :) > I took a guess, ba

Re: installable gnulib library

Hi Bruno, On 11 Oct 2010, at 09:19, Gary V. Vaughan wrote: >> - You want to install the library, which can be done by specifying to >> gnulib-tool a module (via --local-dir) which contains >> lib_LTLIBRARIES = libposix.la >> When gnulib-tool sees this declaration in a module, it will not e

Re: [PATCH] time: enforce recent POSIX ruling that time_t is integral

On 10/10/2010 03:50 PM, Bruno Haible wrote: > From this past experience, I estimate the risk of having a collision with a > system header by using a __ prefix as higher than the risk of having a > collision > with a user program by using a _ prefix. That sounds like reasonable advice given your e

Re: installable gnulib library

Hi Bruno, On 11 Oct 2010, at 09:19, Gary V. Vaughan wrote: >>> It occurs to me also, that when another gnulib using project (that relies on >>> non-libposix modules) wants to minimise it's configury by requiring >>> libposix, >>> gnulib-tool will need an --avoid-posix option or similar so as not

Re: [PATCH] rewrite int foo[2*X-1] to verify(X) or to int foo[X?1:-1]

On 10/10/2010 02:27 PM, Bruno Haible wrote: > Fine, except that it's incomplete: modules/vasnprintf is not the only > module affected: Thanks for catching that: I had looked only at the top level of the modules directory. I fixed that problem, and pushed the result as commit 050d87a67621a3839

Re: installable gnulib library

place of some selection of gnulib modules, so you might as well take the path of least resistance, and implement --avoid-posix rather than some complex solution. >> ## configure.ac: >> >> AC_INIT([libposix], [20101010], [bug-gnu...@gnu.org]) > > The version will need to be

Re: libposix - is it done yet?

On 11 Oct 2010, at 04:45, Bruce Korb wrote: > On 10/10/10 13:59, Bruno Haible wrote: >> Bruce Korb wrote: IMO the inclusion guards of the headers need to be transformed >>> IMO, I don't know that. If a confused program winds up including >>> both, then you'll have duplicate definitions. Theo

Re: installable gnulib library

[adding bug-autoconf for AC_COMPILE_IFELSE comment] On 10 Oct 2010, at 21:35, Bruno Haible wrote: > Hi Gary, Hallo Bruno, Thanks for the quick feedback. >> I think your script is *much* more complicated than it needs to be. Far >> easier to let the existing gnulib machinery populate an installa

Re: libposix - is it done yet?

Hi Bruno, On Sun, Oct 10, 2010 at 3:34 PM, Bruno Haible wrote: > Bruce Korb wrote: >> > nobase_nodist_pkginclude_HEADERS = $(FNMATCH_H) $(FLOAT_H) $(STDDEF_H) ... >> >> so the script must first determine the full list of headers >> that might be provided, convert them to $(XXX_H) names and >> stu

Re: [PATCH] time: enforce recent POSIX ruling that time_t is integral

Paul Eggert wrote: > > But why use __ as prefix? Symbols starting with __ are, generally speaking, > > in the territory of the implementation (libc + compiler), which is why > > gnulib > > tries to use only symbols that start with a single _. > > But this symbol will appear in , so it has both fl

Re: libposix - is it done yet?

Bruce Korb wrote: > > nobase_nodist_pkginclude_HEADERS = $(FNMATCH_H) $(FLOAT_H) $(STDDEF_H) ... > > so the script must first determine the full list of headers > that might be provided, convert them to $(XXX_H) names and > stuff the list into the *_HEADERS thing. Yes. > Having looked > through

Re: libposix - is it done yet?

On 10/10/10 13:59, Bruno Haible wrote: > Bruce Korb wrote: >>> IMO the inclusion guards of the headers need to be transformed >> IMO, I don't know that. If a confused program winds up including >> both, then you'll have duplicate definitions. Theoretically, >> the contents of libposix and what yo

Re: [PATCH] time: enforce recent POSIX ruling that time_t is integral

Paul Eggert wrote: > * lib/time.in.h (struct __time_t_must_be_integral): Rewrite > 2 * ((time_t) 1 / 2 == 0) - 1 to (time_t) 1; this suffices to > verify that time_t cannot be floating. I disagree that this is enough. The C standard says that a cast to floating- point types cannot be portably used

Re: [PATCH] rewrite int foo[2*X-1] to verify(X) or to int foo[X?1:-1]

Hi Paul, > * lib/float+.h (verify_sizeof_flt, verify_sizeof_dbl): > (verify_sizeof_ldbl): Rewrite 2*X-1 to X?1:-1. > * lib/malloca.c: Include "verify.h". > (verify1): Remove, replacing with a verify call. > * lib/relocwrapper.c (verify1): Likewise. > * modules/malloca (Depends-on): Add 'verify'. >

Re: [PATCH] time: enforce recent POSIX ruling that time_t is integral

On 10/10/2010 02:15 PM, Bruno Haible wrote: > I disagree that this is enough. The C standard says that a cast to floating- > point types cannot be portably used in integer constant expressions. But a > compiler is free to support this, as an extension. By the same argument, a compiler is also free

Re: [PATCH] time: enforce recent POSIX ruling that time_t is integral

Bruno Haible wrote: > But why use __ as prefix? Symbols starting with __ are, generally speaking, > in the territory of the implementation (libc + compiler), which is why gnulib > tries to use only symbols that start with a single _. But this symbol will appear in , so it has both flavors: from g

[PATCH] rewrite int foo[2*X-1] to verify(X) or to int foo[X?1:-1]

Here's a proposed patch to replace the other instances of 2*(X)-1 that I found. I haven't pushed this. >From 1581f4d64ee29a7db92f437efb9b12da40554948 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 10 Oct 2010 13:55:10 -0700 Subject: [PATCH] rewrite int foo[2*X-1] to verify(X) or to int f

Re: libposix - is it done yet?

Bruce Korb wrote: > > IMO the inclusion guards of the headers need to be transformed > IMO, I don't know that. If a confused program winds up including > both, then you'll have duplicate definitions. Theoretically, > the contents of libposix and what you get from gnulib would be > the same. No,

Re: [PATCH] time: enforce recent POSIX ruling that time_t is integral

On 10/10/2010 05:09 AM, Bruno Haible wrote: > I agree now. Thanks for checking that. I applied the following patch accordingly. In a later message I'll follow up with a few more proposed patches. >From 6c74aa7b6196c9b3d650c499ea02f1dfc1b62491 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun

Re: libposix - is it done yet?

Hi Bruno, On Sun, Oct 10, 2010 at 11:49 AM, Bruno Haible wrote: > Bruce Korb wrote: >> Anything else need doing? >> >> > href="http://www.woofiles.com/dl-208694-BfZFVR4K-libposix2010.10.05.tar.gz";>libposix-2010.10.05.tar.gz > > Additionally: When PATH does not contain ".", then mk-libposix-pc.sh

Re: libposix - is it done yet?

Bruce Korb wrote: > Anything else need doing? > > href="http://www.woofiles.com/dl-208694-BfZFVR4K-libposix2010.10.05.tar.gz";>libposix-2010.10.05.tar.gz Additionally: When PATH does not contain ".", then mk-libposix-pc.sh fails, saying that it cannot find libposix.la. The fix is to change . l

Re: libposix - is it done yet?

Hi Bruno, > IMO the unit tests should be included. IMO also, the unit tests should be included. > IMO the inclusion guards of the headers need to be transformed IMO, I don't know that. If a confused program winds up including both, then you'll have duplicate definitions. Theoretically, the cont

Re: installable gnulib library

Hi Bruno, Bruno wrote: >>> > > The common way to get rid of these warnings is to insert an invocation >>> > > of >>> > > gl_USE_SYSTEM_EXTENSIONS at the appropriate place in configure.ac. >> > >> > Could you explicitly define "appropriate place" in the sample above? :) >"Appropriate place" means

Re: installable gnulib library

On 10/10/10 09:11, Bruno Haible wrote: > Bruce Korb wrote: >> Whether you use one file or multiple, it is still useful to >> *not* construct the thing where your template sources live. >> Since the AC_INIT macro clearly must be auto-edited, you >> must construe these files to be templates ... > >

Re: git push permissions

Hello, * Bruno Haible wrote on Sun, Oct 10, 2010 at 05:49:06PM CEST: > 3. to make a new git checkout of gnulib with the non-anonymous method > (see ). This is not necessary. Once Bruce has the required permission, he can git remote add write

Re: installable gnulib library

Bruce Korb wrote: > Whether you use one file or multiple, it is still useful to > *not* construct the thing where your template sources live. > Since the AC_INIT macro clearly must be auto-edited, you > must construe these files to be templates ... That means a configure.ac.in? Nah, that's overkil

Re: installable gnulib library

Bruce Korb wrote: > > The common way to get rid of these warnings is to insert an invocation of > > gl_USE_SYSTEM_EXTENSIONS at the appropriate place in configure.ac. > > Could you explicitly define "appropriate place" in the sample above? :) "Appropriate place" means a line; which line, you dete

Re: dprintf, fprintf memory leak

Bruce Korb wrote: > Here are my "make distcheck" results: > > [...] > FAIL: test-dprintf-posix2.sh > [...] > FAIL: test-fprintf-posix3.sh > [...] This indicates a memory leak in dprintf and fprintf. On which platform is this, and which libc version? Bruno

Re: git push permissions

Bruce Korb wrote: > Also, I tried. Can you please fix access? > > $ git push > fatal: The remote end hung up unexpectedly This is because you are not in the group of "members" of gnulib at https://savannah.gnu.org/projects/gnulib . If you want to have write access to the gnulib repository, you n

Re: libposix - is it done yet?

Hi Bruce, > href="http://www.woofiles.com/dl-208694-BfZFVR4K-libposix2010.10.05.tar.gz";>libposix-2010.10.05.tar.gz > The tarball rolls up to 2MB with these directories: > > libposix-2010.10.05/libposix/uniwidth > libposix-2010.10.05/libposix/unistr > libposix-2010.10.05/libposix/glthread > lib

Re: installable gnulib library

Hi Bruno, Another point: On 10/10/10 07:35, Bruno Haible wrote: > I would suggest that you ... create a subdirectory in gnulib, > called 'libposix', with files such as > configure.ac > Makefile.am > version.in.h > version.c > README > libposix.m4 > bootstrap > and then use "gnulib-t

Re: installable gnulib library

o "lib". >> ## Makefile.am: >> >> ACLOCAL_AMFLAGS = -I m4 >> SUBDIRS = libposix tests > > Ahem, there are two things missing here: :-D >> ## configure.ac: >> >> AC_INIT([libposix], [20101010], [bug-gnu...@gnu.org]) >> AC_CONFIG_HEADER

Re: installable gnulib library

;This function is deprecated" makes sense for some sort of maintainer mode functionality -- similar to a link time warning when someone binds to "mktemp(3)". > ## configure.ac: > > AC_INIT([libposix], [20101010], [bug-gnu...@gnu.org]) The version will need to be computed :) > 1.

Re: installable gnulib library

n guard, for example, for stdlib.h: s/_GL_STDLIB_H/_GLINST_STDLIB_H/ Without it, strange things will happen when e.g. coreutils uses stdlib.h from gnulib and its inclusion guard macro is the same as the one of the installed stdlib.h. > ## configure.ac: > > AC_INIT([lib

Re: installable gnulib library

On 10 Oct 2010, at 16:14, Gary V. Vaughan wrote: > 2 bugs need fixing for this to work as intended: D'oh. Make that 4. I kept editing the list, but forgot to update the sentence. > 3. missing AM_CONDITIONAL declarations > -- > I suppose the following definiti

Re: [PATCH] time: enforce recent POSIX ruling that time_t is integral

Hi Paul, ` > >> Hmm, given Bruno's recent point that C89 didn't require ?: support > >> in constant expressions > > I'm skeptical of that. I can't find my copy of the official C89 standard, > but the draft says that > constant expressions can contain ?:. In

Re: installable gnulib library

-import --lib=libposix --source-base=libposix --libtool --with-tests `posix-modules` autoreconf -fvi ## Makefile.am: ACLOCAL_AMFLAGS = -I m4 SUBDIRS = libposix tests ## configure.ac: AC_INIT([libposix], [20101010], [bug-gnu...@gnu.org]) AC_CONFIG_HEADERS([config.h]) AC_CONFIG_FILES([Make