Re: Lua and signal handlers

Reuben Thomas wrote:
> The Lua bindings install a single signal handler that triggers a
> callback at Lua's equivalent of a breakpoint. Obviously this is not
> useful for everything, but it suffices, for example, to write handlers
> for SIGTSTP and SIGWINCH (as Zile uses).

And you can guarantee that in the signal handler, Lua will not call any
libc functions other than the ones listed in the table at the end of
section 2.4.3 in
<http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html>?

Bruno

Re: bug#10639: BUG REPORT coreutils-8.15 Solaris 10 64bit

On 01/30/2012 07:01 PM, JONES, BILL wrote:
> those are vxfs.

Thanks, can you please try the attached patch?
You can apply it by running the shell commands:

  cd lib
  patch < vxfs-patch.txt

I'll CC: this to bug-gnulib as it appears to be a Gnulib bug.

Thanks.

acl: fix infinite loop on Solaris 10 + vxfs
Problem reported by Bill Jones in
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10639>.
* lib/acl-internal.h: Include <limits.h>.
(MIN): New macro.
* lib/copy-acl.c (qcopy_acl): Don't object if we get fewer ACL
entries than we originally counted; perhaps some were removed
as we were running, or perhaps we can count but not get.
Check for size-calculation overflow.
Avoid need for dynamic allocation if possible.
* lib/file-has-acl.c (file_has_acl): Likewise.
* lib/set-mode-acl.c (qset_acl): Likewise.
diff --git a/lib/acl-internal.h b/lib/acl-internal.h
index 88e5e45..64701b2 100644
--- a/lib/acl-internal.h
+++ b/lib/acl-internal.h

Re: bug#10639: BUG REPORT coreutils-8.15 Solaris 10 64bit

Paul Eggert wrote:
> Thanks, can you please try the attached patch?

I find it overkill to change the code for HP-UX and NonStop systems
when the report is about Solaris. Also I think the structure of the loop
is not the problem; it is the code's reaction to
  acl("x", ACE_GETACL, 4, 0x3432A16E0)            Err#-1

Please, can you also try this patch?

Re: bug#10639: BUG REPORT coreutils-8.15 Solaris 10 64bit

On 02/01/2012 02:22 AM, Bruno Haible wrote:
> I find it overkill to change the code for HP-UX and NonStop systems
> when the report is about Solaris. Also I think the structure of the loop
> is not the problem; it is the code's reaction to
>   acl("x", ACE_GETACL, 4, 0x3432A16E0)            Err#-1

The patch you sent looks like it'll fix that particular bug, but while
looking into this I discovered so many bugs in this area, mostly
hard-to-test race conditions and overflows, that I thought it better
to rewrite the affected code than to try to fix each bug one at a time.
I didn't write this up very well, and my first cut at doing this could
stand some improvements of its own.  Here's a revised patch that tries
to do a better job at all this.  (If it's any consolation, this patch
makes the code simpler -- 186 lines shorter....)

diff --git a/ChangeLog b/ChangeLog
index f80c7dd..ec16bef 100644
--- a/ChangeLog
+++ b/ChangeLog
 <at>  <at>  -1,3 +1,89  <at>  <at> 
+2012-02-01  Paul Eggert  <eggert <at> cs.ucla.edu>
+
+	acl: fix several problems with ACLs
+	Problem with infinite loop on Solaris 10 + vxfs reported by Bill
+	Jones in <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10639>.
+	Looking into the code, I saw several closely related issues:
+
+	 - There's a race condition in this kind of code:
+
+	     n = acl (f, GETACLCNT, 0, NULL);

[PATCH] file-has-acl: suppress a warning from gcc -Wsuggest-attribute=const

FYI,

From 93f8bee70d1bc611bead8a826edf0a932c2b8999 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering <at> redhat.com>
Date: Thu, 2 Feb 2012 09:12:13 +0100
Subject: [PATCH] file-has-acl: suppress a warning from gcc
 -Wsuggest-attribute=const

* lib/file-has-acl.c (file_has_acl): This function (for some #ifdefs)
would evoke a new gcc warning.  Given all of the #ifdefs, it is better
not even to try to add the attribute.  Instead, add a pragma to suppress
the suggestion/warning.
---
 ChangeLog          |    8 ++++++++
 lib/file-has-acl.c |    6 ++++++
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index f80c7dd..9c5a3cd 100644
--- a/ChangeLog
+++ b/ChangeLog
 <at>  <at>  -1,3 +1,11  <at>  <at> 
+2012-02-02  Jim Meyering  <meyering <at> redhat.com>
+
+	file-has-acl: suppress a warning from gcc -Wsuggest-attribute=const
+	* lib/file-has-acl.c (file_has_acl): This function (for some #ifdefs)
+	would evoke a new gcc warning.  Given all of the #ifdefs, it is better
+	not even to try to add the attribute.  Instead, add a pragma to suppress
+	the suggestion/warning.
+

fpurge.c on Plan9/APE

dear list,

I am trying to port some GNU stuff to Plan9 and hit a problem with
gnulib fpurge.c bundled in one application.

the requested info from APE (Ansi Posix Environment under Plan9) stdio.h:

fflush:
extern int fflush(FILE *);

setvbuf:
extern int setvbuf(FILE *, char *, int, size_t);

ungetc:
extern int ungetc(int, FILE *);

Which option in fpurge should I use? Or do I need a custom made one
and how should that one look?

Re: fpurge.c on Plan9/APE

On 02/02/2012 03:04 AM, Jens Staal wrote:
> do I need a custom made one
> and how should that one look?

That's what it looks like.  You can start by inspecting
<stdio.h> and look for fields in its FILE * structure.

AM_CPPFLAGS best practice

The manual (gnulib-tool.texi) recommends including both builddir and
srcdir into AM_CPPFLAGS (aka INCLUDES if you are using automake 1.9),
which makes sense, since some headers come straight from gnulib and live
in srcdir, while other headers are generated based on configure results
and thus live in builddir.  But which order is preferred?

The gnulib manual recommends:
AM_CPPFLAGS = -I$(top_builddir)/lib -I$(top_srcdir)/lib

But m4 is using the reverse order:
AM_CPPFLAGS = -I$(top_srcdir)/lib -I../lib

And coreutils has a bug, for forgetting the builddir version (which
means it will build in an in-tree build, but probably fail in a VPATH
build):
AM_CPPFLAGS = -I$(top_srcdir)/lib

Is there any specific reason that gnulib recommends builddir (generated
files) before srcdir?  Consider the ramifications if a file changes
location.  If it goes from generated to in-place (moves from builddir to
srcdir, because it no longer depends on configure results), then
favoring builddir first means that in an incremental build where you
forget to run 'make clean' before updating gnulib, the stale generated
header will be left over in the build tree and be picked up in
preference to the new gnulib file.  Conversely, if a header goes from
in-place to generated, it will no longer live in srcdir, but only in
builddir, so it doesn't matter whether you favor builddir or srcdir.
Therefore, it seems to me that best practice would be to always favor
srcdir first, builddir second.

Re: AM_CPPFLAGS best practice

On Thursday 02 February 2012 15:10:11 Eric Blake wrote:
> Is there any specific reason that gnulib recommends builddir (generated
> files) before srcdir?

my gut tends to prefer builddir over srcdir.  but that could be due more to 
poorly managed packages than a "best practices" setup.  in cases where a 
header file is shipped as part of the distribution and is *usually* used, but 
could possibly be regenerated (and thus show up in the builddir), we'd want 
the builddir version over the srcdir one.

> Consider the ramifications if a file changes
> location.  If it goes from generated to in-place (moves from builddir to
> srcdir, because it no longer depends on configure results), then
> favoring builddir first means that in an incremental build where you
> forget to run 'make clean' before updating gnulib, the stale generated
> header will be left over in the build tree and be picked up in
> preference to the new gnulib file.  Conversely, if a header goes from
> in-place to generated, it will no longer live in srcdir, but only in
> builddir, so it doesn't matter whether you favor builddir or srcdir.
> Therefore, it seems to me that best practice would be to always favor
> srcdir first, builddir second.

it isn't uncommon (in my experience) for this to not be as clean as it should 
be.  consider people who have older gnulib in their pkg's tree, and then they 
update their gnulib checkout (which is located elsewhere), and then run 
gnulib-tool in their pkg to update things.  if a header went from non-
generated to generated, the older version isn't cleaned out automatically.  in 
general, gnulib does not seem to be that good at cleaning up its old stuff.

iirc, i hit this exact bug sometime ago with a project and reported it as a 

Re: AM_CPPFLAGS best practice

On 02/02/2012 01:28 PM, Mike Frysinger wrote:
> On Thursday 02 February 2012 15:10:11 Eric Blake wrote:
>> Is there any specific reason that gnulib recommends builddir (generated
>> files) before srcdir?
> 
> my gut tends to prefer builddir over srcdir.  but that could be due more to 
> poorly managed packages than a "best practices" setup.  in cases where a 
> header file is shipped as part of the distribution and is *usually* used, but 
> could possibly be regenerated (and thus show up in the builddir), we'd want 
> the builddir version over the srcdir one.

My counter-response is that anything that gets generated _and shipped_
as part of the tarball should be 1) invariant (no matter how it gets
generated, the generated version won't depend on configure results), and
2) generated into srcdir, rather than builddir.  If it is generated but
depends on configure, it should _not_ be shipped, and should always live
in builddir.  Therefore, any project that generates files into builddir
but then tries to ship them as part of the tarball is broken, for the
very reason that it is now impossible to tell whether you want the
just-built one or the version-controlled one as part of your tarball.
But if the generated version always goes to srcdir, and is truly
independent of configure, then your version control system will let you
see when regenerating it changes its contents, and that should be an
infrequent occurrence.

> 
>> Consider the ramifications if a file changes
>> location.  If it goes from generated to in-place (moves from builddir to
>> srcdir, because it no longer depends on configure results), then
>> favoring builddir first means that in an incremental build where you