On Wednesday 27 May 2009 01:18:26 Simon Josefsson wrote:
> Mike Frysinger writes:
> > On Tuesday 26 May 2009 19:13:51 Bruno Haible wrote:
> >> Mike Frysinger wrote:
> >> > it's disabled explicitly because we dont want multibyte sucking up
> >> > space on a system that doesnt need it. there are a f
Mike Frysinger writes:
> On Tuesday 26 May 2009 19:13:51 Bruno Haible wrote:
>> Mike Frysinger wrote:
>> > it's disabled explicitly because we dont want multibyte sucking up space
>> > on a system that doesnt need it. there are a few packages (like zile)
>> > which dont currently have a way of d
Bruno Haible writes:
> Eric Blake wrote:
>
>> +strtok_r: use rawmemchr for speed.
>> +* lib/strtok_r.c (__rawmemchr): Use faster rawmemchr.
>> +* modules/strtok_r (Depends-on): Add rawmemchr.
>> ...
>> Likewise, what about these other modules that only use strchr to find the
>> termi
On Tuesday 26 May 2009 19:13:51 Bruno Haible wrote:
> Mike Frysinger wrote:
> > it's disabled explicitly because we dont want multibyte sucking up space
> > on a system that doesnt need it. there are a few packages (like zile)
> > which dont currently have a way of disabling the multibyte workarou
Mike Frysinger wrote:
> it's disabled explicitly because we dont want multibyte sucking up space on a
> system that doesnt need it. there are a few packages (like zile) which dont
> currently have a way of disabling the multibyte workarounds.
Do you think it will take less space if each of thes
Eric Blake wrote:
> + strtok_r: use rawmemchr for speed.
> + * lib/strtok_r.c (__rawmemchr): Use faster rawmemchr.
> + * modules/strtok_r (Depends-on): Add rawmemchr.
> ...
> Likewise, what about these other modules that only use strchr to find the
> terminating byte of a known-termin
Bruno Haible clisp.org> writes:
>
> Eric Blake wrote:
> > http://www.alphalinux.org/archives/axp-list/March2001/0337.shtml
> >
> > It looks like the bug is alpha-specific in memchr
>
> I don't think it is a bug. memchr could also be implemented by doing
> a backwards search and still be confor
On Tuesday 26 May 2009 18:40:23 Bruno Haible wrote:
> Mike Frysinger wrote:
> > i dont see any checks/replacements for when MB_CUR_MAX does not exist
>
> This is because MB_CUR_MAX is part of ANSI C + amendment 1 (ca. 1995), and
> no platforms are known that lack it (see
> gnulib/doc/posix-headers/
Mike Frysinger wrote:
> i dont see any checks/replacements for when MB_CUR_MAX does not exist
This is because MB_CUR_MAX is part of ANSI C + amendment 1 (ca. 1995), and
no platforms are known that lack it (see gnulib/doc/posix-headers/stdlib.texi).
Likewise for mbtowc(): It's present on all platf
Eric Blake wrote:
> http://www.alphalinux.org/archives/axp-list/March2001/0337.shtml
>
> It looks like the bug is alpha-specific in memchr
I don't think it is a bug. memchr could also be implemented by doing
a backwards search and still be conforming to ISO C99 and POSIX:
void *memchr(const vo
looking through the gnulib source code, i dont see any checks/replacements for
when MB_CUR_MAX does not exist (like in a uClibc build where all multibyte
related stuff has been disabled). for example, zile falls apart like so:
../../zile-2.3.7/lib/mbrtowc.c: In function ‘rpl_mbrtowc’:
../../zile
I did a quick audit of all uses of memchr, considering that there is a proposal
to un-obsolete the memchr module now that we have identified glibc bugs in
platform-specific implementations for two different platforms. The choice of
whether to beef up the memchr module depends on whether or not
ممكن نتعرف
Eric Blake writes:
> Simon Josefsson josefsson.org> writes:
>
>> >> + * tests/test-strstr.c: Add another self-test.
>> >>{
>> >> +/* See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521737 */
>> >> +char *input = strdup ("aBaaax");
>> >
>> > Did you take the proper precau
Simon Josefsson josefsson.org> writes:
> >> + * tests/test-strstr.c: Add another self-test.
> >>{
> >> +/* See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521737 */
> >> +char *input = strdup ("aBaaax");
> >
> > Did you take the proper precautions to ensure strdup is ava
Eric Blake writes:
> According to Simon Josefsson on 5/26/2009 6:15 AM:
>> +2009-05-26 Simon Josefsson
>> +
>> +* tests/test-strstr.c: Add another self-test.
>>{
>> +/* See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521737 */
>> +char *input = strdup ("aBaaax");
>
Eric Blake writes:
> According to Simon Josefsson on 5/26/2009 6:48 AM:
>> I'm not sure, it isn't clear that this particular strstr problem is a
>> common problem.
>>
>> I think the first step is to add this to the self-test. If we get
>> reports about it, we can try to learn which platforms an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 5/26/2009 6:56 AM:
> Yes, adding to the test is a good first step, and we can use the feedback
> to decide how much else we might need to do. Is the bug also present in
> gnulib's strstr replacement?
To answer my own questi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Simon Josefsson on 5/26/2009 6:15 AM:
> +2009-05-26 Simon Josefsson
> +
> + * tests/test-strstr.c: Add another self-test.
>{
> +/* See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521737 */
> +char *input = strdup ("
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Simon Josefsson on 5/26/2009 6:48 AM:
> I'm not sure, it isn't clear that this particular strstr problem is a
> common problem.
>
> I think the first step is to add this to the self-test. If we get
> reports about it, we can try to learn
Eric Blake writes:
> According to Simon Josefsson on 5/26/2009 6:15 AM:
>>{
>> +/* See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521737 */
>> +char *input = strdup ("aBaaax");
>> +const char *result = strstr (input, "B1x");
>
> Does this mean we also need to beef up
Bruno Haible writes:
> Simon Josefsson wrote:
>> Bruno, what do you think about simply deprecating the size_max module?
>
> This would cause problems in libintl. The intl/ directory, when shipped
> as part of a package that used gettextize, should not create its own copy
> of stdint.h.
Btw, why
Bruno Haible writes:
> Simon Josefsson wrote:
>> Bruno, what do you think about simply deprecating the size_max module?
>
> This would cause problems in libintl. The intl/ directory, when shipped
> as part of a package that used gettextize, should not create its own copy
> of stdint.h. But the in
Bruno Haible writes:
>> I got a report about SIZE_MAX problems:
>>
>> In file included from ../gnutls_int.h:29,
>> from opencdk.h:30,
>> from kbnode.c:31:
>> ../config.h:357:1: warning: "SIZE_MAX" redefined
>> In file included from ./../gl/stdlib.h:52,
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Simon Josefsson on 5/26/2009 6:15 AM:
>{
> +/* See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521737 */
> +char *input = strdup ("aBaaax");
> +const char *result = strstr (input, "B1x");
Does this mean we als
Bruno Haible writes:
> Simon Josefsson wrote:
>> The getdelim module already implicitly depends on stdint
>
> I don't think it did. 'realloc-posix' depends on stdlib, not stdint.
> So what you added is a new dependency.
The stdlib module depends on stdint.
> Some people, like Sam Steingold, wan
Pushed.
/Simon
---
ChangeLog |4
tests/test-strstr.c | 10 +-
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 993b6ad..96d5f10 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2009-05-26 Simon Josefsson
+
+
27 matches
Mail list logo
