-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 4/28/2008 5:20 PM:
| Eric Blake byu.net> writes:
|
|> Meanwhile, adding rawmemchr would speed up the (corner) case of
|> strchrnul(s,0), but I haven't tackled that yet.
|
| Here it is, plus another potential C99 read-beyond
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I was planning on optimizing getndelim2 to use the new extended stdio
functions for speed. But before I can do that, I need to make sure I
avoid regressions, so I'm checking this in. This also adds file locking
(similar to getdelim), but I wasn't su
> 2008-04-20 Bruno Haible <[EMAIL PROTECTED]>
>
> * lib/c-stack.c (die): Use raise.
> * modules/c-stack (Depends-on): Add raise.
Paul did not speak up in a week, so I applied this.
Bruno
> Also now I added the rpmatch declaration to the file (this is
> where glibc has it):
And here's the yesno.c update:
2008-04-28 Bruno Haible <[EMAIL PROTECTED]>
Expect rpmatch to be declared.
* lib/yesno.c (rpmatch): Remove declaration.
*** lib/yesno.c.orig2008-04-29 03
Jim Meyering wrote:
> Looks good to me.
Also, Eric was positive. So I applied it.
Also now I added the rpmatch declaration to the file (this is
where glibc has it):
2008-04-28 Bruno Haible <[EMAIL PROTECTED]>
Declare rpmatch.
* lib/stdlib.in.h (rpmatch): New declaration.
Eric Blake byu.net> writes:
> Meanwhile, adding rawmemchr would speed up the (corner) case of
> strchrnul(s,0), but I haven't tackled that yet.
Here it is, plus another potential C99 read-beyond-end violation. I'll follow
Bruno's advice and add .valgrind files for strchrnul and rawmemchr next,
Eric Blake <[EMAIL PROTECTED]> writes:
> Simon Josefsson josefsson.org> writes:
>
>>
>> Eric Blake byu.net> writes:
>>
>> > I think it would be even simpler to just avoid intprops.h (after all,
>> > memchr.c was originally borrowed from glibc, which doesn't have
>> > intprops.h).
>>
>> I like
Ben Pfaff wrote:
> This approach will cause false-positive warnings under memory
> debuggers such as Valgrind.
Good point.
> However, anyone who notices such a
> warning should be able to spot from the comments in the function
> that it is still correct code given the assumption you have
> above,
Ralf Wildenhues wrote:
> Wouldn't it be more useful if, instead of listing Linux/x86, the
> glibc version that had this bug was listed (and maybe the GCC
> version used);
It would be useful if there was some hope that glibc be more defensive
against these bit patterns that are outside the IEEE 754
Simon Josefsson josefsson.org> writes:
>
> Eric Blake byu.net> writes:
>
> > I think it would be even simpler to just avoid intprops.h (after all,
> > memchr.c was originally borrowed from glibc, which doesn't have
> > intprops.h).
>
> I like that.
OK, I've done it for memchr, memrchr, strch
Ben Pfaff cs.stanford.edu> writes:
> > Any objections against this patch? I ask because it intentionally
> > violates the C99 constraint of not reading beyond the end of an array.
> > However, the excess read can only occur on the final longword of an array,
> > and only with an aligned longword
Yoann Vandoorselaere <[EMAIL PROTECTED]> wrote:
> Le samedi 26 avril 2008 à 02:31 +0200, Bruno Haible a écrit :
>> Yoann Vandoorselaere wrote:
>> > I guess mkdir could use the original malloc implementation, returning an
>> > error on allocation failure. Or is that a problem?
>>
>> Sounds ok to me:
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Here is a proposed compromise that enables the strict POSIX behaviour when
> POSIXLY_CORRECT is set. This is a POSIX compliance fix for the programs
> 'cp', 'mv', 'rm', 'find', 'xargs'.
>
> This is a continuation of the approach presented last year in
> h
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> Hi Simon,
>
> * Simon Josefsson wrote on Mon, Apr 28, 2008 at 04:39:08PM CEST:
>> --- a/m4/sys_socket_h.m4
>> +++ b/m4/sys_socket_h.m4
>> @@ -45,6 +45,7 @@ AC_DEFUN([gl_HEADER_SYS_SOCKET],
>>HAVE_WINSOCK2_H=0
>>HAVE_WS2TCPIP_H=0
>>
Eric Blake <[EMAIL PROTECTED]> writes:
> I think it would be even simpler to just avoid intprops.h (after all,
> memchr.c was originally borrowed from glibc, which doesn't have
> intprops.h).
I like that.
Thanks,
Simon
Hello Bruno,
* Bruno Haible wrote on Sun, Apr 27, 2008 at 02:11:56PM CEST:
> On mingw, the test-isfinite test failed:
>
> test-isfinite.c:169: assertion failed
> FAIL: test-isfinite.exe
>
> And after adding the same tests as for isnan(long double) - namely, that
> signalling NaNs, pseudo-den
Hi Simon,
* Simon Josefsson wrote on Mon, Apr 28, 2008 at 04:39:08PM CEST:
> --- a/m4/sys_socket_h.m4
> +++ b/m4/sys_socket_h.m4
> @@ -45,6 +45,7 @@ AC_DEFUN([gl_HEADER_SYS_SOCKET],
>HAVE_WINSOCK2_H=0
>HAVE_WS2TCPIP_H=0
> else
> + AC_REQUIRE([AC_C_INLINE])
>HAVE_S
Eric Blake <[EMAIL PROTECTED]> writes:
> Any objections against this patch? I ask because it intentionally
> violates the C99 constraint of not reading beyond the end of an array.
> However, the excess read can only occur on the final longword of an array,
> and only with an aligned longword read
- Original Message -
From: "Eric Blake" <[EMAIL PROTECTED]>
To: "Brian K. White" <[EMAIL PROTECTED]>
Cc: ; <[EMAIL PROTECTED]>
Sent: Tuesday, April 08, 2008 8:39 AM
Subject: Re: fpurge.c, freadahead.c, freading.c make wrong assumption
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
Simon Josefsson josefsson.org> writes:
> > 2008-04-26 Eric Blake byu.net>
> > Bruno Haible clisp.org>
> >
> > * lib/memchr.c: Include intprops.h.
>
> This causes a license incompatibility for GnuTLS:
>
> This causes license incompatibility because intprops is LGPL:
> gnulib
Bruno Haible <[EMAIL PROTECTED]> writes:
> Hi Simon,
>
>> I would also favor removing both inet_ntop.h and inet_pton.h, and use
>> arpa/inet.h for the declarations, as you suggested.
>
> Me too.
Yoann, Bruno,
I've pushed the following, please test it.
/Simon
>From 33d11481e0930865b73ae2cf69403f
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> +# if defined _WIN32 || defined __WIN32__
>
> This is not the right preprocessor test for mingw: It may also evaluate to
> true on Cygwin. But Cygwin has the right declaration of setsockopt and does
> not need a fix. The right #i
Bruno Haible <[EMAIL PROTECTED]> writes:
> Also, the memrchr module does not support the renaming in config.h that
> is used to guarantee namespace cleanliness of shared libraries. E.g.
> #define memrchr libfoo_memrchr
Interesting, are you using such renaming in some project? Can gnulib
genera
Bruno Haible <[EMAIL PROTECTED]> writes:
> Eric Blake asked:
>> Also, is anyone interested in making gnulib's memchr and strchrnul more
>> efficient by copying the optimizations learned in memchr2?
>
> Checked in like this:
>
> 2008-04-26 Eric Blake <[EMAIL PROTECTED]>
> Bruno Haibl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 4/23/2008 3:24 PM:
| Also, is anyone interested in making gnulib's memchr and strchrnul more
| efficient by copying the optimizations learned in memchr2? Also, should we
| provide a replacement for glibc's rawmemchr (surpri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 4/27/2008 5:27 PM:
| Hi Jim,
|
|> The only non-POSIX behaviour is that it fetches the yesexpr and noexpr from
|> a compiled PO file rather than from the system's nl_langinfo function.
|
| Here is a proposed compromise that
Noticed this while reading Yoann's proposed patch.
2008-04-28 Bruno Haible <[EMAIL PROTECTED]>
* doc/posix-functions/strdup.texi: Mention mingw problem.
*** doc/posix-functions/strdup.texi.orig2008-04-28 11:24:14.0
+0200
--- doc/posix-functions/strdup.texi 2008-04-
Le samedi 26 avril 2008 à 02:31 +0200, Bruno Haible a écrit :
> Yoann Vandoorselaere wrote:
> > I guess mkdir could use the original malloc implementation, returning an
> > error on allocation failure. Or is that a problem?
>
> Sounds ok to me: There is no reason why a system call replacement like
28 matches
Mail list logo
