I have trouble using obstacks with my threaded server, since obstack's
error handling is not thread safe. It provides a user defined
function `obstack_alloc_failed_handler' to signal errors when
allocation fails, and this function can call longjmp instead of
exiting. But I can only call longjmp
Bruno Haible wrote:
> Hello Sylvain,
>
> Sylvain Beucler wrote:
> > I see that under Woe, MAX_PATH is the equivalent for PATH_MAX, and is
> > set to 260 in MinGW's headers (windef.h).
>
> An old copy of mingw defines PATH_MAX already in :
>
> /*
>* File system limits
>*
>* TODO: NA
Sylvain Beucler <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
> > For starters, in code intended to be portable, it's best not
> > to rely on PATH_MAX, if at all possible. At a bare minimum,
> > don't use it as an array size, and don't try to allocate
> > PATH_MAX bytes from the heap. On some
Hello Herbert Euler,
> Below is my patch to obstack
gnulib provides for obstack the same API as glibc. It makes no sense for
gnulib to provide a variant of obstack that has features that glibc does
not have.
Therefore the right place to post your patch is either the libc-alpha
AT sourceware DOT
Herbert Euler wrote:
> But I can only call longjmp with a global jmp_buf, since
> this function is called with no arguments.
Here is a 4th way to solve this: Write an obstack_alloc_failed_handler
that throws a C++ exception, and have a catcher for this exception installed
in each thread.
Bruno
The autoconf manual recommends to use "test -h", not "test -L".
2007-08-26 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_ln_if_changed): Use "test -h", not "test -L".
--- gnulib-tool 23 Jul 2007 22:08:02 - 1.252
+++ gnulib-tool 26 Aug 2007 10:28:47 -
@@ -409,7 +409,
Eric Blake wrote:
> For findutils, I recently added a patch to the import-gnulib.sh script to
> call 'find -L -lname '*' -delete' after the fact (yes, this is GNU find
> specific, but does the job of deleting all broken symlinks). But it would
> be better if gnulib-tool and bootstrap were taught t
Sylvain Beucler wrote:
> PATH_MAX is however not defined under the visual c++ 6 / free version
> that I'm using for the port. ...
Ahem, you call that "free"?
- As far as I remember, Microsoft did not give the permission to
redistribute the copies, and they have meanwhile removed it from thei
Ludovic Courtès wrote:
> >We work around such problems by doing the override at the preprocessor
> >level, rather than at the link level. I.e. on a system where strcasecmp
> >is or may be defined at libc level, gnulib does
> > #define strcasecmp rpl_strcasecmp
> >and defines rp
Hi Simon,
> This causes vasnprintf.lo to be built, even though I don't need it!
>
> [EMAIL PROTECTED]:~/src/gnutls/lgl$ ls *.lo
> asnprintf.lo gc-libgcrypt.lomd2.lo printf-parse.lo
> vasnprintf.lo
> dummy.lo gc-pbkdf2-sha1.lo printf-args.lo read-file.lo
> [EMAIL PROTECTED]:
On Sun, Aug 26, 2007 at 01:28:35PM +0200, Bruno Haible wrote:
> Sylvain Beucler wrote:
> > PATH_MAX is however not defined under the visual c++ 6 / free version
> > that I'm using for the port. ...
>
> Ahem, you call that "free"?
> - As far as I remember, Microsoft did not give the permission to
Hi Jim,
> I did most of this weeks ago and just noticed I never checked it in.
> Ok with you, Bruno?
I'll make up my mind on it once you have put an 'mreadlink' module into
gnulib. I don't see such a module in gnulib, nor in coreutils. Remember
that the difference between xreadlink_with_size and
Thank you for the suggestions.
> Below is my patch to obstack
gnulib provides for obstack the same API as glibc. It makes no sense for
gnulib to provide a variant of obstack that has features that glibc does
not have.
Therefore the right place to post your patch is either the libc-alpha
AT sou
Herbert Euler wrote:
> But I have many
> obstacks in my program, so I am having to choose one of them
> accordingly. ... That is why I want to call
> `obstack_alloc_failed_handler' with a user provided argument.
I fully agree that there is an issue here. If the obstack API was
designed today, th
But the facility of obstacks is in glibc for 10 years now. This means,
it will get hard for you to convince the glibc maintainers.
I have improved my patch and sent it to libc-alpha. Let's wait the
result. Thank you.
> The third one requires more libraries to be linked with and I do not
want
15 matches
Mail list logo
