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
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
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
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
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 >
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
> 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
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
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
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
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
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
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
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
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
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
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
-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
-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,
-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,
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
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
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
23 matches
Mail list logo
