regex: malloc 0 bytes

Hello, another patch for new regex module: Stepan - Forwarded message from Yuri Vasilevski <[EMAIL PROTECTED]> - Date: Tue, 23 Aug 2005 23:17:40 -0500 To: [EMAIL PROTECTED] Subject: Bug Report: sed-4.1.4 misinterprets uClibc's malloc (patch included) Hi, Recent versions of sed expect g

Re: error: possibly undefined macro: AC_CHECK_HEADERS_ONCE

Hello, On Tue, Aug 23, 2005 at 04:41:22PM -0400, Sam Steingold wrote: > GNU CLISP comes with regex.c and it places it in the "current" > directory. > clisp/modules/regexp/configure.in > has > gl_INCLUDED_REGEX([regex.c]) > and files files > clisp/modules/regexp/regex.h > clisp/modules/regexp/regex

Re: regex & g++

> * Paul Eggert <[EMAIL PROTECTED]> [2005-08-23 13:35:05 -0700]: > > Sam Steingold <[EMAIL PROTECTED]> writes: > >> c++ is stricter, so if the code can be compiled with c++ it is probably >> safer. > > That doesn't match my experience. To make C code work with C++, I > often have to introduce cast

Re: Possible spurious cycle detection with fts

Jim Meyering meyering.net> writes: > I've just checked in these changes: > > 2005-08-14 Jim Meyering meyering.net> > > Sync from coreutils. > > > * fts.c [! _LIBC]: Include "lstat.h" rather than rolling our own. > * fts.c (fd_safer): Remove decl. > Include fcntl--.h

Re: error: possibly undefined macro: AC_CHECK_HEADERS_ONCE

> * Paul Eggert <[EMAIL PROTECTED]> [2005-08-23 11:49:25 -0700]: > > Bruno Haible <[EMAIL PROTECTED]> writes: > >> That appears to be obsolete. As far as I see, there are no users of this >> macro which don't also bundle regex.c. > > Yes, that sounds right. I installed this patch into gnulib, and

Re: getpass: use of termios.h problematic

Simon Josefsson <[EMAIL PROTECTED]> writes: > Further, lib/getpass.c look quite unreadable. Even the code in glibc > look much friendlier. > > I propose to adopt the current glibc code, and #if HAVE_TERMIOS_H and > #if TCGETATTR protect it. If there are no objections, I'll propose a > patch with

Re: regex & g++

Sam Steingold <[EMAIL PROTECTED]> writes: > c++ is stricter, so if the code can be compiled with c++ it is probably > safer. That doesn't match my experience. To make C code work with C++, I often have to introduce casts (e.g., to convert void * to char *, or to convert one integer type to anoth

regex.h REG_ENOSYS patch for POSIX and portability

It looks like I spoke too soon and that we still have some regex problems. Among other things, there seem to be several problems with the POSIX name space restrictions in regex.h. To get the ball rolling I installed this: 2005-08-23 Paul Eggert <[EMAIL PROTECTED]> * config/srclist.txt

Re: getdelim doesn't set errno on failure?

On Tuesday, August 23, 2005 at 17:59, Jim Meyering wrote: > Oskar Liljeblad <[EMAIL PROTECTED]> wrote: > > I don't know if this is necessary or necessarily correct, but > > it seems getdelim doesn't always set errno on failure (when it > > returns -1). > > > > From what I can tell, the test below (

Re: Documentation bug in regex.h?

Re . Yes, that is a documentation bug. I installed this patch and filed a glibc bug report. 2005-08-23 Paul Eggert <[EMAIL PROTECTED]> * config/srclist.txt: Add glibc bug 1232. * lib/regex.h (RE_NO_EMPTY_RANGE

Re: error: possibly undefined macro: AC_CHECK_HEADERS_ONCE

Bruno Haible <[EMAIL PROTECTED]> writes: > That appears to be obsolete. As far as I see, there are no users of this > macro which don't also bundle regex.c. Yes, that sounds right. I installed this patch into gnulib, and then reindented. 2005-08-23 Paul Eggert <[EMAIL PROTECTED]> * m

removed unnecessary forward decls in regex_internal.c, regexec.c

I installed this into gnulib and filed a glibc bug report. This handles all pending regex problems that I know about in gnulib. Does anyone know of any others? If not, I'd like to start pushing these changes into glibc. 2005-08-23 Paul Eggert <[EMAIL PROTECTED]> * config/srclist.txt:

Re: regex & g++

> * Ben Pfaff <[EMAIL PROTECTED]> [2005-08-23 11:00:25 -0700]: > Sam Steingold <[EMAIL PROTECTED]> writes: >> g++ cannot compile regex, possibly because of K&R style: > Why is it desirable to compile C code as C++? c++ is stricter, so if the code can be compiled with c++ it is probably safer. also

Re: regex & g++

Sam Steingold <[EMAIL PROTECTED]> writes: > g++ cannot compile regex, possibly because of K&R style: Why is it desirable to compile C code as C++? -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org ___ bug-gnulib mailing list bug-gnulib

Re: regex & g++

> * Paul Eggert <[EMAIL PROTECTED]> [2005-08-20 00:44:38 -0700]: > > Sam Steingold <[EMAIL PROTECTED]> writes: > >> g++ cannot compile regex, possibly because of K&R style: > > I installed the following patch into gnulib in an attempt to fix this, > and also submitted the corresponding bug reports

Re: getline: protect prototype better

Simon Josefsson wrote: > This was also discovered while porting GNU SASL to uClinux. > > Perhaps I should investigate how difficult it would be to make uClinux > run ./configure properly instead of maintaining the HAVE_* symbols > manually. Definitely. uClinux has a shell and a compilation environ

Re: getline: protect prototype better

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> This was also discovered while porting GNU SASL to uClinux. >> >> Perhaps I should investigate how difficult it would be to make uClinux >> run ./configure properly instead of maintaining the HAVE_* symbols >> manually. > > Defin

Re: quotearg.c fails when multibyte processing is disabled

Simon Josefsson wrote: > > The invocation of AC_TYPE_MBSTATE_T in m4/quotearg.m4 is supposed to > > already handle this. On which system did you encounter the problem? > > I'm porting GNU SASL to uClinux, and it doesn't run configure, rather > I'm managing the config.h symbols by hand. Then you ha

Re: quotearg.c fails when multibyte processing is disabled

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> How about this? >> >> 2005-08-23 Simon Josefsson <[EMAIL PROTECTED]> >> >> * quotearg.c [!HAVE_MBRTOWC]: Map mbstate_t to int, so that >> compilation suceed when multibyte processing is disabled. > > The invocation of

Re: getline: protect prototype better

Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> How about this? If for some reason HAVE_DECL_GETLINE is not defined >> at all, the header file fail to parse. > > What's the point in trying to use lib/getline.c without m4/getline.m4 ? > We engage ourselves to maintain both in

Re: [bug-gnulib] quotearg.c fails when multibyte processing is disabled

Simon Josefsson wrote: > How about this? > > 2005-08-23 Simon Josefsson <[EMAIL PROTECTED]> > > * quotearg.c [!HAVE_MBRTOWC]: Map mbstate_t to int, so that > compilation suceed when multibyte processing is disabled. The invocation of AC_TYPE_MBSTATE_T in m4/quotearg.m4 is supposed to

Re: [bug-gnulib] getdelim doesn't set errno on failure?

Oskar Liljeblad wrote: > I don't know if this is necessary or necessarily correct, but > it seems getdelim doesn't always set errno on failure (when it > returns -1). It is also not specified to do so. 'getdelim' is a glibc invention, and the glibc manual says: "If an error occurs or end of fi

Re: [bug-gnulib] getline: protect prototype better

Simon Josefsson wrote: > How about this? If for some reason HAVE_DECL_GETLINE is not defined > at all, the header file fail to parse. What's the point in trying to use lib/getline.c without m4/getline.m4 ? We engage ourselves to maintain both in sync, since they are part of a single gnulib module

Re: getline: protect prototype better

Simon Josefsson <[EMAIL PROTECTED]> wrote: > How about this? If for some reason HAVE_DECL_GETLINE is not defined > at all, the header file fail to parse. This uses the idiom that is > suggested by the autoconf manual. > > 2005-08-23 Simon Josefsson <[EMAIL PROTECTED]> > > * getline.h (get

Re: getdelim doesn't set errno on failure?

Oskar Liljeblad <[EMAIL PROTECTED]> wrote: > I don't know if this is necessary or necessarily correct, but > it seems getdelim doesn't always set errno on failure (when it > returns -1). > > From what I can tell, the test below (needed < cur_len) is to > test for overflow. Right. How about using E

Re: getline: protect prototype better

Simon Josefsson <[EMAIL PROTECTED]> writes: > How about this? If for some reason HAVE_DECL_GETLINE is not defined > at all, the header file fail to parse. This uses the idiom that is > suggested by the autoconf manual. > > 2005-08-23 Simon Josefsson <[EMAIL PROTECTED]> > > * getline.h (g

getdelim doesn't set errno on failure?

I don't know if this is necessary or necessarily correct, but it seems getdelim doesn't always set errno on failure (when it returns -1). >From what I can tell, the test below (needed < cur_len) is to test for overflow. Oskar Liljeblad ([EMAIL PROTECTED]) Index: getdelim.c ==

getline: protect prototype better

How about this? If for some reason HAVE_DECL_GETLINE is not defined at all, the header file fail to parse. This uses the idiom that is suggested by the autoconf manual. 2005-08-23 Simon Josefsson <[EMAIL PROTECTED]> * getline.h (getline): Protect prototype better. --- getline.h 17

quotearg.c fails when multibyte processing is disabled

How about this? 2005-08-23 Simon Josefsson <[EMAIL PROTECTED]> * quotearg.c [!HAVE_MBRTOWC]: Map mbstate_t to int, so that compilation suceed when multibyte processing is disabled. --- quotearg.c 16 Jul 2005 21:29:14 +0200 1.45 +++ quotearg.c 23 Aug 2005 13:25:06 +0200