Hi Paul,
> > $ git stash
> > $ git pull
> > $ git stash apply
> > # fix conflicts then "git commit" of the merged files
>
> Alas, the first step doesn't work; git says "No local changes to
> save".
Then the two "git stash" commands were unnecessary; all that's needed is
$ git pu
On OpenBSD 4.0, the tdelete() function has an incorrect return value when
removing the last element from a tree. This works around it.
2008-01-09 Bruno Haible <[EMAIL PROTECTED]>
Work around OpenBSD 4.0 tdelete() bug.
* m4/tsearch.m4 (gl_FUNC_TSEARCH): Also check tdelete's retur
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 1/9/2008 4:16 PM:
| May I commit these additional tweaks? Clearer documentation, less surprising
| configure output, more maintainable module descriptions.
Yes, please commit. Thanks
- --
Don't work too hard, make some t
I wrote:
> This should detect this bug:
>
>
> 2008-01-08 Bruno Haible <[EMAIL PROTECTED]>
>
> * m4/wcwidth.m4 (gl_FUNC_WCWIDTH): Test also U+3000. Needed to
> detect bug on OpenBSD 4.0.
> * doc/functions/wcwidth.texi: Document the OpenBSD bug.
Well, it did not fix the testsu
James Youngman wrote:
> Lots of packages get bug reports for releases that are pretty old.
> The idea behind this module is to allow the --version output to emit a
> warning when the release is very old, asking the reader to try
> upgrading before reporting a bug. You might use it like this for
>
Lots of packages get bug reports for releases that are pretty old.
The idea behind this module is to allow the --version output to emit a
warning when the release is very old, asking the reader to try
upgrading before reporting a bug. You might use it like this for
example:-
/* emit the standa
Eric Blake wrote:
> * m4/memmem.m4 (gl_FUNC_MEMMEM_SIMPLE): New macro.
> (gl_FUNC_MEMMEM): Separate performance from presence checks.
> * modules/memmem-simple: New file.
> * modules/memmem (Description): Tweak.
> * MODULES.html.sh (string handling): Mention it.
> * doc/functions/memmem.texi (memme
Simon Josefsson wrote:
> Here is a starting point for a new memmem-simple module. What do you
> think?
> ...
> diff --git a/m4/memmem.m4 b/m4/memmem.m4
> index 9767354..10d6f5a 100644
> --- a/m4/memmem.m4
> +++ b/m4/memmem.m4
> @@ -1,4 +1,4 @@
> -# memmem.m4 serial 7
> +# memmem.m4 serial 8
> dnl
Eric Blake <[EMAIL PROTECTED]> writes:
> Simon Josefsson josefsson.org> writes:
>
>> > return !result || !memmem ("a", 1, 0, 0);]])],
>> >
>> Ah, thanks. This was not part of the old memmem.m4 checks. Still, the
>> glibc documentation (which I regard as the memmem specification) doesn't
>>
Simon Josefsson josefsson.org> writes:
> > return !result || !memmem ("a", 1, 0, 0);]])],
> >
> Ah, thanks. This was not part of the old memmem.m4 checks. Still, the
> glibc documentation (which I regard as the memmem specification) doesn't
> say what should be returned for empty needles.
Here is a starting point for a new memmem-simple module. What do you
think?
/Simon
modules/memmem-simple:
Description:
memmem() function: locate first substring in a buffer.
Files:
lib/memmem.c
m4/memmem.m4
Depends-on:
extensions
string
stdint
memchr
memcmp
configure.ac:
gl_FUNC_MEMMEM_SIMPL
Eric Blake <[EMAIL PROTECTED]> writes:
> Simon Josefsson josefsson.org> writes:
>
>>
>> > (remember, however, that the system memmem may be broken, as on
>> > cygwin).
>>
>> Did the old check find that brokenness? Has this brokenness been
>> discussed before, and was a m4 test to detect it pro
Simon Josefsson josefsson.org> writes:
>
> > (remember, however, that the system memmem may be broken, as on
> > cygwin).
>
> Did the old check find that brokenness? Has this brokenness been
> discussed before, and was a m4 test to detect it produced? I can't see
> anything in memmem.m4 about
Eric Blake <[EMAIL PROTECTED]> writes:
> According to Simon Josefsson on 1/9/2008 3:16 AM:
> |
> | For gnutls, the strings are always the same (X.509 PEM headers), and we
> | haven't seen such slowdowns even on large inputs (searching for a 10
> | byte needle in a 500kb input is, while not typical
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Simon Josefsson on 1/9/2008 3:16 AM:
|
| For gnutls, the strings are always the same (X.509 PEM headers), and we
| haven't seen such slowdowns even on large inputs (searching for a 10
| byte needle in a 500kb input is, while not typical,
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> I reviewed the memmem situation for gnutls, and the recent changes are
>> somewhat large. Memmem now pulls in:
>>
>> ! lgl/m4/eealloc.m4
>> ! lgl/m4/malloca.m4
>> ! lgl/malloca.c
>> ! lgl/malloca.h
>> ! lgl/malloca.valgrind
>
>
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> I can reproduce it locally using:
>>
>> [EMAIL PROTECTED]:~$ gnulib-tool --with-tests --test unictype/category-and
>>
>> but I don't understand why it is failing. Any ideas? Can others
>> reproduce this?
>
> Sure I reproduce
Colin Watson wrote:
> The attached updated patches address your concerns and Paul's
Thanks; looks better now. Two points still:
- This code will not compile with C89 compilers on platforms without
threading, due to the semicolon:
strsignal (int signum)
{
__libc_once_define (static, onc
18 matches
Mail list logo
