Bruno Haible [EMAIL PROTECTED] writes:
2006-07-27 Bruno Haible [EMAIL PROTECTED]
* m4/stdint.m4 (gl_STDINT_H): Define __STDC_CONSTANT_MACROS during the
test.
* lib/stdint_.h (INT*_C, UINT*_C) [C++]: Define these if
__STDC_CONSTANT_MACROS is defined, not if
Bruno Haible [EMAIL PROTECTED] writes:
Here, as well as in many other places (including 'stdint'), we assume that
int and int32_t are the same. I don't wish to add more #ifdefs for cases
that are hypothetical.
I was worried about the case where an implementation provides a
conforming stdint.h
Eric Blake [EMAIL PROTECTED] writes:
m4/ChangeLog:
2006-07-23 Eric Blake [EMAIL PROTECTED]
* unistd-safer.m4 (gl_UNISTD_SAFER): Check for missing pipe.
2006-07-23 Eric Blake [EMAIL PROTECTED]
* pipe-safer.c (pipe_safer) [!HAVE_FUNC_PIPE]: Provide fallback to
avoid
Yoann Vandoorselaere wrote:
#include sys/types.h
#include sys/socket.h
+
+#ifdef HAVE_NETINET_IN_H
+# include netinet/in.h
+#endif
+
#ifdef HAVE_ARPA_INET_H
# include arpa/inet.h
#endif
Also, how about using #if instead of #ifdef, like in the rest of gnulib?
***
Hi,
Yoann Vandoorselaere wrote:
mbchar.h make direct use of the iswcntrl function which is not available
on some system. I made a patch using the same workaround as is done in
mbswidth.c, although I'm not sure this is valid.
Just for info: Which system is this which has a wchar.h and a
On Fri, 2006-07-28 at 14:18 +0200, Bruno Haible wrote:
Hi,
Yoann Vandoorselaere wrote:
mbchar.h make direct use of the iswcntrl function which is not available
on some system. I made a patch using the same workaround as is done in
mbswidth.c, although I'm not sure this is valid.
Just
Yoann Vandoorselaere wrote:
Just for info: Which system is this which has a wchar.h and a wctype.h
header file but no iswcntrl function? The isw* functions are the main
contents of wctype.h. I don't expect a system to have wctype.h
but lack the functions.
FreeBSD 4.x got the wctype.h
On Fri, 2006-07-28 at 17:35 +0200, Bruno Haible wrote:
Yoann Vandoorselaere wrote:
Just for info: Which system is this which has a wchar.h and a wctype.h
header file but no iswcntrl function? The isw* functions are the main
contents of wctype.h. I don't expect a system to have wctype.h
On Fri, 2006-07-28 at 17:44 +0200, Yoann Vandoorselaere wrote:
On Fri, 2006-07-28 at 17:35 +0200, Bruno Haible wrote:
Yoann Vandoorselaere wrote:
Just for info: Which system is this which has a wchar.h and a
wctype.h
header file but no iswcntrl function? The isw* functions are the
Yoann Vandoorselaere [EMAIL PROTECTED] writes:
On Fri, 2006-07-28 at 14:13 +0200, Bruno Haible wrote:
Yoann Vandoorselaere wrote:
#include sys/types.h
#include sys/socket.h
+
+#ifdef HAVE_NETINET_IN_H
+# include netinet/in.h
+#endif
+
#ifdef HAVE_ARPA_INET_H
# include
Paul Eggert [EMAIL PROTECTED] writes:
I noticed that recent changes (merging from gettext, for example)
added many ChangeLog entries whose dates disagree with when the change
was installed into gnulib. Hence gnulib's ChangeLog file appears not
to be in reverse chronological order. This
[EMAIL PROTECTED] writes:
Yoann Vandoorselaere [EMAIL PROTECTED] writes:
On Fri, 2006-07-28 at 14:13 +0200, Bruno Haible wrote:
Yoann Vandoorselaere wrote:
#include sys/types.h
#include sys/socket.h
+
+#ifdef HAVE_NETINET_IN_H
+# include netinet/in.h
+#endif
+
#ifdef
/Simon wrote:
Emacs doesn't highlight this new format well.
This is a poor argument:
1) Emacs ChangeLog highlighting is known for not even supporting
enumerations of functions, broken across lines:
2005-05-11 Bruno Haible [EMAIL PROTECTED]
* flo_rest.d
Paul Eggert eggert at CS.UCLA.EDU writes:
With Bison I wanted fopen_safer but not tmpfile_safer (I think tmpfile
is not that safe due to signals and whatnot), so I split the fopen-safer
module into two, as follows:
/usr/ucb/cc on Solaris 7 didn't like fopen-safer or tmpfile-safer:
cc -Xc
Is it worth silencing these compiler warnings with /usr/ucb/cc on Solaris 7?
../../lib/regex_internal.h, line 714: warning: token-less macro argument
../../lib/regexec.c, line 1412: warning: non-constant initializer: op --
--
Eric Blake
On glibc platforms, error_at_line currently violates GNU coding standards when
the output stream is in wide character mode. OK to apply? Does this need to
be pushed to glibc?
2006-07-28 Eric Blake [EMAIL PROTECTED]
* error.c (error_at_line): Fix typo in wide string.
Index:
Eric Blake [EMAIL PROTECTED] writes:
On glibc platforms, error_at_line currently violates GNU coding standards
when
the output stream is in wide character mode. OK to apply? Does this need to
be pushed to glibc?
Is it useful if it isn't pushed to glibc? It only updates code
inside an
Ben Pfaff blp at cs.stanford.edu writes:
Is it useful if it isn't pushed to glibc? It only updates code
inside an #ifdef _LIBC block.
Actually, a different bug is present on non glibc platforms. When file_name is
NULL, error_at_file omits the required space in program: message. My
[EMAIL PROTECTED] writes:
Emacs doesn't highlight this new format well. Care to bring this idea
up on, e.g., emacs-devel?
I'm a bit stretched for time right now, but you're welcome to bring it
up, as an Emacs issue or as a GNU coding standards issue or both.
I suppose it'd be nice if Emacs
Eric Blake [EMAIL PROTECTED] writes:
2006-07-28 Eric Blake [EMAIL PROTECTED]
* error.c (error_at_line): Match GNU Coding Standards.
The change looks good, but the ChangeLog entry is a bit terse; could
you please modify it to explain the bug it fixes.
Man, I wish there were an
Eric Blake [EMAIL PROTECTED] writes:
Is it worth silencing these compiler warnings with /usr/ucb/cc on Solaris 7?
../../lib/regex_internal.h, line 714: warning: token-less macro argument
This one is worth fixing, since the code does not conform to C89. The
obvious fix is to surround that
21 matches
Mail list logo
