gnulib manual patch

Hi, Here is a patch for the gnulib texi manual explaining some things I would have liked to see in the manual. -- Pat Index: gnulib.texi === RCS file: /cvsroot/gnulib/gnulib/doc/gnulib.texi,v retrieving revision 1.10 diff -u -3 -p

Re: no rpl_mktime in mktime.c

> This problem has been fixed for localtime_r in a different way, and we > could use the same method to fix it for mktime_r. That is, we could > change the role of time_r.h to mean "act like time.h, but replace > functions that need to get fixed", and then have it "#define mktime > rpl_mktime". W

Re: UTF-8 support (was: quote characters in stds)

Paul Eggert wrote: > I read your email containing accented letters with GNU Emacs 21.4 and > Gnus 5.10.6, a combination that supports UTF-8. The UTF-8 support in Emacs 21.4 is minimal. Some people recommend the emacs-unicode-2 branch of the Emacs CVS. (Haven't tried it.) > whose xterm doesn't sup

Re: [bug-gnulib] Re: warning: comparison is always false due to limited range of data type

Paul Eggert wrote: > Shouldn't we simply fix GCC instead? I agree. The appended simpler test case (with 'unsigned short' instead of 'unsigned int', to see the warning on a 32-bit platform as well) produces the warning with "gcc -Wall", even without -W, with any of 3.3.1, 3.4.3, 4.0.0. It appears

Re: [bug-gnulib] Re: should argp depend on unlocked-io?

Sergey Poznyakoff wrote: > Oskar Liljeblad <[EMAIL PROTECTED]> wrote: > > Should argp depend on unlocked-io or should the line > > > > AC_REQUIRE([gl_FUNC_GLIBC_UNLOCKED_IO]) > > > > be removed from m4/argp.m4? If you keep it and don't > > include unlocked-io along with argp, you'll get this > >

Re: short opengroup URLs

Jim Meyering wrote: > Here's his reply. > I think this is sufficient to justify our using the shortened URLs. OK, so I committed the appended patch. Bruno diff -c -3 -r1.91 MODULES.html.sh *** MODULES.html.sh 6 Jul 2005 15:58:47 - 1.91 --- MODULES.html.sh 11 Jul 2005 11:17:55

Re: [bug-gnulib] Re: libtool 2.1a failed mdemo-make.test on Solaris

Ralf Wildenhues wrote: > It's a bit tricky to reproduce: You > need a system which has no argz.h, then configure, then `make check' > without prior make. If you had ever run `make' before in this build > tree, even after `make clean' the dependency information is stored in > libltdl/.deps/*.Plo, a

Re: [bug-gnulib] Re: check_version

Simon Josefsson wrote: > +const char * > +check_version (const char *req_version) > +{ > + if (!req_version || strverscmp (req_version, VERSION) < 0) > +return VERSION; > + > + return NULL; > +} > ... > You will typically wrap the call to the > `check_version' function through a library API,

Re: [bug-gnulib] Re: size_max

Paul Eggert wrote: > Also, while we're on the subject of size_max.m4, I have a pedantic > point: its use of ~(size_t)0 isn't portable in general. For example, > if size_t is narrower than int, then ~(size_t)0 might evaluate to -1, > which isn't correct. Ah, right. I'm changing it to (size_t)~(siz

Re: size_max

Simon Josefsson wrote: > How about this? The patch was discussed and revised a few times some > months ago. Nobody complained after the last patch was posted. I'll > install this on Sunday, unless someone complains. > > > 2004-12-28 Simon Josefsson <[EMAIL PROTECTED]> > > > > * modules/siz

Re: [EMAIL PROTECTED]: Re: quotation characters]

Karl Berry cited RMS saying: > I thought we were going to tell people to use `quote', > not just mention it as a possibility. If it's so hard to convince RMS that modern style is different, maybe it's easier to convince him to drop this subject. Things that make sense to state in a standards docu

Re: check-module

Jim Meyering wrote: > FYI, I ran this command > > (cd modules; ../check-module *) > > and saw some new warnings: There seems to be a portability problem with the check-module script: When I remove all the exceptions code from the check-module script and run (cd modules; ../check-module *) I don'

Re: canonicalize depends on pathmax.h

Jim Meyering wrote: > * check-module (find_included_lib_files): Hard-code another > pair of exceptions: fts.c includes fts-cycle.c and unistd-safer.h > but the fts-lgpl module file (correctly) does not list those files. Why are there two places where you note the exceptions? With

Re: [bug-gnulib] Re: proposal: lib/verify.h

Paul Eggert wrote: > ! # define verify_expr(R) ((void) sizeof (verify_type__ (R))) This doesn't work in C++: gcc gives an error "error: ISO C++ forbids defining types within sizeof" However, Jim's first version with the NULL pointer works in C++ too: #define verify_expr(R) (void) ((verify_type__

Re: [bug-gnulib] Re: no rpl_mktime in mktime.c

Paul Eggert wrote: > I thought that C++ was supposed to be namespace clean > these days. So isn't a standard C++ program supposed to be able to do > this? > > #define mktime(x) (x) > #include > int i = mktime (0); No, this cannot work: will typically contain a declaration like extern "C" {

Re: [bug-gnulib] Re: libtool 2.1a failed mdemo-make.test on Solaris

Hi Bruno, * Bruno Haible wrote on Mon, Jul 11, 2005 at 01:23:26PM CEST: > > The modules in gnulib are normally used in a directory that creates a > single library, say libfoo.la, and in this case a line like > > all-local $(lib_OBJECTS): $(ARGZ_H) > > is meant to be changed to > > all-loca

Re: [bug-gnulib] same.c:78: error: `HAVE_LONG_FILE_NAMES' undeclared (first use in this function)

Gerrit P. Haase wrote: > I also got antoher error, for module mathl this was added to Makefile.am: > > noinst_HEADERS += > > Since it was the first use of noinst_HEADERS automake chokes on it. This usage of noinst_HEADERS is nonsense: - mathl.h and trigl.h are already included in the file l

Re: lgpl compatible files archive?

Paul Eggert wrote: > > alloca malloc realloc strtod atexit dup2 getcwd getpagesize memmove > > memset strerror regex > ... > Bruno, Jim -- do you have any objections to relicensing these? Fine with me: All these modules can reasonably be used in libraries. regex has traditionally been under GPL,

Re: FYI: removing HAVE_FCNTL_H tests

Jim Meyering wrote: > > I've just removed all tests for HAVE_FCNTL_H from coreutils. > > It's been gone in at least one place since coreutils-5.0 (2004-04-02) > > The same applies to HAVE_UNISTD_H and unistd.h One platform still does not have : It's Woe32 with the MSVC compiler. It's unfortunately

Re: [bug-gnulib] new module gettext-h for programs that don't use i18n

Paul Eggert wrote: > I'm trying to have Emacs use gnulib a bit more (one module at a > time...) and discovered that many modules currently depend on gettext > even though they only need the gettext.h file. gettext is a fairly > heavyweight module, and it's not time yet for me to add it to Emacs >

Re: check-module

Hello, On Mon, Jul 11, 2005 at 01:30:32PM +0200, Bruno Haible wrote: > > (cd modules; ../check-module *) ... > There seems to be a portability problem with the check-module script: actually, the script didn't seem to be prepared for such usage at all. It seems that the script actually checked o

Re: new module gettext-h for programs that don't use i18n

Hello Bruno, > for this is the --avoid option to gnulib-tool, which I've now implemented. Great! Thank you very much for this long awaited option. Stepan ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] copyright message with(out) directives

Karl Berry wrote: > Is it better for translators to use placeholder directives in the > standard copyright message, like this (inherited in GNU Hello): > > printf (_("\ > Copyright (C) %s Free Software Foundation, Inc.\n\ > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A\n

Re: [EMAIL PROTECTED]: Re: quotation characters]

If it's so hard to convince RMS that modern style is different, maybe it's easier to convince him to drop this subject. Please, no. It wasn't rms's idea to bring this up. It was ours (mine), and the reason is that GNU developers ask the question, repeatedly. I don't want to go back to h

Re: lgpl compatible files archive?

Hello, On Mon, Jul 04, 2005 at 11:46:41AM -0700, Paul Eggert wrote: > I would say the one exception is getcwd, where the code to support > arbitrarily-deep nesting is not LGPLed anywhere that I can see. does this mean that the arbitrarily-deep nesting code is not going to be contributed back to g

Re: gnulib manual patch

Here is a patch for the gnulib texi manual explaining some things I would have liked to see in the manual. Thanks much, I installed those changes. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: size_max

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> How about this? The patch was discussed and revised a few times some >> months ago. Nobody complained after the last patch was posted. I'll >> install this on Sunday, unless someone complains. >> >> > 2004-12-28 Simon Josefss

Re: new module gettext-h for programs that don't use i18n

Paul Eggert <[EMAIL PROTECTED]> writes: > I'm trying to have Emacs use gnulib a bit more (one module at a > time...) and discovered that many modules currently depend on gettext > even though they only need the gettext.h file. gettext is a fairly > heavyweight module, and it's not time yet for m

Re: copyright message with(out) directives

[EMAIL PROTECTED] (Karl Berry) writes: > I recall past discussions about this, but don't know what the current > preference is. I agree with Bruno about the desirability of parameterizing this. > And, another point, I see that cp --version, for example, has somehwat > different wording: I think

Re: copyright message with(out) directives

+the GNU General Public License .\n\ I've never seen a url in this message before, for any program. Not that I object, I guess it makes sense, but it seems new? You said you found this in the coding standards, but I'm not seeing it ... ? Not that it's a

Re: [bug-gnulib] Re: no rpl_mktime in mktime.c

Bruno Haible <[EMAIL PROTECTED]> writes: > - Which header files are included by the program, in which order? That I don't know, but it's pretty easy to see how the problem would arise by looking at the header (see the pattern below). > - Which C++ header undefines mktime? On my Debian GNU/Linux

Re: lgpl compatible files archive?

Stepan Kasal <[EMAIL PROTECTED]> writes: > does this mean that the arbitrarily-deep nesting code is not going to be > contributed back to glibc? No. I don't think anybody is working on it though, and in the meantime let's let sleeping dogs lie. ___ b

Re: [bug-gnulib] Re: should argp depend on unlocked-io?

Bruno Haible <[EMAIL PROTECTED]> writes: > What about this patch, then? Add the dependency to the module description. > It's then unnecessary to mention it in the autoconf macro. Both patches look a bit off to me, since argp should be usable in multithreaded code. (This is a problem with the cur

Re: [bug-gnulib] Re: proposal: lib/verify.h

Bruno Haible <[EMAIL PROTECTED]> writes: > However, Jim's first version with the NULL pointer works in C++ too: > > #define verify_expr(R) (void) ((verify_type__ (R) *) 0) > > I'd therefore suggest to use this one. Thanks for catching that; I followed your suggestion in coreutils. 2005-07-11 Pa

Re: [bug-gnulib] new module gettext-h for programs that don't use i18n

Bruno Haible <[EMAIL PROTECTED]> writes: > I would therefore now suggest to undo the earlier commodity hacks and > return to a state where the modules/* files represent the real dependencies. > Namely, add back 'xalloc-die' as dependency to those modules need it. > Not sure about 'unlocked-io'. T

Re: UTF-8 support

Bruno Haible <[EMAIL PROTECTED]> writes: > Paul Eggert wrote: >> I read your email containing accented letters with GNU Emacs 21.4 and >> Gnus 5.10.6, a combination that supports UTF-8. > > The UTF-8 support in Emacs 21.4 is minimal. Some people recommend the > emacs-unicode-2 branch of the Emacs

Re: [bug-gnulib] Re: no rpl_mktime in mktime.c

I'm dropping in in the middle of this thread, but I may have some useful information. Patrice Dumas was adding gnulib functions to libdap, which is part of my project. We found that when building on Red Hat Enterprise Linux 3 (Workstation) running on a dual processor x86_64 and using gcc 3.2.3,

Re: UTF-8 support

Paul Eggert wrote: > Bruno Haible <[EMAIL PROTECTED]> writes: > > Paul Eggert wrote: > >> I read your email containing accented letters with GNU Emacs 21.4 and > >> Gnus 5.10.6, a combination that supports UTF-8. > > > > The UTF-8 support in Emacs 21.4 is minimal. Some people recommend the > > emac

Re: no rpl_mktime in mktime.c

Patrice Dumas <[EMAIL PROTECTED]> writes: > It is likely that it fixes my issue (I cannot test myself). Hmm, if we can't test the fix then I'm tempted to leave it alone. Do you know someone else who can test it? ___ bug-gnulib mailing list bug-gnulib