utimensat: Make sure exit status in configure check doesn't exceed 127.

Bruno Haible writes: > 2) In the configure-time test in m4/utimensat.m4, you added > result |= 128; >However, the exit code of a program is limited to the range 0..127. >How to merge some of the bits? So far, this test fails with exit code > - 2 on AIX, >

Re: gnulib-tool.py: Don't leave temporary directories on exit.

Hi Collin, > ... It seems like a pain to track > down every code path that can lead to 'sys.exit()' or 'exit()' with a > temporary directory still existing. > ... > Therefore, we can use tempfile.TemporaryDirectory as a context manager > and le

gnulib-tool.py: Don't leave temporary directories on exit.

are pretty massive and ideally I would like to make them a bit easier to read. It seems like a pain to track down every code path that can lead to 'sys.exit()' or 'exit()' with a temporary directory still existing. With that said, GLConfig's are only created in two p

Re: reclaiming memory before exit, take 2

On Sat, 2020-05-16 at 16:04 +0200, Bruno Haible wrote: > Paul writes in [1]: > > In any event, it seems to me to be a deficiency in the detection if > > it reports allocated memory which is still referenced to by global > > variables, or even static variables, as memory leaks. > > On the contrary,

Re: reclaiming memory before exit, take 2

Jeffrey Walton wrote: > I prefer to run a release > build with diagnostics. Something like '-g2 -O3 -DNDEBUG > -fsanitize=asan', install it, and then use it long term. > > One of the [many] reasons this is important is, it provides additional > coverage beyond the test cases. In the wild I may enc

Re: reclaiming memory before exit, take 2

d just before program exit, does not constitute an important leak (it's arguably not a leak at all; it depends on one's definition of "leak"). Still-reachable memory can constitute an important leak (if your program has allocated an object that it will never actually refer to

Re: reclaiming memory before exit, take 2

ally makes sense to look for them. > However, I > don't think we always need to worry about these leaks just before program > exit, > since they are not a performance problem there and introducing 'free' there > both > complicates and slows the program. I'm n

Re: reclaiming memory before exit, take 2

On Sat, May 16, 2020 at 12:47 PM Bruno Haible wrote: > > Tim Rühsen wrote: > > At GNU wget we have conditional cleanup functions. That is compilation > > with -DDEBUG_MALLOC in $CFLAGS will add those cleanup functions and they > > are called before wget exits. Handy for testing, but you have to bu

Re: reclaiming memory before exit, take 2

ndings to eliminate? Or because we have valgrind for the memory leaks but no experience with 'valgrind --track-fds'? > Another point is: a library exit / cleanup call before exiting the > application can easily free all reachable memory and by that disguise or > hide intern

Re: reclaiming memory before exit, take 2

Tim Rühsen wrote: > At GNU wget we have conditional cleanup functions. That is compilation > with -DDEBUG_MALLOC in $CFLAGS will add those cleanup functions and they > are called before wget exits. Handy for testing, but you have to build > an extra executable. How about using an environment varia

Re: reclaiming memory before exit, take 2

your tests. So you better use coverage guided fuzzing *and* static analysis in combination. Another point is: a library exit / cleanup call before exiting the application can easily free all reachable memory and by that disguise or hide internal memory leaks that lead to OOM in a long-running

Re: reclaiming memory before exit, take 2

y superfluous, in most cases this leads to a slowdown of software, to increased energy consumption, to higher costs, and produces more CO2 than needed. So by default, applications should not free memory before exit. But I agree that people who want to test for memory leaks (and most develop

Re: reclaiming memory before exit, take 2

generally makes sense to look for them. However, I don't think we always need to worry about these leaks just before program exit, since they are not a performance problem there and introducing 'free' there both complicates and slows the program. This underlying issue dates b

Re: reclaiming memory before exit, take 2

us > memory leaks (like they also want to silence "gcc -Wall" warnings when > they are pointless). > > I can see three good and one bad ways of doing so: > > * [good] Enhance the suppressions file(s). > > * [good] In unit tests, add free() statements right bef

reclaiming memory before exit, take 2

us memory leaks (like they also want to silence "gcc -Wall" warnings when they are pointless). I can see three good and one bad ways of doing so: * [good] Enhance the suppressions file(s). * [good] In unit tests, add free() statements right before exit(). Like Paul said in [2]: &quo

Re: reclaiming memory before exit

many times on GNU make, which uses a lot of allocated memory which is referred to by global variables and is not freed at exit, and I don't recall seeing these reported as leaks. I will have to run again and refresh my memory as it's been some months since I tried it last. In any eve

Re: reclaiming memory before exit

Jeffrey Walton wrote: > Allow me to rephrase again as if I am speaking to executives: GNU > should embrace a diversity of leadership. This topic is off-topic on this list. Please don't discuss it here. First, read [1]. Then, you can discuss it privately with Richard Stallman and the members of the

Re: reclaiming memory before exit

On Fri, May 15, 2020 at 6:07 PM Paul Smith wrote: > > On Fri, 2020-05-15 at 16:38 -0400, Jeffrey Walton wrote: > > On Fri, May 15, 2020 at 4:23 PM Paul Eggert > > > To fix this problem you need to fix GNU itself. They need new blood > > in leadership that understands and embraces modern engineeri

Re: reclaiming memory before exit

t > > complicate a program merely to avoid their false alarms. For example, > > if memory is used until just before a process exits, don’t free it > > simply to silence such a tool. > > Are people are reading more into it than it says, and interpreting this > as "GN

Re: reclaiming memory before exit

On Fri, 2020-05-15 at 21:58 +0200, Bruno Haible wrote: > Another possibility is to standardize on a GCC attribute for > functions, with the meaning "memory allocations done inside this > functions are on the same level as static initializations and don't > need to be reclaim

Re: reclaiming memory before exit

tdown to take, literally, minutes and cause significant load on the system. Simply invoking _exit(), on the other hand, takes a fraction of that time with little extra load. In a highly-available system that difference is absolutely crucial. Final free is one legitimate way to manage memory at

Re: reclaiming memory before exit

On Fri, May 15, 2020 at 4:23 PM Paul Eggert wrote: > > On 5/15/20 10:52 AM, Kamil Dudka wrote: > ... > > I do not understand why you take it personally. > > I didn't take it personally. The email in question wasn't even directed at > me. I > do value civility, though. There was nothing uncivil o

Re: reclaiming memory before exit

requirements may have been justified by the inadequacies of software tools at the time, by today's standards they were just make-work, and improving the inadequate tools was a better solution. For GNU apps, requiring 'free' before program exit is a similar sort of make-work requirement -

Re: reclaiming memory before exit

On Fri, May 15, 2020 at 3:58 PM Bruno Haible wrote: > > Kamil Dudka wrote: > > How old is the text in GNU standards that Bruno refers to? > > How old it is, is irrelevant because the two main points are valid and will > continue to be valid (if the tools don't change): > > 1) The sentence "if me

Re: reclaiming memory before exit

don’t free it simply to silence such a tool" [1] is valid as long as GNU targets not an embedded OS for a hardware without MMU, but an operation system that frees all resources of a process when the process exits. A call to 'free (ptr);' right before exit() is a b

Re: reclaiming memory before exit

On Friday, May 15, 2020 5:16:28 AM CEST Paul Eggert wrote: > On 5/14/20 5:11 PM, Jeffrey Walton wrote: > > Not everyone has GNU's low standards. > > Now may be a good time to remind us of the GNU Kind Communications > Guideline; see . > Let's

Re: reclaiming memory before exit

Jeffrey, > > We discussed this already in the thread starting at [1]. > > Not everyone has GNU's low standards. You are one of the few persons who apply analysis and checking tools to many GNU projects, more than anyone else [2][3]. This is appreciated (as long as the reports are about platforms

Re: reclaiming memory before exit

On Thu, May 14, 2020 at 11:16 PM Paul Eggert wrote: > > On 5/14/20 5:11 PM, Jeffrey Walton wrote: > > Not everyone has GNU's low standards. > > Now may be a good time to remind us of the GNU Kind Communications Guideline; > see . Let's not le

Re: reclaiming memory before exit

On 5/14/20 5:11 PM, Jeffrey Walton wrote: > Not everyone has GNU's low standards. Now may be a good time to remind us of the GNU Kind Communications Guideline; see . Let's not let honest technical disagreements degenerate into name-calling.

Re: reclaiming memory before exit

On Thu, May 14, 2020 at 8:00 PM Bruno Haible wrote: > > Jeffrey Walton wrote: > > > Building RPMs with -Dlint would mean performance > > > penalty because some programs (e.g. sort) would explicitly release complex > > > data structures just before exit, which is

Re: reclaiming memory before exit

Jeffrey Walton wrote: > > Building RPMs with -Dlint would mean performance > > penalty because some programs (e.g. sort) would explicitly release complex > > data structures just before exit, which is wasteful. > > I think it may be a bit presumptuous to call cleanup waste

Re: fstrcmp: memory is not reclaimed on exit

Hi Bruno, > Le 16 févr. 2020 à 13:52, Bruno Haible a écrit : > > Hi Akim, > > Sorry for the delay. You look busy :) >> +void >> +fstrcmp_free (void) >> +{ >> + gl_once (keys_init_once, keys_init); >> + gl_tls_key_destroy (buffer_key); >> + gl_tls_key_destroy (bufmax_key); >> +} > > This

Re: fstrcmp: memory is not reclaimed on exit

Paul Eggert wrote: > it's merely choosing a point in a design space that involves simplicity, > efficiency, correctness, testability, etc. and where there are several > reasonable choices. Right. In the case of fstrcmp, the bison tests use 'valgrind -q'. Akim could use 'valgrind -q --leak-check=

Re: fstrcmp: memory is not reclaimed on exit

On 2/16/20 12:44 PM, Jeffrey Walton wrote: The coding standard is wrong in this area. The practice breaks testing. Not really. It breaks some tests, which are arguably testing the wrong thing. Any tests that check for whether all memory is freed just before exit, are testing for a property

Re: fstrcmp: memory is not reclaimed on exit

On Sun, Feb 16, 2020 at 7:53 AM Bruno Haible wrote: > > ... > > I agree, I would like to be able to explicitly release the memory. But > > I can't see any API to do that in fstrcmp.c. Is this one ok? > > The GNU Coding Standards [1] tell us to not worry about this situation. > However, > the al

Re: fstrcmp: memory is not reclaimed on exit

you run fstrcmp in the main thread? Most likely valgrind does its > >inventory in the main thread, during exit(). This means that at this > > point > >the fstrcmp buffer for the main thread still exists. In other words, you > >should treat thread-local m

Re: fstrcmp: memory is not reclaimed on exit

Hi all, > Le 22 janv. 2020 à 07:50, Akim Demaille a écrit : > > I agree, I would like to be able to explicitly release the memory. But > I can't see any API to do that in fstrcmp.c. Is this one ok? I feel > stupid to initialize the memory right before releasing, but I didn't > find a means to

Re: fstrcmp: memory is not reclaimed on exit

re it stands, that it does it as the latest possible instant. > In particular: > - Did you create threads, in which fstrcmp is run? If yes, are they still >running? No, Bison does not use any threads. > - Or did you run fstrcmp in the main thread? Most likely valgrind does its

Re: fstrcmp: memory is not reclaimed on exit

w what to do. Is this a red herring related to Valgrind > as a platform? Do the threads still exist at the moment valgrind does its inventory of left- over memory? In particular: - Did you create threads, in which fstrcmp is run? If yes, are they still running? - Or did you run fstrcm

fstrcmp: memory is not reclaimed on exit

Hi! There was a recent bug report about Bison not reclaiming all its memory on exit (https://lists.gnu.org/r/bug-bison/2020-01/msg6.html). This is a not a leak, the memory is still reachable, yet we try to stay clean on exit. The traces from Valgrind are: > 10. input.at:331: testing Sym

Re: [PATCH] gnu-web-doc-update: exit immediately when CVSROOT environment is missing

On 26/10/15 21:54, Sami Kerola wrote: > * build-aux/gnu-web-doc-update: Check the environment variable CVSROOT early > on to avoid needing to build a project before getting "cvs add: No CVSROOT > specified! Please use the `-d' option" error. > --- > build-aux/gnu-web-doc-update | 3 +++ > 1 file

[PATCH] gnu-web-doc-update: exit immediately when CVSROOT environment is missing

* build-aux/gnu-web-doc-update: Check the environment variable CVSROOT early on to avoid needing to build a project before getting "cvs add: No CVSROOT specified! Please use the `-d' option" error. --- build-aux/gnu-web-doc-update | 3 +++ 1 file changed, 3 insertions(+) diff --git a/build-aux/g

[PATCH] tests: provide returns_() to simplify exit status checking

* tests/init.sh (returns_): A new function for use in tests, to allow for easier checking of return values, where you expect a command to exit with failure status. By checking for a particular exit code, you don't hide any crashes for example. --- ChangeLog | 8 tests/init.sh

[PATCH] bootstrap: exit immediately upon gnulib-tool failure

* build-aux/bootstrap: Exit immediately if gnulib-tool fails. This was noticed when gnulib-tool exited early due to failure to apply a patch in coreutils at http://hydra.nixos.org/eval/1172233, but various confusing errors were then given as the build proceeded. --- build-aux/bootstrap | 3 ++- 1

openat: don't exit program if save_cwd fails

not changed, so there's no need to do something as drastic as exit the program. Here's a proposed patch. It also fixes some more-obscure issues in functions like linkat. I suppose I could pull them out as a separate patch but I'm not sure it's worth the trouble. openat:

Re: [PATCH] maint.mk: forbid exit(-1)

Eric Blake wrote: > Libvirt accidentally had an 'exit (-1)' which got by the syntax > checker; generally, exiting with 255 is not a wise idea. > > * top/maint.mk (sc_prohibit_magic_number_exit): Detect negatives. ... > diff --git a/top/maint.mk b/top/maint.mk > i

[PATCH] maint.mk: forbid exit(-1)

Libvirt accidentally had an 'exit (-1)' which got by the syntax checker; generally, exiting with 255 is not a wise idea. * top/maint.mk (sc_prohibit_magic_number_exit): Detect negatives. Signed-off-by: Eric Blake --- ChangeLog|5 + top/maint.mk |5 +++-- 2 files

Re: getopt-gnu: fix exit code overflow

Hi Eric, > waitpid() distinguishes between normal exits > 128 and a > signal exit, and all existing shells are good about only reporting core > dumps or other signal exits when waitpid() says the child exits via > signal. It's just the ambiguity that results when dealing with

Re: getopt-gnu: fix exit code overflow

On 06/19/2012 04:11 AM, Bruno Haible wrote: > Exit codes are limited to be < 128. Values between 128 and 255 are reported > as core dumps by the invoking shell. Not true. waitpid() distinguishes between normal exits > 128 and a signal exit, and all existing shells are good about on

getopt-gnu: fix exit code overflow

Exit codes are limited to be < 128. Values between 128 and 255 are reported as core dumps by the invoking shell. To avoid such misinterpretations, this fix. The problem was introduced on 2011-07-07. 2012-06-19 Bruno Haible getopt-gnu: Fix exit code overflow in autoconf t

[PATCH] bootstrap: don't exit 0 upon gnulib-tool failure

: *** Stop. but they scrolled by as configure and make ran. Oops. Here's the fix: >From de009b65198c00dbe0ecd796ce75d5d9f5346103 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sat, 11 Feb 2012 10:57:28 +0100 Subject: [PATCH] bootstrap: don't exit 0 upon gnulib-tool failure * build-aux/

Re: copy_file_preserving variant that doesn't exit on error?

On 12 January 2012 15:40, Bruno Haible wrote: > Hi Reuben, > >> so where's the test with /dev/null? > > You didn't submit a test with /dev/null. If it makes sense to have one, > please submit one. Ah, I think I tried to make one, but it didn't make sense, because I was trying to make a file that

Re: copy_file_preserving variant that doesn't exit on error?

Hi Reuben, > so where's the test with /dev/null? You didn't submit a test with /dev/null. If it makes sense to have one, please submit one. Bruno

Re: copy_file_preserving variant that doesn't exit on error?

On 12 January 2012 13:26, Bruno Haible wrote: > Hi Reuben, > > Reuben Thomas wrote: >> I find no tests for specific return codes from qcopy_file_preserving (grep >> GL_COPY gives no hits in gnulib/tests/), and I can find no test >> involving /dev/null (all instances I can find are redirections, no

Re: copy_file_preserving variant that doesn't exit on error?

Hi Reuben, Reuben Thomas wrote: > I find no tests for specific return codes from qcopy_file_preserving (grep > GL_COPY gives no hits in gnulib/tests/), and I can find no test > involving /dev/null (all instances I can find are redirections, not > parameters to a test). Yes, I added a test for whe

Re: copy_file_preserving variant that doesn't exit on error?

On 12 January 2012 12:55, Jim Meyering wrote: > Reuben Thomas wrote: > >> On 12 January 2012 02:13, Bruno Haible wrote: >>> >>> - In copy-file.h declare the right function name. >> >> Ah yes, I must've missed warnings for this, sorry. >> >>> - In the tests I also had to drop the test with /dev/fu

Re: copy_file_preserving variant that doesn't exit on error?

Reuben Thomas wrote: > On 12 January 2012 02:13, Bruno Haible wrote: >> >> - In copy-file.h declare the right function name. > > Ah yes, I must've missed warnings for this, sorry. > >> - In the tests I also had to drop the test with /dev/full, since - unlike >>  /dev/null - this device does not e

Re: copy_file_preserving variant that doesn't exit on error?

On 12 January 2012 02:13, Bruno Haible wrote: > > - In copy-file.h declare the right function name. Ah yes, I must've missed warnings for this, sorry. > - In the tests I also had to drop the test with /dev/full, since - unlike >  /dev/null - this device does not exist everywhere. Ex.: on OpenBSD

Re: copy_file_preserving variant that doesn't exit on error?

Reuben Thomas wrote: > > errno describes _what_ error occurred. The error message also contains > > information about _when_ it occurred. > > Actually, the error codes returned by qcopy_file_preserving contain > all the information about when the error occurred, as you can see in > copy_file_prese

Re: copy_file_preserving variant that doesn't exit on error?

as --- tests/test-copy-file-1.sh.orig Thu Jan 12 03:00:15 2012 +++ tests/test-copy-file-1.sh Thu Jan 12 02:15:02 2012 @@ -10,4 +10,11 @@ fi export TMPDIR -exec "${srcdir}/test-copy-file.sh" +"${srcdir}/test-copy-file.sh" +ret1=$? +NO_STDERR_OUTPUT=1 "${srcdir}/test-

Re: copy_file_preserving variant that doesn't exit on error?

On 11 January 2012 01:32, Bruno Haible wrote: > > errno describes _what_ error occurred. The error message also contains > information about _when_ it occurred. Actually, the error codes returned by qcopy_file_preserving contain all the information about when the error occurred, as you can see in

Re: copy_file_preserving variant that doesn't exit on error?

Hi Reuben, > >> Is there no way to deal with error messages normally, i.e. via > >> gnulib's strerror? Then the error-returning copy_file_preserving could > >> replace the aborting version, and users who want to could check the > >> return code and issue errors in the usual way. > > > > This would

Re: copy_file_preserving variant that doesn't exit on error?

""), src_filename); +{ + err = GL_COPY_ERR_AFTER_READ; + goto error; +} #endif /* Preserve the access and modification times. */ @@ -123,15 +146,66 @@ copy_file_preserving (const char *src_filename, const char *dest_filename) /* Preserve the access permissions.

Re: copy_file_preserving variant that doesn't exit on error?

Hi Reuben, Thanks for working on this refactoring. Reuben Thomas wrote: > Here's a revised version of my patch. A couple of comments. Yes I heard that it's not so much fun to hear picky comments, but quality... - The function _copy_file_preserving is not declared nor used outside that file. H

Re: copy_file_preserving variant that doesn't exit on error?

ror; +} #endif /* Preserve the access and modification times. */ @@ -123,15 +146,73 @@ copy_file_preserving (const char *src_filename, const char *dest_filename) /* Preserve the access permissions. */ #if USE_ACL if (copy_acl (src_filename, src_fd, dest_filename, dest_fd, mode)) -exit

Re: copy_file_preserving variant that doesn't exit on error?

On 10 January 2012 09:16, Jim Meyering wrote: > A couple of suggestions: Thanks for the review. >  ERR_READ may be too generic, risking collision with symbols defined by >  other applications.  Perhaps names like GL_COPY_READ_FAILURE, >  GL_ACL_PRESERVE_FAILURE, etc. I now have GL_COPY_ERR_*. I

Re: copy_file_preserving variant that doesn't exit on error?

; + >> +    case ERR_OPEN_BACKUP_WRITE: >> +      error (EXIT_FAILURE, errno, _("cannot open backup file \"%s\" >> for writing"), >> +             dest_filename); >> + >> +    case ERR_READ: >> +      error (EXIT_FAILURE, errno, _("error reading \"%s\""), src_filename); >> + >> +    case ERR_WRITE: >> +      error (EXIT_FAILURE, errno, _("error writing \"%s\""), dest_filename); >> + >> +    case ERR_AFTER_READ: >> +      error (EXIT_FAILURE, errno, _("error after reading \"%s\""), >> src_filename); >> + >> +    case ERR_ACL: >> +      exit (EXIT_FAILURE); >> + >> +    default: >> +      exit (EXIT_FAILURE); >> +    }

Re: copy_file_preserving variant that doesn't exit on error?

; > +      goto error_src; > +    } >   if (close (src_fd) < 0) > -    error (EXIT_FAILURE, errno, _("error after reading \"%s\""), > src_filename); > +    { > +      err = ERR_AFTER_READ; > +      goto error; > +    } >  #endif > >   /* Preserve

[PATCH] test-getcwd: disambiguate exit status

test-getcwd: disambiguate exit status * tests/test-getcwd.c (test_long_name): Return 0..7. (main): Exit with an unambiguous exit status. The old code yielded a mysterious mixture of two failure codes. diff --git a/tests/test-getcwd.c b/tests/test-getcwd.c index e9832f0..359aedb 100644 --- a/tests

Re: copy_file_preserving variant that doesn't exit on error?

(const char *src_filename, const char *dest_filename) /* Preserve the access permissions. */ #if USE_ACL if (copy_acl (src_filename, src_fd, dest_filename, dest_fd, mode)) -exit (EXIT_FAILURE); +{ + err = ERR_ACL; + goto error_src_dest; +} #else chmod (dest_f

Re: copy_file_preserving variant that doesn't exit on error?

On 2 August 2011 09:21, Jim Meyering wrote: > > Ideally, copy_file_preserving would retain it semantics > and it would simply call your new function (containing the > guts of this one), obtain an indication of which part (if any) > failed, and then diagnose and exit. > >

Re: copy_file_preserving variant that doesn't exit on error?

Reuben Thomas wrote: > By the way, I note that the return value of chown is ignored where no > other return value is; is this an oversight, or is it really the case > that this is the one operation whose failure can be overlooked? I think the rationalization is that depending on the type of the d

Re: copy_file_preserving variant that doesn't exit on error?

st to move this along a bit, I attach a patch which changes > copy_file_preserving to return error codes instead of calling error. Hi Reuben, Thanks for pursuing this. It would indeed be useful to have code with equivalent functionality that does not exit upon failure. However, that "equival

Re: copy_file_preserving variant that doesn't exit on error?

By the way, I note that the return value of chown is ignored where no other return value is; is this an oversight, or is it really the case that this is the one operation whose failure can be overlooked?

Re: copy_file_preserving variant that doesn't exit on error?

+26,7 @@ extern "C" { Modification times, owner, group and access permissions are preserved as far as possible. Exit upon failure. */ -extern void copy_file_preserving (const char *src_filename, const char *dest_filename); +extern int copy_file_preserving (const char *src_filena

copy_file_preserving variant that doesn't exit on error?

I just came across the copy-file module, which does exactly what I want (it is even geared to making backup files), but (unfortunately for use in an interactive program) exits on error. I was just wondering what the rationale for this is, rather than returning an error code. Even in a non-interact

(make-vector 100000000000 nil) shouldn't force a quick exit

Currently, when the user allocates a too-large vector, e.g., (make-vector 1000 nil), the malloc failure causes Emacs to go into "I'm about to die!" mode, because it assumes that memory is so low that the user should simply exit as soon as possible. But there's typica

Re: remove 'exit'?

On Sun, May 1, 2011 at 8:47 PM, Simon Josefsson wrote: > How about just removing the module?  If something breaks, the maintainer > can track it down, and will notice that the module disappeared, and fix > the package.  If nothing breaks, it is normally just a portability > problem that will be no

[PATCH 1/3] atexit-tests: ensure reliable exit status

This was the only remaining init.sh client that didn't properly use the 'Exit' function. * tests/test-atexit.sh: Prefer 'Exit' over 'exit'. Reported by Bruno Haible. Signed-off-by: Eric Blake --- > Shouldn't this patch also be applied to tests/test

Re: remove 'exit'?

ch is the important aspect. >> >> I have removed the module now. > > Except that you forgot to remove 'exit' from the Dependencies: section > of other modules. I'm doing that now. Thank you! That shouldn't have been there since it was deprecated, I think

[PATCH] exit: drop remaining clients

Anyone using EXIT_FAILURE needs to depend on stdlib, now that the exit module is gone. * modules/argmatch (Depends-on): Replace exit with stdlib. * modules/copy-file (Depends-on): Likewise. * modules/execute (Depends-on): Likewise. * modules/exitfail (Depends-on): Likewise. * modules/obstack

Re: remove 'exit'?

s an error regardless of warning. > > Alas, I don't think it becomes an error even if we remove it -- I recall > that gnulib-tool just prints another warning for unknown modules. But > it shouldn't do any harm, which is the important aspect. > > I have removed the modul

Re: remove 'exit'?

k...@freefriends.org (Karl Berry) writes: > FWIW, I also agree with just removing the module instead of trying to > ever-escalate warnings. My experience is that few people are likely to > deal with it until it becomes an error regardless of warning. Alas, I don't think it becomes an error even

Re: remove 'exit'?

FWIW, I also agree with just removing the module instead of trying to ever-escalate warnings. My experience is that few people are likely to deal with it until it becomes an error regardless of warning. I would agree even more with keeping the module as an "alias" for stdlib so as to avoid this s

Re: remove 'exit'?

Simon Josefsson wrote: > How about just removing the module?  If something breaks, the maintainer > can track it down, and will notice that the module disappeared, and fix > the package. OK. I won't object any more. Feel free to remove the module. Bruno -- In memoriam Itzhak Katzenelson

Re: remove 'exit'?

Hello Simon, * Simon Josefsson wrote on Sun, May 01, 2011 at 09:47:06PM CEST: > Bruno Haible writes: > > 'gettextize' requires the user to press Enter to acknowledge the output. And > > it has annoyed a lot of people. Some distros patch out this part of > > gettextize. > > In summary, people don

Re: remove 'exit'?

Hello, * Bruno Haible wrote on Sun, May 01, 2011 at 09:38:43PM CEST: > > Should we just play more with boldface output? This sounds like an arms race again. Whenever that happens, it is usually most helpful in the long to consider removing output, or producing some of the other output more judi

Re: remove 'exit'?

Bruno Haible writes: > Hi Simon, > >> It is easy to miss the message -- gnulib-tool's output is quite verbose. >> Would it help if the user had to press enter to continue? That could be >> a problem for automated builds, but someone is bound to notice the >> problem eventually in that case thoug

Re: remove 'exit'?

Hi Simon, > It is easy to miss the message -- gnulib-tool's output is quite verbose. > Would it help if the user had to press enter to continue? That could be > a problem for automated builds, but someone is bound to notice the > problem eventually in that case though. 'gettextize' requires the

Re: remove 'exit'?

Bruno Haible writes: > Simon Josefsson wrote: >> I noticed this warning in one of my projects (gsasl): >> >> Notice from module exit: >> This module is obsolete. It will be removed on 2011-01-01. Use 'stdlib'. >> >> Time to remove the modu

Re: remove 'exit'?

Simon Josefsson wrote: > I noticed this warning in one of my projects (gsasl): > > Notice from module exit: > This module is obsolete. It will be removed on 2011-01-01. Use 'stdlib'. > > Time to remove the module? Well, if you were still using this module, that i

remove 'exit'?

I noticed this warning in one of my projects (gsasl): Notice from module exit: This module is obsolete. It will be removed on 2011-01-01. Use 'stdlib'. Time to remove the module? /Simon

[PATCH] init.sh: ensure a more reliable exit status when exiting via trap

I've fixed the trap code in init.sh. Thanks, Dmitry. >From 092a81622804491f13fb73f4df610db0db45b35a Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 28 Apr 2010 09:51:15 +0200 Subject: [PATCH] init.sh: ensure a more reliable exit status when exiting via trap * tests/init.sh

Re: [PATCH] Fix exit status of signal handlers in shell scripts

:" in the build output would find nothing. > > > > Yes, and it should be this way, IMO. Each time a user sees a "FAIL:", he > > should be encouraged to investigate. > > > > Whereas in the gettext test suite, often when I sent SIGINTs, I saw some > > tests f

Re: relax licenses for both exitfail and exit

Simon Josefsson wrote: ... > Thanks -- I've pushed the modified patch. Now the only license issue > within gnulib is 'euidaccess'... glibc-derived, so I've adjusted it: >From 032088a1c918358d4832c9ea524a757ea2739f8d Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sat, 6 Mar 2010 11:46:04 +010

Re: relax licenses for both exitfail and exit

Jim Meyering writes: > I wrote: >> I'll see if Paul agrees. > > He does: > > > Yes, it's OK to relax the licenses for both exit and exitfail. Thanks -- I've pushed the modified patch. Now the only license issue within gnulib is 'euidaccess'... /Simon

relax licenses for both exitfail and exit

I wrote: > I'll see if Paul agrees. He does: > Yes, it's OK to relax the licenses for both exit and exitfail.

Re: exit

Bruno Haible writes: > Hi Simon, > > Both are good suggestions. > >> Bruno, do you mind re-licensing the 'exit' module to >> LGPLv2+? > > Fine with me. Please go ahead. > >> And add the above obsolete warning? > > Also fine with me. At

Re: exit

Hi Simon, Both are good suggestions. > Bruno, do you mind re-licensing the 'exit' module to > LGPLv2+? Fine with me. Please go ahead. > And add the above obsolete warning? Also fine with me. At the same time, in doc/posix-functions/exit.texi, it's appropriate to cha

Re: exit

Simon Josefsson writes: > Eric Blake writes: > >> According to Simon Josefsson on 3/4/2010 6:33 AM: >>> Building all modules leads to this warning: >>> >>> gnulib-tool: warning: module obstack depends on a module with an >>> incompatible license

  1   2   >