Re: enforcing the use of string.h related modules

Eric Blake <[EMAIL PROTECTED]> writes: > * modules/regex (Depends-on): Add mempcpy. > ... > * modules/mountlist (Depends-on): Add strstr The other parts of your patch might be needed, but these aren't quite right. As far as I can tell, regex does not depend on mempcpy, nor does mount

gnulib string module problems on Debian stable, maybe other platforms

I ran into a problem building CVS coreutils on Debian stable, since coreutils does not use some of the string.h-related modules, but Debian string.h #defines some of the symbols that string.h therefore attempts to #define to foo_is_unportable, and the #defines collide. I worked around my particula

Re: gnulib string module problems on Debian stable, maybe other platforms

Paul Eggert <[EMAIL PROTECTED]> wrote: > I ran into a problem building CVS coreutils on Debian stable, since > coreutils does not use some of the string.h-related modules, but > Debian string.h #defines some of the symbols that string.h therefore > attempts to #define to foo_is_unportable, and the

Re: enforcing the use of string.h related modules

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 2/1/2007 1:03 AM: > Eric Blake <[EMAIL PROTECTED]> writes: > >> * modules/regex (Depends-on): Add mempcpy. >> ... >> * modules/mountlist (Depends-on): Add strstr > > The other parts of your patch might be needed,

Re: enforcing the use of string.h related modules

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 2/1/2007 1:03 AM: > Eric Blake <[EMAIL PROTECTED]> writes: > >> * modules/regex (Depends-on): Add mempcpy. >> ... >> * modules/mountlist (Depends-on): Add strstr > > The other parts of your patch might be needed,

Re: enforcing the use of string.h related modules

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 1/31/2007 10:00 PM: > > Also, I noticed that the dependency of > string.h: string_h > is not strong enough - fixing your typo changed configure from declaring > GNULIB_strcase to GNULIB_STRCASE, but did not regenerate strin

strtok_r.c sync

We were syncing strtok_r.c with glibc. Now the change below was made. Should we revert the change or drop the sync? Thanks, k *** lib/strtok_r.c Sat Jan 27 00:34:48 2007 --- /tmp/strtok_r.c Thu Feb 1 00:34:15 2007 *** *** 1,4 /* Reentrant string tokenizer. Generic v

nonexistent modules

Running ./MODULES.html.sh --cvs-urls >/tmp/MODULES.html gets the following msgs about nonexistent modules. Help? gnulib-tool: module utf8-ucs4-safe doesn't exist gnulib-tool: module utf16-ucs4-safe doesn't exist gnulib-tool: module unistr/u8-mbtouc-safe doesn't exist gnulib-tool: module unistr/u

Re: gnulib string module problems on Debian stable, maybe other platforms

Jim Meyering <[EMAIL PROTECTED]> writes: > How about a c-strstr module, analogous to c-strtod? > i.e., strstr as if it were operating in the C locale. There already is a c-strstr module. But now that you mention it, why is there a c-strstr module, or a fancy strstr replacement that looks at mult

Re: [bug-gnulib] nonexistent modules

Karl Berry wrote: > Running > ./MODULES.html.sh --cvs-urls >/tmp/MODULES.html > > gets the following msgs about nonexistent modules. Oops, my fault. Fixed now: 2007-02-01 Bruno Haible <[EMAIL PROTECTED]> * MODULES.html.sh (Unicode string functions): Update after 2007-01-27 ren

Re: [bug-gnulib] strtok_r.c sync

Karl Berry wrote: > We were syncing strtok_r.c with glibc. Now the change below was made. > Should we revert the change or drop the sync? Drop the sync for the moment, until someone pushes our changes to gnulib. There is no strtok_r.h any more. Bruno

Re: [bug-gnulib] enforcing the use of string.h related modules

Eric Blake wrote: > Does this look correct to apply? The MKDIR_P changes are ok but are not yet necessary, as there is only 1 module that creates the 'arpa' subdirectory and only 1 module that creates the 'netinet' subdirectory. The Makefile dependency would be highly annoying. Many users don't u

Re: [bug-gnulib] gnulib string module problems on Debian stable, maybe other platforms

Hello Paul, > Debian string.h #defines some of the symbols that string.h therefore > attempts to #define to foo_is_unportable, and the #defines collide. Oh well. Thanks for the fix. > A program that uses mountlist shouldn't > need to use the gnulib strstr if it doesn't want to. I think it's tim

xalloc.h (x2nrealloc): Don't always double the buffer size.

For background, this thread started here: http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/9581 Andi Kleen <[EMAIL PROTECTED]> wrote: >> [*] Can you even get a 2GB-long string into expr? > > At least on Linux you can't, the kernel limits arguments and environments > to 128K or so. There ar

gl_STDARG_H on AIX 5.3 with IBM v8 C compiler

I've fetched the latest gnulib CVS and tried testing the xvasprintf module on AIX 5.3: $ ./gnulib-tool --create-testdir --dir=/home/china/tmp/z xvasprintf $ cd /home/china/tmp/z $ ./configure CC=xlc --disable-dependency-tracking ... $ gmake ... $ nm -BCpg gllib/libgnu.a|grep va_copy

Re: gnulib string module problems on Debian stable, maybe other platforms

Bruno Haible <[EMAIL PROTECTED]> writes: > I think it's time for me to report a glibc bug on strstr and > strcasestr, then... Sounds good. I didn't know there was a bug. What is the bug, out of curiosity? I don't see why multibyte characters would be relevant to the bug, since strstr is suppos

Re: [bug-gnulib] gnulib string module problems on Debian stable, maybe other platforms

> it can define GNULIB_STRSTR itself: > > dnl Tell gnulib that the non-i18n implementation of strstr() is enough > dnl for our purposes. > AC_DEFINE([GNULIB_STRSTR], 1) This sounds a bit fragile. mountlist can use a non-i18n version of strstr but maybe some mountlist-using apps can't. So it

Re: AIX incorrectly detects strndup

Matthew Woehlke <[EMAIL PROTECTED]> wrote: > ...for some reason, configure on AIX is incorrectly thinking that it has > strndup (declared, anyway) from the OS, when it does not UNLESS > '_ALL_SOURCE' is defined. This causes a build failure in xstrndup (from > coreutils 6.6, and Jim's 6.7+ snapshot

Re: xalloc.h (x2nrealloc): Don't always double the buffer size.

Jim Meyering wrote: > I've just changed xalloc's x2nrealloc to do n = 3n/2, rather than n *= 2, Which means that the time needed for realloc() will grow by a factor of 1.7 on average. If it matters - haven't measured it -, I would suggest to use - n = 2*n for n < 100, - n = 3*n/2 for n >

Re: gl_STDARG_H on AIX 5.3 with IBM v8 C compiler

Albert, Thanks for the report. Can you please elucidate three unclear points? 1) You showed this: > I'm not really sure what the xlc compiler is doing with va_copy(). In > , we have: > 88: #ifdef _ISOC99_SOURCE > 89: #define va_copy(__list1,__list2) ((void)(__list1 = __list2)) > 90: #endif

Re: gnulib string module problems on Debian stable, maybe other platforms

Paul Eggert wrote: > But I see further problems in this area. For example, > mountlist uses strstr in a system-dependent way where the ASCII-only > system strstr is just fine. A program that uses mountlist shouldn't > need to use the gnulib strstr if it doesn't want to. Indeed, the gnulib module

strstr, strcase, strcasestr, and i18n

I wrote: > I think it's time for me to report a glibc bug on strstr and strcasestr, > then... Paul Eggert wrote: > But now that you mention it, why is there a c-strstr module, or a > fancy strstr replacement that looks at multibyte characters? The situation is indeed a bit messy. Since , strtod

portability checks, errors and warnings

Paul Eggert wrote: > > it can define GNULIB_STRSTR itself: > > > > dnl Tell gnulib that the non-i18n implementation of strstr() is enough > > dnl for our purposes. > > AC_DEFINE([GNULIB_STRSTR], 1) > > This sounds a bit fragile. mountlist can use a non-i18n > version of strstr but maybe som