gcc warning in argmatch

disappears. OK to apply? 2006-10-18 Bruno Haible <[EMAIL PROTECTED]> * lib/argmatch.c (argmatch_invalid): Inline the format string expression. This allows gcc to perform format string checking. *** gnulib-20061012/lib/argmatch.c 2006-09-19 00:51:15.0 +0200 ---

tweak findprog.c

Hi, I applied this, to fix a gcc warning. 2006-10-18 Bruno Haible <[EMAIL PROTECTED]> * lib/findprog.c (find_in_path): Avoid "gcc -Wwrite-strings" warning. *** gnulib-20061012/lib/findprog.c 2006-09-19 00:51:16.0 +0200 --- gnulib-20061012-modifie

gnulib-tool: one more AC_LIBOBJ related fix

Hi, AC_LIBOBJ removes duplicates but our replacement doesn't. This matters when building shared libraries on platforms like MacOS X and mingw. (For example, if you need both getline and getdelim, getdelim.o will be added twice.) Here is a fix. 2006-10-18 Bruno Haible <[EMAIL P

make 'lock' usable in a mixed C/C++ world

The mingw port of GNU gettext now needs this. 2006-10-18 Bruno Haible <[EMAIL PROTECTED]> * lock.h [C++]: Wrap definitions in extern "C". *** gnulib-20061012/lib/lock.h 2006-08-15 13:35:30.0 +0200 --- gnulib-20061012-modified/lib/lock.h 2006-10-19 04:41:44

Re: [bug-gnulib] [patch] gnulib-tool --local-dir

Charles Wilson wrote: > -*/ ) sourcebase=`echo "$local_gnulib_dir" | sed -e > "$sed_trimtrailingslashes"` ;; > +*/ ) local_gnulib_dir=`echo "$local_gnulib_dir" | sed -e > "$sed_trimtrailingslashes"` ;; Thanks, applied. Bruno

Re: gcc warning in argmatch

Paul Eggert wrote: > but can you please hoist the call to gettext > outside the conditional? That is a tad easier for me to read and > typically generates more-compact code. Something like this: > > error (0, 0, > _(problem == -1 >? "invalid argument %s for %s" >

Re: [bug-gnulib] argp, strndup and MinGW

Hi, It appears that the copy of gnulib that you are using is several months old: The printf-args.c problem was fixed on 2006-07-22. So, can you please tell us the date of the gnulib copy that you are using, so that we can look at the right source code, or try the current gnulib instead? Thanks. B

Re: [bug-gnulib] argp, strndup and MinGW

Daniel Martin wrote: > Ah, sorry. > > I was under the impression that gnulib-tool downloaded everything from > the current CVS. I'll try the most recent gnulib. Sorry to have wasted > your time. > > I've just looked in the gnulib-tool source and it contains the line: > cvsdatestamp='$Date: 2006/0

c-strstr tweak

This fixes a gcc warning with -Wmissing-prototypes. 2006-10-16 Bruno Haible <[EMAIL PROTECTED]> * lib/c-strstr.c: Include c-strstr.h. *** gnulib/lib/c-strstr.c 2006-09-14 15:42:08.0 +0200 --- gnulib-20061012/lib/c-strstr.c 2006-10-17 02:03:36.0

Re: gcc warning in argmatch

Paul Eggert wrote: > I guess I thought it was specified. The gettext manual says something > like this under "xgettext Invocation": > >`-k KEYWORDSPEC' >`--keyword[=KEYWORDSPEC]' > Additional keyword to be looked for (without KEYWORDSPEC means not > to use default keywords

--create-testdir and mingw

The output of --create-testdir should be usable on mingw, IMO. But the autoconfiguration of two modules aborts on mingw. So I find it better to exclude them from the default configuration. Of course, you can still --create-testdir of these modules explicitly. 2006-10-19 Bruno Haible <[EM

Re: [bug-gnulib] argp and MinGW

gc()) #define __argv (*__p___argv()) But OTOH, glibc headers must be robust against user code that does #define argc some_weird_macro Sergey, is this ok to commit? 2006-10-19 Bruno Haible <[EMAIL PROTECTED]> * lib/argp.h (argp_parse, __argp_parse): Use _argc, _argv as argume

use autoconf caching in alloca.m4

This is a small optim, when gl_FUNC_ALLOCA is used several times by the same configure file. 2006-10-19 Bruno Haible <[EMAIL PROTECTED]> * m4/alloca.m4 (gl_FUNC_ALLOCA): Cache the result of the AC_EGREP_CPP invocation. *** gnulib-20061019/m4/alloca.m42005-01-23

an autoconf expert challenge

nvoke AC_LIBOBJ are not AC_REQUIREd? 2006-10-19 Bruno Haible <[EMAIL PROTECTED]> * m4/allocsa.m4 (gl_ALLOCSA): Invoke gl_FUNC_ALLOCA, don't AC_REQUIRE it. *** gnulib-20061019/m4/allocsa.m4 2006-10-13 00:10:35.0 +0200 --- gnulib-20061019-modified/m4/allo

use autoconf caching in size_max.m4

This is a small optim, when gl_SIZE_MAX is used several times by the same configure file. 2006-10-19 Bruno Haible <[EMAIL PROTECTED]> * m4/size_max.m4 (gl_SIZE_MAX): Cache the result. *** gnulib-20061019/m4/size_max.m4 2006-06-16 15:14:36.0 +0200 --- gnulib-20

fallout on mingw

Hi, A build of the complete gnulib on mingw fails with a number of errors. 1) 'savewd' i386-pc-mingw32-gcc -DHAVE_CONFIG_H -DEXEEXT=\".exe\" -DEXEEXT=\".exe\" -I. -I.. -I../intl -g -O2 -MT savewd.o -MD -MP -MF .deps/savewd.Tpo -c -o savewd.o savewd.c savewd.c:31:22: sys/wait.h: No such file

canonicalize on mingw

mingw doesn't have symlinks, therefore S_ISLNK (defined in stat-macros.h) always returns 0. This should avoid the compilation error. canonicalize.m4 should then also check for readlink(). *** canonicalize.c.bak 2006-09-19 00:51:16.0 +0200 --- canonicalize.c 2006-10-20 03:37:12.00

fchmodat on mingw

This fixes the build error of fchmodat on mingw. Jim, Paul? 2006-10-19 Bruno Haible <[EMAIL PROTECTED]> * lib/openat-priv.h (EOPNOTSUPP): Provide fallback definition. Needed for mingw. *** openat-priv.h.bak 2006-10-07 01:01:48.0 +0200 --- openat-priv.h

Re: [bug-gnulib] [patch] feature enhancement for gnulib-tool

Hello Charles, Charles Wilson wrote: > When you call gnulib-tool --import/--update, it autogenerates a > Makefile.am for the library. Sometimes it is desirable to customize > that Makefile's behavior -- but those customizations will be lost upon > the next --update. Thanks for working on this

getndelim2 on mingw

This fixes a compilation error on mingw. I applied it. getndelim2.c: In function `getndelim2': getndelim2.c:91: error: `SSIZE_MAX' undeclared (first use in this function) 2006-10-19 Bruno Haible <[EMAIL PROTECTED]> * lib/getndelim2.c (SSIZE_MAX): Provide fallback de

Re: [bug-gnulib] [patch] feature enhancement for gnulib-tool

Charles Wilson wrote: > The problem comes down to assignment. Some of the variables in the > section emitted by gnulib-tool prior to the snippets are assigned using > '='. Therefore, you can't do this: > > Makefile.am: > DEFAULT_INCLUDES = > AM_CPPFLAGS = -DNO_XMALLOC > include Makefile.am.gnul

Re: [bug-gnulib] argp and MinGW

Paul Eggert wrote: > Bruno Haible <[EMAIL PROTECTED]> writes: > > > * lib/argp.h (argp_parse, __argp_parse): Use _argc, _argv as argument > > names, not __argc, __argv. (The latter are defined as macros on mingw.) > > glibc headers must also be robust agains

renaming obstack_free

2. any patch should not break the binary compatibility, 3. any patch should not break glibc. I propose this one. Paul, do you think you can push that into glibc? 2006-10-20 Bruno Haible <[EMAIL PROTECTED]> Ability to rename obstack_free. * lib/obstack.h (_obstack_free

gnulib-tool: fix for platforms with bash 2.x

Hi, All versions of bash grok for f in $VAR; do ...; done where VAR is an empty shell variable. But for f in $(VAR); do ...; done where $(VAR) is an empty Makefile variable, leads to a syntax error with bash 2.00..2.05. The solution is ugly... 2006-10-21 Bruno Haible <[EMAIL PROTEC

gnulib documentation structure

10-21 Bruno Haible <[EMAIL PROTECTED]> * doc/gnulib.texi: Split the chapter "Gnulib" into 3 chapters "Introduction", "Miscellanous Notes", "Particular Modules". diff -r -c3 --exclude=CVS gnulib-20061020/doc/gnulib.texi gnulib-200610

an introduction to gnulib

Hi, I hope this fulfills the need of an introduction to gnulib. 2006-10-22 Bruno Haible <[EMAIL PROTECTED]> * doc/gnulib-intro.texi: New file. * doc/gnulib.texi: Include it. diff -r -c3 --new-file --exclude=CVS gnulib-20061020/doc/gnulib-intro.texi gnulib-20061020-mo

new module 'tsearch'

ch.h (like we also did for some of the more exotic functions). 2006-10-22 Bruno Haible <[EMAIL PROTECTED]> * modules/tsearch: New file. * lib/tsearch.h: New file. * lib/tsearch.c: New file, from glibc-2.5 with small modifications. * m4/tsea

Re: [bug-gnulib] Re: getaddrinfo.c: don't require snprintf; new function: shorttostr

Simon Josefsson wrote: > > +# Prerequisites of lib/uinttostr.c. > > +AC_DEFUN([gl_PREREQ_UINTTOSTR], [:]) > > What are these dummy functions useful for, anyway? They separate the autoconf macros needed to determine _when_ to enable a replacement from the autoconf macros needed for compiling the r

Re: [bug-gnulib] gnulib-tool: fix for platforms with bash 2.x

Daniel Jacobowitz wrote: > > ! echo " @MOSTLYCLEANDIRS=\"\$(MOSTLYCLEANDIRS)\" \\" I think a semicolon is missing after the assignment. > > ! echo " test -z \"\$\$MOSTLYCLEANDIRS\" || \\" This is not needed usually (except if you care about very old shells). > > ! echo "for dir in \

Re: renaming obstack_free

Paul Eggert wrote: > if we uniformly substitute __obstack_free for _obstack_free, and omit the > change's last hunk, then the change should be OK for glibc. Thanks for the advice. I committed this. 2006-10-23 Bruno Haible <[EMAIL PROTECTED]> Paul Eggert

Re: an introduction to gnulib

Karl Berry wrote: > I fixed a few Texinfo niglets. ChangeLog entry? Diffs to this mailing list? These were a little more than Texinfo niglets: > @@ -144,18 +146,18 @@ > @subsection Enhancements of ISO C or POSIX functions > > These are sometimes POSIX functions with GNU extensions also found

fts.c doesn't compile with C89 compiler

after-statement" yields a warning: fts.c:1076: warning: ISO C90 forbids mixed declarations and code gnulib still assumes C89 only. Here is a fix. Jim, OK to apply? 2006-10-23 Bruno Haible <[EMAIL PROTECTED]> * fts.c (fts_build): Move variable declaration, for C89 compliance.

Re: texinfo, dashes

Eric Blake wrote: > But texinfo documents that using '---' without surrounding spaces is the > correct way to typeset an mdash, which is exactly the punctuation you want > here. Here's what I get: Input: '---' ' --- ' Output in .info:'--'

gl_list.h doesn't compile with C89 compiler

Just fixed this. 2006-10-24 Bruno Haible <[EMAIL PROTECTED]> * lib/gl_list.h: Use C comment style, not C++ comment style. *** lib/gl_list.h 6 Oct 2006 12:06:07 - 1.3 --- lib/gl_list.h 24 Oct 2006 13:23:28 - *** *** 360,366

wcwidth.h requires wint_t type

Hi, On MacOS X 10.2 (Darwin 6.x), wcwidth.h gives a compilation error, because wint_t is not defined. All other uses of wint_t in gnulib are protected by HAVE_WCHAR_H or HAVE_WINT_T, only this one is missing the check. I'm applying this: 2006-10-24 Bruno Haible <[EMAIL P

fix 'striconv' on NetBSD

the same way on NetBSD as on platforms with glibc or libiconv. It fixes a testsuite failure of GNU gettext. 2006-10-24 Bruno Haible <[EMAIL PROTECTED]> * lib/striconv.c (mem_cd_iconv, str_cd_iconv): Treat all non-GNU iconv implementations like Irix iconv. *** gnulib-20061

Re: texinfo, dashes

Karl Berry wrote: > Indeed, spaces around dashes is an American/European difference. > ... > However, nothing else in Texinfo documents in general, or the Gnulib > document in particular, is typeset in European style, as far as I can > see, so the spaces seem out of place to me. But when I sit dow

Re: gettext.h patch for portability to sunCC, pgCC, RHEL AS 4 g++

Paul Eggert wrote: > However, gettext.h does attempt to be portable to C++, so the problems > you found there suggest that a fix is needed. It currently does this: > > #define _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS \ > (__GNUC__ >= 3 || defined __cplusplus) > > but (as you've found) older C

Re: [bug-gnulib] cvs commit log messages

Jim Meyering wrote: > I have found that it is useful to keep the commit log message > very similar to the ChangeLog entry. ... whereas I find it useful to put rationale information into the cvs commit message. (Because the ChangeLog entry is only supposed to mention _what_ has changed, not _why_.

Re: [bug-gnulib] C++ support?

e 218: Error: An integer constant expression is required > within the array subscript operator. > 2 Error(s) detected. Fixed. Bruno 2006-10-25 Bruno Haible <[EMAIL PROTECTED]> * lib/gettext.h (_LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS): Define to false for PGI C++

Re: [bug-gnulib] C++ support?

Bob Proulx wrote: > My opinion (which counts for very little here) is that while C++ is > designed to be as close to C as possible, but no closer, that it is > still not C. C++ is not a strict superset of C. It is close but not > perfect. True. Regarding struct and enum type definitions, you hav

Re: [bug-gnulib] gettext.h patch for portability to sunCC, pgCC, RHEL AS 4 g++

Ben Pfaff wrote: > I don't understand this assertion that ISO C++ supports > variable-size arrays. ISO C++98 shows the expression in an > array-declarator to be a constant-expression You're right. I was confused. It's only some specific C++ compilers (such as g++) which do support variable-size a

Re: gettext.h patch for portability to sunCC, pgCC, RHEL AS 4 g++

Paul Eggert wrote: > Like Ben Pfaff, I don't understand the assertion that ISO > C++ supports variable-length arrays. Indeed, ISO C++ does not support variable-length arrays. Sorry for the wrong statement. > I just now checked the 2005-10-19 working draft >

'progname' tweak

In the situation when all gnulib symbols are aliased, one needs this patch to avoid a compiler warning. 2006-10-25 Bruno Haible <[EMAIL PROTECTED]> * lib/progname.h (set_program_name): Undefine before defining. *** lib/progname.h.bak 2005-05-14 08:03:58.0 +0200 -

Re: [bug-gnulib] Non const global in mbchar.c

Paul Eggert wrote: > Makes sense to me. Here's a proposed patch. > > 2006-10-25 Paul Eggert <[EMAIL PROTECTED]> > > * lib/mbchar.c (is_basic_table): Now const. > Problem reported by John Darrington. > * lib/mbchar.h (is_basic_table): Likewise. Thanks, applied. Bruno

update to gettext-0.16

Hi, I'm upgrading the gettext module to gettext-0.16. 2006-10-27 Bruno Haible <[EMAIL PROTECTED]> Update to GNU gettext 0.16. * modules/gettext (Files): Add m4/intl.m4, m4/intldir.m4. Remove m4/inttypes-h.m4, m4/signed.m4. * m4/gettext.m4: Update to

Re: [bug-gnulib] hello pretest 2.1.94

Hello Karl, > I put another hello pretest at > ftp://alpha.gnu.org/gnu/hello/hello-2.1.94.tar.bz2 (and .gz). It uses automake-1.10 and gettext-0.15, which is a bad combination. ("make install" fails on platforms which don't have a good 'mkdir' program.) The fix should be to use "gettextize" from

Re: signed.m4 never again (was: Re: signed.m4 again)

it also from the 'vasnprintf' module. 2006-10-27 Bruno Haible <[EMAIL PROTECTED]> * m4/signed.m4: Remove file. * m4/vasnprintf.m4 (gl_PREREQ_PRINTF_ARGS_: Remove bh_C_SIGNED invocation. * modules/vasnprintf (Files): Remove m4/signed.m4. diff

Re: [bug-gnulib] strings.h in argz.c?

Simon Josefsson wrote: > #if defined(HAVE_STRING_H) > # include > #elif defined(HAVE_STRINGS_H) > # include > #endif > #if defined(HAVE_MEMORY_H) > # include > #endif > > Is strings.h needed on any modern platform? No. 1) exists on all platforms, for several years now. The #elif branch

Re: [bug-gnulib] Missing dependency in allocsa

Charles Wilson wrote: > The allocsa module includes eealloc.m4 in its filelist -- but it doesn't > "depend" on the eealloc module -- Right. > this allows the LGPL allocsa module to > avoid bringing in the GPL eealloc.h, so as not to run afoul of GPL. The license question is secondary. The pri

Re: strings.h in argz.c?

Simon Josefsson wrote: > I assume that memory.h is a side-effect of using strings.h, and that > memory.h is not needed today either? Yes. Even on older systems like Solaris 2.4, AIX 4.3, IRIX 6.5, HP-UX 11, OSF/1 4.0, the contents of is also available through . Bruno

Re: new module 'tsearch'

There were no objections, so I committed this new module. Bruno > 2006-10-22 Bruno Haible <[EMAIL PROTECTED]> > > * modules/tsearch: New file. > * lib/tsearch.h: New file. > * lib/tsearch.c: New file, from glibc-2.5 with small modifications. > * m4/tsearch.m4: New file.

C++ support (1)

efore applying this patch. 2006-10-29 Bruno Haible <[EMAIL PROTECTED]> Make it compile in C++ mode. * lib/striconv.c (mem_cd_iconv): Cast malloc/realloc result. * lib/strnlen1.c (strnlen1): Cast memchr result. * lib/mbchar.h (mb_copy): Rename arguments to 

C++ support (2)

. Unfortunately, for xmalloc, such a thing is not possible. OK to apply? 2006-10-29 Bruno Haible <[EMAIL PROTECTED]> * lib/xalloc.h (xrealloc, xnrealloc, x2realloc, x2nrealloc, xmemdup) [C++]: Add function template that provides result type propagation. *** gnulib-200610

C++ support (3)

This is one of 2 more changes needed for C++ compilation of GNU gettext without errors. Is this acceptable? 2006-10-29 Bruno Haible <[EMAIL PROTECTED]> Make it compile in C++ mode. * lib/full-write.c (full_rw): Add a cast. *** gnulib-20061026/lib/full-write.c2006

C++ support (4)

The other change requires to add casts for xmalloc calls, and to move the 'struct slotvec' outside the function where it's currently defined - otherwise it is not a valid template parameter for the xrealloc template (and without the xrealloc template, one needs to add dozens of casts). Paul, what

Re: [bug-gnulib] gnulib-tool: unterminated substitute pattern

7; shall match a embedded in the pattern space. A literal shall not be used in the BRE of a context address or in the substitute function." I'm applying this: 2006-11-01 Bruno Haible <[EMAIL PROTECTED]> * gnulib-tool (func_get_automake_snippet): Change sed_combine_lines

Re: [bug-gnulib] C++ support (3)

Jim Meyering wrote: > but since it's just one Yes. Currently I see no point in making all the replacement modules compile in C++ mode. Only those used in a build on a Linux system are needed, because the purpose of type checking can be achieved on Linux. > and I see no way around it, ok. OK, ap

Re: [bug-gnulib] xmalloc, xnmalloc (was: Re: C++ support (2))

Paul Eggert wrote: > I installed this patch instead. Thanks. > I prefer to put it into a C++ ghetto area of the code. I was hesitating about this too. What I realize now is that we are using xmalloc() too often, and xnmalloc() not often enough. xnmalloc() is designed to be safe against integer

Re: [bug-gnulib] C++ support (3)

rations in lib/regex* that Ulrich Drepper refuses to convert to ANSI C. Such a solution would also help Sam Steingold, who has the same problem in GNU clisp. 2006-11-01 Bruno Haible <[EMAIL PROTECTED]> * lib/printf-parse.c (PRINTF_PARSE): Cast malloc/realloc results. *** lib

Re: [bug-gnulib] C++ support (3)

.c:29: > /usr/include/string.h:326: error: declaration of `int rpl_strcasecmp(const > char*, const char*) throw ()' throws different exceptions > strcase.h:34: error: than previous declaration `int rpl_strcasecmp(const > char*, > const char*)' I'm applying this

Re: [bug-gnulib] gnulib-tool: unterminated substitute pattern

h replaces it with nothing). I'm applying this: 2006-11-02 Bruno Haible <[EMAIL PROTECTED]> * gnulib-tool (func_get_automake_snippet): Interpret a backslash- newline sequence in the Makefile.am snippet as a space, like "make" does. Reporte

Re: [bug-gnulib] xmalloc, xnmalloc

Paul Eggert wrote: > If you look at the context of those lines in getgroups.c and > group-member.c, you'll see that those lines are OK. (So I'm afraid > the "sinner" is whoever's in charge of the rest. :-) Yes. But in the group-member.c case, a macro that invokes xnmalloc would simplify your cod

Re: tracking source files for POTFILES.in?

Karl Berry asked on bug-gnulib: > How do people maintain the list of Gnulib source files for POTFILES.in? > Other than simply tracking the ever-changing list of sources, is there > any built-in support of some kind? > > I can imagine writing a script that greps the gnulib dir or whatever, > but ma

Re: [bug-gnulib] [patch] typo in gnulib-tool

Charles Wilson wrote: > The variable name is $makefile_name, the command-line option is > --makefile-name Thanks, applied. Bruno

Re: gnulib localization

Sergey Poznyakoff wrote: > The "gnulib" textual domain was defined exactly for that purpose. OK, that is good for the moment as well. It is quite well translated already, see http://www.iro.umontreal.ca/translation/registry.cgi?domain=gnulib . What's missing is that gnulib-tool copies the POT & P

Re: [bug-gnulib] Proposed Module: canonicalize-lgpl

Paul Eggert wrote: > I'd prefer something more like fts, where > the code itself is the same in both modules ... > Can't we slim it down to one copy? Hmm, in terms of maintainability, borrowing an implementation from glibc doesn't cost much, since the code in glibc doesn't change often. Either wa

Re: gnulib localization

Sergey Poznyakoff wrote: > The idea of a compendium textual domain, which > gnulib is at TP, is that a translator, preparing his localzation will > download it and merge with his translaton using msgmerge. Do you know how many translators actually do this? Very few, I would say. I don't have preci

Re: [bug-gnulib] xmalloc, xnmalloc

t on non-GCC > platforms. Maybe that's better, since it's a bit clearer anyway. Yes, I like the idea. It makes it easy to remember the names of the macros: just like the function, but uppercased. I applied the following patch. 2006-11-03 Bruno Haible <[EMAIL PROTECTED]>

C++ support (6)

To avoid C++ name mangling of the exported symbols, I applied this. 2006-11-03 Bruno Haible <[EMAIL PROTECTED]> * lib/c-ctype.h [C++]: Define functions without name mangling. * lib/fwriteerror.h [C++]: Likewise. * lib/gcd.h [C++]: Likewise. * lib/linebrea

C++ support (7)

This was an ANSI C compliance bug, but g++ stumbled upon it as well, like non-gcc C compilers would do. 2006-11-05 Bruno Haible <[EMAIL PROTECTED]> * lib/gl_array_list.c (gl_array_iterator_next): Make pointer decrement ANSI C compliant. *** gnulib-20061026/lib/gl_array_

gnulib-tool: support for subdirectories of lib/

Hi, I've been experimenting with modules that have files in subdirectories of lib/. gnulib-tool didn't handle this. With this patch, it nearly works - modulo an automake bug. 2006-11-05 Bruno Haible <[EMAIL PROTECTED]> * gnulib-tool (func_import, func_create_

Re: [bug-gnulib] Proposed Module: canonicalize-lgpl

Paul Eggert wrote: > I guess the basic idea here is that we move this module from gettext > to gnulib Yes, this is the idea. > Here is a slightly different proposal to add that module; it assumes > the 'canonicalize' changes I just installed. What do you think? Looks fine. I too like the idea o

Re: [bug-gnulib] C++ support (1)

Bob Proulx wrote: > > Compiling GNU gettext with a C++ compiler revealed a bug: an assignment > > between an 'int' variable and an 'enum' variable that was not intended. > > Although I am sure it was not intended, what bad consequences would > have resulted from the enum and int mixup? msgfmt, on

inline

Just for info. Here are some notes I collected about 'inline' three months ago. If it's too much details, skip the text until "Results" at the bottom :-) --- Use of 'inline' in function definitions

use of __gen_tempname

in related postings... I think it is preferable to build a binary that is 1 KB bigger but continues working after an OS upgrade. Hence this proposed patch. 2006-11-06 Bruno Haible <[EMAIL PROTECTED]> * lib/tempname.c (gen_tempname): Remove variant that invokes __gen_tem

Re: [bug-gnulib] xmalloc, xnmalloc

Paul Eggert wrote: > HAVE_INLINE isn't defined by xalloc.m4 or any of xalloc's prerequisites. Oops, thanks for noticing that. I'm adding this. 2006-11-06 Bruno Haible <[EMAIL PROTECTED]> * m4/inline.m4: New file. * m4/gl_list.m4 (gl_LIST): Require gl_I

Re: [bug-gnulib] xmalloc, xnmalloc

function, gdb will set a breakpoint in one of the copies, chosen randomly, not in all 30 copies. What I suggest to get around this, is to define these functions with external linkage when such a compiler is in use. To avoid code duplication, one needs to move the function definitions to a separat

Re: [bug-gnulib] new module flexmember to test for flexible array member support

Paul Eggert wrote: > * modules/flexmember, m4/flexmember.m4: New files. Nice. Maybe add a reference to ISO C99 6.7.2.1.(16) ? Also, a little bit of methodology explanation would be nice, for those who would naively want to use sizeof on such a type. *** gnulib-20061106/m4/flexmember.m4

Re: [bug-gnulib] xmalloc, xnmalloc

Hi Paul, In case HAVE_INLINE is not defined, xnmalloc is not an inline function. XNMALLOC (n, char) was optimized to a single xmalloc call. Can we restore this optimization? 2006-11-06 Bruno Haible <[EMAIL PROTECTED]> * lib/xalloc.h (XNMALLOC): Restore optimization of sizeof(

Re: [bug-gnulib] make gl_oset.h C89 compatible

Ralf Wildenhues wrote: > 2006-11-06 Ralf Wildenhues <[EMAIL PROTECTED]> > > * lib/gl_oset.h: Use C comment style, not C++ comment style. Thanks, applied. It's astonishing how long such mistakes stay, when we only use gcc and don't enable the appropriate gcc warnings (I think "gcc -ansi -p

Re: [bug-gnulib] proposed xalloc-related changes to array-list, array-oset, etc.

Paul Eggert wrote: > 2006-11-06 Paul Eggert <[EMAIL PROTECTED]> > > Simplify xmalloc expressions. Add overflow check in xmalloc arguments. > * lib/gl_anyavltree_list2.h (create_subtree_with_contents): > (gl_tree_create, gl_tree_add_first, gl_tree_add_last): > (gl_tree_add

Re: inline

Ralf Wildenhues wrote: > > Solaris 7 cclacks inline entirely > > HP-UX 11 cc has an unusable inline (return type must not be a typedef) > > IRIX 6 cc has __inline but does not understand extern __inline. > > AIX 4 xlc has __inline, uses the C99 semantics > > OSF/1 5.1 cchas

Re: gnulib-tool: support for subdirectories of lib/

Ralf Wildenhues wrote: > > I've been experimenting with modules that have files in subdirectories of > > lib/. > > gnulib-tool didn't handle this. With this patch, it nearly works - modulo > > an automake bug. > > Could you be bothered to show how to reproduce this bug? Done. Bug reported to bug

Re: [bug-gnulib] xmalloc, xnmalloc

Paul Eggert wrote: > Hmm, what if GCC's __NO_INLINE__ macro is defined? Shouldn't > m4/inline.m4 define HAVE_INLINE only if __NO_INLINE__ is not defined? Yes. I applied this. 2006-11-08 Bruno Haible <[EMAIL PROTECTED]> * m4/inline.m4 (gl_INLINE): A

Re: [bug-gnulib] xmalloc, xnmalloc

Paul Eggert wrote: > There's gotta be a better way. > > I installed the following Look fine. Thanks! > I prefer macros like "static_inline" and > "long_double" when defining macros that stand for their standard > counterparts like "static inline" and "long double". Well, I agree that 'long_doub

Re: [bug-gnulib] Re: NSK(OSS) compilation problem

s that use existing gnulib macros (such as gettext of any version <= 0.16) if they reconfigure it with a newer autoconf. Since the comment already says that when cross-compiling we can assume that the bug is not present, I'd propose to set ac_cv_type_long_long_int to the value it had b

Re: [bug-gnulib] proposed patch to allocsa, vasnprintf for Tandem NSK (OSS)

Paul Eggert wrote on 2006-10-11: > 2006-10-11 Paul Eggert <[EMAIL PROTECTED]> > > Don't assume that 64-bit signed int is available if unsigned int > is, and vice versa. > * lib/allocsa.h (sa_alignment_unsignedlonglong): New constant. > (sa_alignment_max): Don't assume tha

Re: [bug-gnulib] yet another hello pretest

more maintainable code than pervasive use of 'my_exit'. > Also, you may want to get rid of the space-tab formatting errors in your > ChangeLog. Also this one: --- tests/ChangeLog.bak 2006-08-23 15:45:59.0 +0200 +++ tests/ChangeLog 2006-11-09 17:27:58.0 +0100 @@ -

Re: [bug-gnulib] use of __gen_tempname

Eric, > > Please apply. I'm sorry that I missed this mail. Something must be wrong with my mailbox. Bruno

Re: [bug-gnulib] coreutils build failure due to missing gl_INLINE dependency

Jim Meyering wrote: > Since two other modules (oset and list) also include m4/inline.m4 > without a provision to use gl_INLINE, it's clear that it's worthwhile > to make a module out of this inline.m4 file, so I did that. Thanks!

Re: [bug-gnulib] inline.m4: use compiler, not cpp

Jim Meyering wrote: > 2006-11-10 Jim Meyering <[EMAIL PROTECTED]> > > * m4/inline.m4 (gl_INLINE): Check with the compiler, not cpp, > so that relevant options in CFLAGS (like -O, -fno-inline) are > taken into account. Thanks again! I applied this patch, with added comments, an

Re: [bug-gnulib] lib/gettext.h breaks --enable-gcc-warnings

Paul Eggert wrote: > 2006-11-09  Paul Eggert  <[EMAIL PROTECTED]> > > * lib/gettext.h (dgettext, dcgettext, ngettext) [! ENABLE_NLS]: > (dngettext, dcngettext, bindtextdomain) [! ENABLE_NLS]: > (bind_textdomain_codeset) [! ENABLE_NLS]: > Evaluate all the arguments.

Re: [bug-gnulib] yet another hello pretest

Paul Eggert wrote: > 2. The "#if ENABLE_NLS" isn't needed, since gettext.h does the right > thing anyway. > -#if ENABLE_NLS >/* Set the text message domain. */ >bindtextdomain (PACKAGE, LOCALEDIR); >textdomain (PACKAGE); > -#endif But with this, configuring with "./configure --d

Re: missing dependencies [Re: inline.m4: use compiler, not cpp

Jim Meyering wrote: > >> but there > >> is a bug (haven't investigated at all yet) whereby most of the generated > >> dependencies (lib/.deps/*.Po files) are not included into the Makefile. I agree with Ralf that it's most likely tied to the issue I reported two days ago: In summary (thanks Ralf f

Re: yet another hello pretest

Jim Meyering wrote: > Better still, add this in system.h: > > #if ! ENABLE_NLS > # undef textdomain > # define textdomain(Domainname) /* empty */ > # undef bindtextdomain > # define bindtextdomain(Domainname, Dirname) /* empty */ > #endif If you do this, you'll get "unused

Re: yet another hello pretest

Jim, > I don't see > how you could be objecting to such an addition to hello's system.h. It's up to Karl to decide what he puts into hello's system.h. I only mentioned that these definitions can _in_general_ lead to "unused variable" warnings. Bruno

Re: [bug-gnulib] Re: gnulib-tool --with-tests --test

Ralf Wildenhues wrote: > The patch below should some of the reported issues. OK to apply? Thanks for this patch. Everything except the first hunk (gl_source_base) is fine. Please apply. About the gl_source_base of the tests directory: The idea is that the tests directory has its sources separate

Re: gnulib and subdirs (was: Re: compilation rules with dependencies don't work with subdir-objects)

Hello Ralf, > FWIW, I really haven't understood what the subdir-objects case is useful > for in this context: gllib currently has a flat directory structure. > Is it just for convenience or is there a necessity behind it? gnulib's lib directory now has over 600 source files. Only Paul and I have

Re: missing dependencies [Re: inline.m4: use compiler, not cpp

he better (more flexibility - don't rely on hardcoded short-sighted automake built-in magic). I fixed the missing dependencies: 2006-11-12 Bruno Haible <[EMAIL PROTECTED]> * gnulib-tool (func_get_automake_snippet): Synthesize also an EXTRA_lib_

<    2   3   4   5   6   7   8   9   10   11   >