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 @@ -56,6 +56,7 @@ # define mbrtowc(pwc, s, n, ps) ((*(pwc) = *(s)) != 0) # define iswprint(wc) isprint ((unsigned char) (wc)) # undef HAVE_MBSINIT +# define mbstate_t int #endif #if !defined mbsinit !HAVE_MBSINIT ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
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 Jul 2005 11:39:14 +0200 1.16 +++ getline.h 23 Aug 2005 13:28:13 +0200 @@ -23,6 +23,6 @@ # include stdio.h # include sys/types.h -#if !HAVE_DECL_GETLINE +#if defined(HAVE_DECL_GETLINE) !HAVE_DECL_GETLINE ssize_t getline (char **lineptr, size_t *n, FILE *stream); #endif /* !HAVE_GETLINE */ ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
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
===
RCS file: /cvsroot/gnulib/gnulib/lib/getdelim.c,v
retrieving revision 1.1
diff -u -p -r1.1 getdelim.c
--- getdelim.c 2 Aug 2005 09:33:30 - 1.1
+++ getdelim.c 23 Aug 2005 14:38:56 -
@@ -28,6 +28,11 @@
#include getdelim.h
+/* Some systems, like OSF/1 4.0 and Woe32, don't have EOVERFLOW. */
+#ifndef EOVERFLOW
+# define EOVERFLOW E2BIG
+#endif
+
#if !HAVE_FLOCKFILE
# undef flockfile
# define flockfile(x) ((void) 0)
@@ -86,6 +91,7 @@ getdelim (char **lineptr, size_t *n, int
if (needed cur_len)
{
+ errno = EOVERFLOW;
result = -1;
goto unlock_return;
}
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
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 (getline): Protect prototype better. --- getline.h 17 Jul 2005 11:39:14 +0200 1.16 +++ getline.h 23 Aug 2005 13:28:13 +0200 @@ -23,6 +23,6 @@ # include stdio.h # include sys/types.h -#if !HAVE_DECL_GETLINE +#if defined(HAVE_DECL_GETLINE) !HAVE_DECL_GETLINE A symbol that is not defined expands in the preprocessor to 0, so the former should parse properly. If it does not, then the latter will not parse properly either. The latter can be preferred because of its different meaning, not because it should parse properly when the former does not. Furthermore, in gnulib we know that the test will be performed, so I don't see a reason to prefer the latter. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
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. Anyone using only the .c file but not the .m4 will have endless maintenance problems anyway. Bruno ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
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 already handle this. On which system did you encounter the problem? Bruno ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
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. Definitely. uClinux has a shell and a compilation environment (and you can also cross-compile to it). That's exactly what autoconf was designed for. Right, although now I was incorporating GNU SASL into the uClinux build framework. All autoconf based programs that have been ported to uClinux appear to use hand-written Makefile's. The reason I went through the hassle of incorporating GNU SASL into the uClinux framework was to get the tools included in the uClinux generated ROMFS root file system automatically. But it is likely much simpler to cross-compile it first (which, incidentally, I've already done), and manually move the tools on to the root file system. I'll likely do that, thanks for the heads-up. Regards, Simon ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
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 environment (and you can also cross-compile to it). That's exactly what autoconf was designed for. Bruno ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: regex g++
Sam Steingold [EMAIL PROTECTED] writes: g++ cannot compile regex, possibly because of KR 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@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
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] * m4/regex.m4 (gl_INCLUDED_REGEX): Remove; no longer used. All contents moved to gl_REGEX. (gl_REGEX): Don't bother checking whether lib/regex.c exists; assume that it does. --- m4/regex.m4 21 Aug 2005 00:51:27 - 1.41 +++ m4/regex.m4 23 Aug 2005 18:46:22 - @@ -1,4 +1,4 @@ -#serial 25 +#serial 26 # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005 Free # Software Foundation, Inc. @@ -12,13 +12,6 @@ dnl Mostly written by Jim Meyering. AC_DEFUN([gl_REGEX], [ - gl_INCLUDED_REGEX([lib/regex.c]) -]) - -dnl Usage: gl_INCLUDED_REGEX([lib/regex.c]) -dnl -AC_DEFUN([gl_INCLUDED_REGEX], - [ AC_LIBSOURCES( [regcomp.c, regex.c, regex.h, regex_internal.c, regex_internal.h, regexec.c]) @@ -103,10 +96,6 @@ AC_DEFUN([gl_INCLUDED_REGEX], ac_use_included_regex=no fi -test -n $1 || AC_MSG_ERROR([missing argument]) -m4_syscmd([test -f '$1']) -ifelse(m4_sysval, 0, - [ AC_ARG_WITH([included-regex], [ --without-included-regex don't compile regex; this is the default on systems with recent-enough versions of the GNU C @@ -117,10 +106,7 @@ AC_DEFUN([gl_INCLUDED_REGEX], AC_LIBOBJ([regex]) gl_PREREQ_REGEX fi - ], -) - ] -) +]) # Prerequisites of lib/regex.c and lib/regex_internal.c. AC_DEFUN([gl_PREREQ_REGEX], ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
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 (needed cur_len) is to test for overflow. Right. How about using ENOMEM instead? Yes, that would be useful. It is hard as it is to handle errors from getline. Also the documentation from GNU libc seems wrong: If an error occurs or end of file is reached without any bytes read, `getline' returns `-1'. Here's what getdelim in Gnulib returns: -1, errno=EINVAL(an argument is NULL) -1, errno!=0(malloc failed, assuming malloc set errno) =0, errno undefined, feof (getc returned EOF, reached end of file) =0, errno!=0, ferror (getc returned EOF, read failed) -1, errno undefined (arithmetic overflow) -1, errno!=0(realloc failed, assuming realloc set errno) So getline/getdelim only returns -1 on invalid arguments or an out of memory condition, never on I/O errors or EOF! Or did I miss something? Regards, Oskar Liljeblad ([EMAIL PROTECTED]) ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
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: Add glibc bug 1233.
* lib/regex.h (REG_NOSYS)
[!defined _XOPEN_SOURCE 200112L = _POSIX_C_SOURCE]:
Define, since POSIX requires it as of 2001.
(_REG_ENOSYS) [! (defined _XOPEN_SOURCE || 200112L = _POSIX_C_SOURCE)]:
New private symbol, used to keep the enum signed in all cases.
--- config/srclist.txt 23 Aug 2005 19:11:46 - 1.80
+++ config/srclist.txt 23 Aug 2005 20:19:48 -
@@ -107,6 +107,7 @@ $LIBCSRC/posix/regex.c lib gpl
# http://sources.redhat.com/bugzilla/show_bug.cgi?id=1207
# http://sources.redhat.com/bugzilla/show_bug.cgi?id=1222
# http://sources.redhat.com/bugzilla/show_bug.cgi?id=1232
+# http://sources.redhat.com/bugzilla/show_bug.cgi?id=1233
#$LIBCSRC/posix/regex.hlib gpl
#
# http://sources.redhat.com/bugzilla/show_bug.cgi?id=1215
--- lib/regex.h 23 Aug 2005 19:11:46 - 1.29
+++ lib/regex.h 23 Aug 2005 20:19:48 -
@@ -309,8 +309,10 @@ extern reg_syntax_t re_syntax_options;
`re_error_msg' table in regex.c. */
typedef enum
{
-#ifdef _XOPEN_SOURCE
+#if defined _XOPEN_SOURCE || 200112L = _POSIX_C_SOURCE
REG_ENOSYS = -1, /* This will never happen for this implementation. */
+#else
+ _REG_ENOSYS = -1,/* This is so that reg_errcode_t is always signed. */
#endif
REG_NOERROR = 0, /* Success. */
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
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 another). These casts reduce
reliability, since they can mask real problems when they are done
incorrectly. As a general rule I therefore prefer C code to have as
few casts as C allows.
I don't use C++, so I'll need your help here. Is there some simple
way that we can work around this in the regex code, without having to
make wholesale changes? For example, can we surround all the code
with extern C { ... } when compiling with C++?
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
