Re: bug#8675: error: token "@" is not valid in preprocessor expressions

[Christoph Scholtes]

On 5/18/2011 6:27 PM, Bruno Haible wrote:


So, if the reporter was using GNU make
 and the previous Makefile.in was based on gnulib 2011-04-03 or newer
 and the reporter did a make command in the top-level directory that
 recreated config.status before recursing into lib/ and then into
 src/,
then the situation cannot have occurred.


I was using Debian Squeeze with GNU make 3.81. I executed `make 
maintainer-clean' at the root and then `./configure' and `make 
bootstrap' when it failed.



If the previous Makefile.in was not based on gnulib 2011-04-03 or newer,
we need to do nothing; the problem is already fixed.


I am not sure what version of gnulib my Makefile was based on.


If the reporter did "make" in the top-level directory of emacs and it did
not rebuild config.status, even after configure changed, it needs to be
fixed in emacs.


I am not sure how to determine if this was the case, since running 
./autogen.sh, ./configure and make bootstrap fixed the problem.


Let me know if I can help to further troubleshoot this.

Christoph

Re: perror bug

[Bruno Haible]

On 2011-14-03 I wrote in
:
> With gnulib, there are three problems
> in toto:
>   1) The strerror_r replacement, when EXTEND_STRERROR_R is defined,
>      clobbers the strerror function's buffer, which it shouldn't.
>   2) The perror replacement uses strerror, thus clobbering the strerror
>      buffer.
>   3) On Cygwin, perror clobbers the strerror buffer.
> 
> The fix for 1) should be to move most of lib/strerror.c to lib/strerror_r.c.
> The fix for 2) should be to change lib/perror.c to call strerror_r.
> The fix for 3) should be to change m4/perror.m4 to enable the replacement
> on Cygwin.

Here comes the fix for 1). Tested on

  glibc 2.8
  glibc 2.8 with -D_POSIX_C_SOURCE=200112L
  MacOS X 10.5
  OpenBSD 4.4
  AIX 5.1
  AIX 6.1
  HP-UX 11.23
  HP-UX 11.31
  IRIX 6.5
  OSF/1 5.1
  Solaris 9
  Solaris 10
  mingw
  Cygwin 1.5.x


2011-05-18  Bruno Haible  

strerror_r: Avoid clobbering the strerror buffer when possible.
* lib/strerror_r.c (strerror_r): Merge the three implementations.
Handle gnulib defined errno values here. When strerror() returns NULL
or an empty string, return EINVAL.
* lib/strerror.c (strerror): Always call strerror_r. Don't handle
gnulib defined errno values here.
* modules/strerror (Depends-on): Add verify, strerror_r-posix.

*** lib/strerror.c.orig Thu May 19 05:17:36 2011
--- lib/strerror.c  Thu May 19 04:47:44 2011
***
*** 17,355 
  
  #include 
  
  #include 
  
  #if REPLACE_STRERROR
  
  # include 
  # include 
! 
! # if GNULIB_defined_ESOCK /* native Windows platforms */
! #  if HAVE_WINSOCK2_H
! #   include 
! #  endif
! # endif
  
  # include "intprops.h"
  
  /* Use the system functions, not the gnulib overrides in this file.  */
  # undef sprintf
  
- # undef strerror
- # if ! HAVE_DECL_STRERROR
- #  define strerror(n) NULL
- # endif
- 
  char *
! rpl_strerror (int n)
  {
!   char const *msg = NULL;
!   /* These error messages are taken from glibc/sysdeps/gnu/errlist.c.  */
!   switch (n)
! {
! # if GNULIB_defined_ETXTBSY
! case ETXTBSY:
!   msg = "Text file busy";
!   break;
! # endif
! 
! # if GNULIB_defined_ESOCK /* native Windows platforms */
! /* EWOULDBLOCK is the same as EAGAIN.  */
! case EINPROGRESS:
!   msg = "Operation now in progress";
!   break;
! case EALREADY:
!   msg = "Operation already in progress";
!   break;
! case ENOTSOCK:
!   msg = "Socket operation on non-socket";
!   break;
! case EDESTADDRREQ:
!   msg = "Destination address required";
!   break;
! case EMSGSIZE:
!   msg = "Message too long";
!   break;
! case EPROTOTYPE:
!   msg = "Protocol wrong type for socket";
!   break;
! case ENOPROTOOPT:
!   msg = "Protocol not available";
!   break;
! case EPROTONOSUPPORT:
!   msg = "Protocol not supported";
!   break;
! case ESOCKTNOSUPPORT:
!   msg = "Socket type not supported";
!   break;
! case EOPNOTSUPP:
!   msg = "Operation not supported";
!   break;
! case EPFNOSUPPORT:
!   msg = "Protocol family not supported";
!   break;
! case EAFNOSUPPORT:
!   msg = "Address family not supported by protocol";
!   break;
! case EADDRINUSE:
!   msg = "Address already in use";
!   break;
! case EADDRNOTAVAIL:
!   msg = "Cannot assign requested address";
!   break;
! case ENETDOWN:
!   msg = "Network is down";
!   break;
! case ENETUNREACH:
!   msg = "Network is unreachable";
!   break;
! case ENETRESET:
!   msg = "Network dropped connection on reset";
!   break;
! case ECONNABORTED:
!   msg = "Software caused connection abort";
!   break;
! case ECONNRESET:
!   msg = "Connection reset by peer";
!   break;
! case ENOBUFS:
!   msg = "No buffer space available";
!   break;
! case EISCONN:
!   msg = "Transport endpoint is already connected";
!   break;
! case ENOTCONN:
!   msg = "Transport endpoint is not connected";
!   break;
! case ESHUTDOWN:
!   msg = "Cannot send after transport endpoint shutdown";
!   break;
! case ETOOMANYREFS:
!   msg = "Too many references: cannot splice";
!   break;
! case ETIMEDOUT:
!   msg = "Connection timed out";
!   break;
! case ECONNREFUSED:
!   msg = "Connection refused";
!   break;
! case ELOOP:
!   msg = "Too many levels of symbolic links";
!   break;
! case EHOSTDOWN:
!   msg = "Host is down";
!   break;
! case EHOSTUNREACH:
!   msg = "No route to host";
!   break;
! case EPROCLIM:
!   msg = "Too many processes";
!   break;
! case EUSERS:
!   msg = "Too many users";
!   break;
! case EDQUOT:
!   msg = "Disk quota exceeded";
!   break;
! case ESTALE:
!   msg = "Stale NFS file handle"

Re: proposed new module intprops-test

[Bruno Haible]

Hi Paul,

> > ./gnulib-tool --with-tests --test intprops
> 
> Thanks, I ran that and it worked.

It fails to compile on HP-UX 11.23 and 11.31 with cc, on IRIX 6.5 with cc,
on OSF/1 5.1 with cc, and on Solaris 9 and 10 (SPARC) with cc.


Here are the error messages on HP-UX 11.23 with cc:

   cc -Ae -O -DHAVE_CONFIG_H -I.  -DGNULIB_STRICT_CHECKING=1  -I. -I.  -I.. 
-I./..  -I../gllib -I./../gllib-g -c test-intprops.c
cc: "test-intprops.c", line 116: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 116: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 116: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 117: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 117: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 117: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 120: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 120: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 120: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 121: error 1511: Bit-field size must be a constant.
cc: "test-intprops.c", line 121: error 1613: Zero-sized struct.
cc: "test-intprops.c", line 121: warning 504: The sizeof operator applied to a 
zero-sized object.
cc: "test-intprops.c", line 122: error 1511: Bit-field size must be a constant.
cc: "test-intprops.c", line 122: error 1613: Zero-sized struct.
cc: "test-intprops.c", line 122: warning 504: The sizeof operator applied to a 
zero-sized object.
cc: "test-intprops.c", line 124: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 124: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 125: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 125: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 126: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 126: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 127: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 127: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 128: error 1511: Bit-field size must be a constant.
cc: "test-intprops.c", line 128: error 1613: Zero-sized struct.
cc: "test-intprops.c", line 128: warning 504: The sizeof operator applied to a 
zero-sized object.
cc: "test-intprops.c", line 129: error 1511: Bit-field size must be a constant.
cc: "test-intprops.c", line 129: error 1613: Zero-sized struct.
cc: "test-intprops.c", line 129: warning 504: The sizeof operator applied to a 
zero-sized object.
cc: "test-intprops.c", line 135: error 1511: Bit-field size must be a constant.
cc: "test-intprops.c", line 135: error 1613: Zero-sized struct.
cc: "test-intprops.c", line 135: warning 504: The sizeof operator applied to a 
zero-sized object.
cc: "test-intprops.c", line 136: error 1511: Bit-field size must be a constant.
cc: "test-intprops.c", line 136: error 1613: Zero-sized struct.
cc: "test-intprops.c", line 136: warning 504: The sizeof operator applied to a 
zero-sized object.
cc: "test-intprops.c", line 137: error 1511: Bit-field size must be a constant.
cc: "test-intprops.c", line 137: error 1613: Zero-sized struct.
cc: "test-intprops.c", line 137: warning 504: The sizeof operator applied to a 
zero-sized object.
cc: "test-intprops.c", line 148: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 148: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 150: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 150: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 151: error 1511: Bit-field size must be a constant.
cc: "test-intprops.c", line 151: error 1613: Zero-sized struct.
cc: "test-intprops.c", line 151: warning 504: The sizeof operator applied to a 
zero-sized object.
cc: "test-intprops.c", line 154: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 156: warning 559: Constant expression overflow 
during evaluation.
cc: "test-intprops.c", line 157: error 1511: Bit-field size must be a constant.
cc: "test-intprops.c", line 157: error 1613: Zero-sized struct.
cc: "test-intprops.c", line 157: warning 504: The sizeof operator applied to a 
zero-sized object.
cc: "test-intprops.c", line 160: error 1511: Bit-field size must be a constant.
cc: "test-intprops.c", line 160: error 1613: Zero-sized struct.
cc: "test-intprops.c", line 160: warning 504: The sizeo

Re: error: token "@" is not valid in preprocessor expressions

[Bruno Haible]

Hi Paul,

> all we need to do is to have unistd.h
> depend on Makefile.  And, once unistd.h depends on Makefile
> then it need not depend on config.status (as Makefile already
> depends on config.status).  Like this:
> 
> --- a/modules/unistd
> +++ b/modules/unistd
> @@ -20,7 +20,7 @@ BUILT_SOURCES += unistd.h
>  
>  # We need the following in order to create an empty placeholder for
>  #  when the system doesn't have one.
> -unistd.h: unistd.in.h $(top_builddir)/config.status $(CXXDEFS_H) 
> $(ARG_NONNULL_H) $(WARN_ON_USE_H)
> +unistd.h: unistd.in.h Makefile $(CXXDEFS_H) $(ARG_NONNULL_H) $(WARN_ON_USE_H)
>   $(AM_V_GEN)rm -f $@-t $@ && \
>   { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
> sed -e 's|@''HAVE_UNISTD_H''@|$(HAVE_UNISTD_H)|g' \
> 

Such a change would have the effect that hand-editing a Makefile would
cause all gnulib *.h files to be regenerated and, with it, all *.o files
would be recompiled. However, hand-editing a Makefile is necessary in
two situations at least:
  1) to test a certain modification of compilation commands, before
 putting the changes into Makefile.am,
  2) to trace the effect of C compiler bugs, by compiling different
 *.o files with different compiler optimization levels.

I'm therefore vehemently opposed to such a change.

In fact, in the thread starting at
  
we developed some Automake tests for guaranteeing that everything is properly
rebuilt, and it turned out that
  1. some specific code pattern is necessary in the module descriptions, and
 it was implemented on 2011-04-03,
  2. GNU make is necessary as well.
But that's it.

So, if the reporter was using GNU make
and the previous Makefile.in was based on gnulib 2011-04-03 or newer
and the reporter did a make command in the top-level directory that
recreated config.status before recursing into lib/ and then into
src/,
then the situation cannot have occurred.

If the reporter was not using GNU make, he should do so. It has become clear
through the tests in Automake that GNU make is a requirement for rebuilds to
be reliable.

If the previous Makefile.in was not based on gnulib 2011-04-03 or newer,
we need to do nothing; the problem is already fixed.

If the reporter did "make" in the top-level directory of emacs and it did
not rebuild config.status, even after configure changed, it needs to be
fixed in emacs.

If the reporter only did "make" in the lib/ or src/ subdirectory and not
in the top-level directory, then either he needs to change his way of working,
or a rule like

  ../config.status : $(srcdir)/../configure
../config.status --recheck

needs to be added in every subdirectory's Makefile. Automake generated
Makefiles contain such a rule, so maybe that's what is missing in
emacs/src/Makefile?

Bruno
-- 
In memoriam Eli Cohen 

Re: error: token "@" is not valid in preprocessor expressions

[Paul Eggert]

On 05/18/11 13:35, Andreas Schwab wrote:
> Normally, if GNU make sees that a
> makefile is remade it rereads it automatically.

Ah, thanks, I didn't know that.  So if we care only about
GNU make, then all we need to do is to have unistd.h
depend on Makefile.  And, once unistd.h depends on Makefile
then it need not depend on config.status (as Makefile already
depends on config.status).  Like this:

--- a/modules/unistd
+++ b/modules/unistd
@@ -20,7 +20,7 @@ BUILT_SOURCES += unistd.h
 
 # We need the following in order to create an empty placeholder for
 #  when the system doesn't have one.
-unistd.h: unistd.in.h $(top_builddir)/config.status $(CXXDEFS_H) 
$(ARG_NONNULL_H) $(WARN_ON_USE_H)
+unistd.h: unistd.in.h Makefile $(CXXDEFS_H) $(ARG_NONNULL_H) $(WARN_ON_USE_H)
$(AM_V_GEN)rm -f $@-t $@ && \
{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
  sed -e 's|@''HAVE_UNISTD_H''@|$(HAVE_UNISTD_H)|g' \


Looking at the existing gnulib modules, I see that almost all of them
have the .h file depend on config.status, but there's one exception:
configmake.h depends on Makefile.  Shouldn't they all depend on
Makefile rather than on config.status?  That should have helped to
avoid this problem.

Re: error: token "@" is not valid in preprocessor expressions

[Andreas Schwab]

Paul Eggert  writes:

> I don't see how adding a dependency would fix this problem.  In this
> case, lib/Makefile in turn depended on 'configure', 'configure.in',
> 'm4/longlong.m4', etc., etc., and one of these files got updated, so
> lib/Makefile was regenerated; but as I understand it, the 'make' that was
> (still) running was based on the out-of-date lib/Makefile, and it
> generated the a bad lib/unistd.h.

Looks like an orderring problem.  Normally, if GNU make sees that a
makefile is remade it rereads it automatically.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: error: token "@" is not valid in preprocessor expressions

[Paul Eggert]

[Adding bug-gnulib to this thread.  For bug-gnulib readers, the scenario is
 in Emacs a "bzr update; make" failed with:

  ./unistd.h:1186:5: error: token "@" is not valid in preprocessor expressions

 because unistd.h was built with the old Makefile.
 Full thread at .
]

On 05/18/11 05:39, Andreas Schwab wrote:
> If that does not work, then proper dependencies are missing.

I don't see how adding a dependency would fix this problem.  In this
case, lib/Makefile in turn depended on 'configure', 'configure.in',
'm4/longlong.m4', etc., etc., and one of these files got updated, so
lib/Makefile was regenerated; but as I understand it, the 'make' that was
(still) running was based on the out-of-date lib/Makefile, and it
generated the a bad lib/unistd.h.

Adding a dependency "unistd.h: Makefile" wouldn't fix this problem.

This sort of problem is not due to gnulib per se; it's inherent to any
project that uses makefiles.  In general, if a patch modifies a
makefile, or anything the makefile depends on, then you must
regenerate everything from scratch with a fresh 'make' invocation.

That being said, I've run into Christoph's problem myself more than
once, and it's a hassle, and it'd be nice to address it somehow.  How
about this idea?  I expect it would have worked around this problem.
Currently lib/Makefile contains something like this:

unistd.h: 


Suppose we change this rule to look like this:

unistd.h: Makefile 
case ' $? ,$(USING_NEW_MAKEFILE)' in \
  *' Makefile '*,) \
exec $(MAKE) $(AM_MAKEFLAGS) USING_NEW_MAKEFILE=yes $@;; \
esac; \


This would be a gnulib change, so I'll CC: this to bug-gnulib.
A similar pattern would apply to every module that generates
a .h file with a big hairy command that uses 'make' variables.

[PATCH] fnmatch: avoid compiler warning

[Eric Blake]

Detected on Ubuntu 10.04, where the glibc fnmatch fix is not yet
present; also reproduced via:
$ gl_cv_func_fnmatch_posix=no CFLAGS=-Wall \
./gnulib-tool --with-tests --test fnmatch

In file included from gllib/fnmatch.c:172:0:
gllib/fnmatch_loop.c: In function ‘internal_fnmatch’:
gllib/fnmatch_loop.c:203:28: error: initialization discards qualifiers from 
pointer target type
gllib/fnmatch_loop.c:204:28: error: initialization discards qualifiers from 
pointer target type

* lib/fnmatch_loop.c (FCT): Use correct type.
Reported by Matthias Bolte.

Signed-off-by: Eric Blake 
---
 ChangeLog  |6 ++
 lib/fnmatch_loop.c |4 ++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index ffea473..99e2c3e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2011-05-18  Eric Blake  
+
+   fnmatch: avoid compiler warning
+   * lib/fnmatch_loop.c (FCT): Use correct type.
+   Reported by Matthias Bolte.
+
 2011-05-13  Jim Meyering  

maint.mk: three new prohibit__without_use rules
diff --git a/lib/fnmatch_loop.c b/lib/fnmatch_loop.c
index 1fb246f..8334491 100644
--- a/lib/fnmatch_loop.c
+++ b/lib/fnmatch_loop.c
@@ -200,8 +200,8 @@ FCT (const CHAR *pattern, const CHAR *string, const CHAR 
*string_end,
 case L_('['):
   {
 /* Nonzero if the sense of the character class is inverted.  */
-CHAR *p_init = p;
-CHAR *n_init = n;
+const CHAR *p_init = p;
+const CHAR *n_init = n;
 register bool not;
 CHAR cold;
 UCHAR fn;
-- 
1.7.4.4

Re: [libvirt] [PATCH] Ensure virStrerror always sets an error string

[Daniel P. Berrange]

On Wed, May 18, 2011 at 11:27:28AM -0600, Eric Blake wrote:
> [adding bug-gnulib]
> 
> On 05/18/2011 11:07 AM, Daniel P. Berrange wrote:
> > strerror_r() is free to not set any error string, if the passed
> > errno is not valid. It may, however, still return a pointer to
> > the original passed in buffer. This resulting in random garbage
> > from the stack being present as the error string.
> 
> Indeed.  However, I'm inclined to NACK the libvirt patch, because:
> 
> Right now, gnulib guarantees that strerror() always gives a useful
> result (non-empty string for all errno values, even though POSIX allows
> an empty string), but the strerror_r-posix module is not making those
> same guarantees.
> 
> Therefore, I argue that this is a bug in gnulib.  We should be changing
> the strerror_r-posix module to guarantee sane behavior, rather than just
> bare-minimum compliance, even if that means replacing strerror_r on a
> few more platforms.

Yeah, if gnulib wants to fix this, that's fine with me.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

Re: [libvirt] [PATCH] Ensure virStrerror always sets an error string

[Eric Blake]

[adding bug-gnulib]

On 05/18/2011 11:07 AM, Daniel P. Berrange wrote:
> strerror_r() is free to not set any error string, if the passed
> errno is not valid. It may, however, still return a pointer to
> the original passed in buffer. This resulting in random garbage
> from the stack being present as the error string.

Indeed.  However, I'm inclined to NACK the libvirt patch, because:

Right now, gnulib guarantees that strerror() always gives a useful
result (non-empty string for all errno values, even though POSIX allows
an empty string), but the strerror_r-posix module is not making those
same guarantees.

Therefore, I argue that this is a bug in gnulib.  We should be changing
the strerror_r-posix module to guarantee sane behavior, rather than just
bare-minimum compliance, even if that means replacing strerror_r on a
few more platforms.

> +++ b/src/util/virterror.c
> @@ -1267,9 +1267,13 @@ const char *virStrerror(int theerrno, char *errBuf, 
> size_t errBufLen)
>  int save_errno = errno;
>  const char *ret;
>  
> +memset(errBuf, 0, errBufLen);

That's a bit time-consuming, especially if errBufLen is MUCH bigger than
the message to be printed.  It would suffice to simply do *errbuf=0.

>  strerror_r(theerrno, errBuf, errBufLen);
>  ret = errBuf;
>  errno = save_errno;
> +
> +if (ret[0] == '\0')
> +strncpy(errBuf, _("Unknown errno"), errBufLen);
>  return ret;
>  }
>  

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: socketless platforms?

[Eric Blake]

On 05/18/2011 10:18 AM, Sam Steingold wrote:
> is there such a thing as a platform without socket support?
> if yes, how do I detect that after I call gl_SOCKETLIB?

Not all platforms support Unix sockets (AF_UNIX/AF_LOCAL is lacking on
mingw) or IPv6 sockets (AF_INET6 is lacking on various platforms).  For
that matter, you could probably find a platform these days where AF_INET
(IPv4) is useless, although it will probably still compile and just be a
runtime failure.  Other address families supported by Linux are
non-standard, and unlikely to work in portable code.

But pretty much every platform has some form of socket support.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

socketless platforms?

[Sam Steingold]

is there such a thing as a platform without socket support?
if yes, how do I detect that after I call gl_SOCKETLIB?
-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://www.memritv.org http://openvotingconsortium.org
http://pmw.org.il http://honestreporting.com http://palestinefacts.org
I'd give my right arm to be ambidextrous.

GNULIB_PORTCHECK

[Sam Steingold]

what does GNULIB_PORTCHECK mean?
e.g.,
./config.log:REPLACE_TIMEGM='GNULIB_PORTCHECK'
the only mention I see is time_h.m4:
  dnl If another module says to replace or to not replace, do that.
  dnl Otherwise, replace only if someone compiles with -DGNULIB_PORTCHECK;
  dnl this lets maintainers check for portability.
I am confused (as usual, alas...)

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://www.memritv.org http://pmw.org.il http://mideasttruth.com
http://www.PetitionOnline.com/tap12009/ http://openvotingconsortium.org
Just because you're paranoid doesn't mean they AREN'T after you.

Re: include without check

[Eric Blake]

On 05/18/2011 09:18 AM, Eric Blake wrote:
> On 05/18/2011 07:37 AM, Sam Steingold wrote:
>> sys_uio.in.h includes  without #ifdef HAVE_SYS_TYPES_H.
>> can this file be assumed to be present on all platforms including mingw?
> 
> gnulib/doc/posix-headers/sys_types.texi does not list any platform where
> it is missing.  Yes, you can assume this file is present everywhere.

Also from gnulib's README:

Because we assume a freestanding C89 compiler, Gnulib code can include
, , , and  unconditionally.  It
can also assume the existence of , , ,
, , , , , and .
Similarly, many modules include  even though it's not even
in C99; that's OK since  has been around nearly forever.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: include without check

[Eric Blake]

On 05/18/2011 07:37 AM, Sam Steingold wrote:
> sys_uio.in.h includes  without #ifdef HAVE_SYS_TYPES_H.
> can this file be assumed to be present on all platforms including mingw?

gnulib/doc/posix-headers/sys_types.texi does not list any platform where
it is missing.  Yes, you can assume this file is present everywhere.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

include without check

[Sam Steingold]

sys_uio.in.h includes  without #ifdef HAVE_SYS_TYPES_H.
can this file be assumed to be present on all platforms including mingw?
-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://palestinefacts.org http://mideasttruth.com http://pmw.org.il
http://honestreporting.com http://thereligionofpeace.com http://truepeace.org
MS Windows: error: the operation completed successfully.

[PATCH] maint.mk: three new prohibit__without_use rules

[Jim Meyering]

FYI, three more prohibit__without_use rules:

>From 2c25c9ebe8db1415bfde25f0a451767332c8cf59 Mon Sep 17 00:00:00 2001
From: Jim Meyering 
Date: Fri, 13 May 2011 23:35:48 +0200
Subject: [PATCH] maint.mk: three new prohibit__without_use rules

* top/maint.mk (sc_prohibit_stdio--_without_use): New rule.
(sc_prohibit_stdio-safer_without_use): Likewise.
(sc_prohibit_xfreopen_without_use): Likewise.
---
 ChangeLog|7 +++
 top/maint.mk |   14 ++
 2 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index c326081..ffea473 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2011-05-13  Jim Meyering  
+
+   maint.mk: three new prohibit__without_use rules
+   * top/maint.mk (sc_prohibit_stdio--_without_use): New rule.
+   (sc_prohibit_stdio-safer_without_use): Likewise.
+   (sc_prohibit_xfreopen_without_use): Likewise.
+
 2011-05-17  Jim Meyering  

announce-gen: fail if the NEWS delta is empty
diff --git a/top/maint.mk b/top/maint.mk
index d0d33e4..c838516 100644
--- a/top/maint.mk
+++ b/top/maint.mk
@@ -568,6 +568,16 @@ sc_prohibit_signal_without_use:
re='\<($(_sig_function_re)) *\(|\<($(_sig_syms_re))\>'  \
  $(_sc_header_without_use)

+# Don't include stdio--.h unless you use one of its functions.
+sc_prohibit_stdio--_without_use:
+   @h='"stdio--.h"' re='\<((f(re)?|p)open|tmpfile) *\('\
+ $(_sc_header_without_use)
+
+# Don't include stdio-safer.h unless you use one of its functions.
+sc_prohibit_stdio-safer_without_use:
+   @h='"stdio-safer.h"' re='\<((f(re)?|p)open|tmpfile)_safer *\('  \
+ $(_sc_header_without_use)
+
 # Prohibit the inclusion of strings.h without a sensible use.
 # Using the likes of bcmp, bcopy, bzero, index or rindex is not sensible.
 sc_prohibit_strings_without_use:
@@ -595,6 +605,10 @@ sc_prohibit_stddef_without_use:
re='\<($(_stddef_syms_re)) *\(' \
  $(_sc_header_without_use)

+# Don't include xfreopen.h unless you use one of its functions.
+sc_prohibit_xfreopen_without_use:
+   @h='"xfreopen.h"' re='\' \
halt='do not use HAVE''_FCNTL_H or O'_NDELAY\
--
1.7.5.1.341.g177b8

Re: [PATCH] maint.mk: add a syntax-check rule to ensure tightly-scoped symbols

[Jim Meyering]

Pádraig Brady wrote:
> On 17/05/11 15:23, Pádraig Brady wrote:
>> Given '^__.*' names are reserved by the compiler,
>> perhaps the happy medium is to to allow single underscores,
>> but exclude double underscores, with something like:
>
> I'm going with the following, so as to not put the
> onus on users configuring an exclude list, to include
> the __.* pattern.

> Subject: [PATCH] maint.mk: exclude compiler symbols from sc_tight_scope
...
> @@ -1391,7 +1394,7 @@ _gl_tight_scope: $(bin_PROGRAMS)
>  test -f $$f && d= || d=$(srcdir)/; echo $$d$$f; done`;   \
>   hdr=`for f in $(noinst_HEADERS); do \
>  test -f $$f && d= || d=$(srcdir)/; echo $$d$$f; done`;   \
> - ( printf '^%s$$\n' $(_gl_TS_unmarked_extern_functions); \
> + ( printf '^%s$$\n' '__.*' $(_gl_TS_unmarked_extern_functions);  \
> grep -h -A1 '^extern .*[^;]$$' $$src  \
>   | grep -vE '^(extern |--)' | sed 's/ .*//'; \
> perl -lne '$(_gl_TS_function_match)'  \
> @@ -1400,7 +1403,7 @@ _gl_tight_scope: $(bin_PROGRAMS)
>   nm -e *.$(OBJEXT) | sed -n 's/.* T //p' | grep -Ev -f $$t   \
> && { echo the above functions should have static scope >&2;   \
>  exit 1; } || : ; \
> - ( printf '^%s$$\n' $(_gl_TS_unmarked_extern_vars);  \
> + ( printf '^%s$$\n' '__.*' $(_gl_TS_unmarked_extern_vars);   \
> perl -lne '$(_gl_TS_var_match) and print "^$$1\$$"'   \
>   $$hdr *.h ) | sort -u > $$t;\
>   nm -e *.$(OBJEXT) | sed -n 's/.* [BCDGRS] //p'  \

Perfect.  Thanks!