Re: bug#48113: Module suggestion: timeout

severity 48113 wishlist retitle 48113 Self-test timeout functionality thanks Karl Berry writes: > What do bug-automake people think? > > For myself, I have no objection to sprinkling timeout commands through > the Automake test infrastructure wherever appropriate. It's not ever > going to ri

Re: bug#48113: Module suggestion: timeout

What do bug-automake people think? For myself, I have no objection to sprinkling timeout commands through the Automake test infrastructure wherever appropriate. It's not ever going to rise to the top of my own list of things to do, though, so if it's going to happen, you or someone will have t

Re: Module suggestion: timeout

Adding timeout to all build operations automatically is probably too much and too intrusive. But in any case, it should be easy to add such a timeout to certain build operations (e.g. downloading, running a compiler for which the halting problem cannot be solved, testing a production binary, ...).

Re: Module suggestion: timeout

Marc Nieper-Wißkirchen writes: > Moreover, use cases for a baked-in timeout are not restricted to tests. For > example, I may want to restrict the build time of certain components in > situations where a logical error may lead to infinite build times (a simple > example is that of a Scheme compil

Re: Module suggestion: timeout

Dear Bruno, dear Simon, thank you for your replies. I understand that valgrind-tests and the proposed "timeout-tests" solution are not completely equivalent. Nevertheless, I still think that some timeout functionality provided by Gnulib would be useful. Bruno's solution ** #if HAVE_DECL_ALARM

Re: Module suggestion: timeout

Bruno Haible writes: > So, I don't think the "let's treat timeout like valgrind" approach is going > to work. Instead, you need to design a way to deal with timeouts, > independently. Hi! I think Marc's request for functionality to introduce timeouts for self-tests is a good one. However I re

Re: Module suggestion: timeout

Hi Marc, Marc Nieper-Wißkirchen wrote: > Gnulib contains a module named valgrind More precisely, it's called 'valgrind-tests'. See https://www.gnu.org/software/gnulib/manual/html_node/Using-valgrind-automatically.html > that allows the easy use of > Valgrind for tests whenever it is supported by

Module suggestion

Gnulib contains a module named valgrind that allows the easy use of Valgrind for tests whenever it is supported by the build system. I would suggest to add a similar module named timeout that sets the variable TIMEOUT with suitable defaults whenever the GNU coreutils timeout program (or an equival

Re: Module suggestion: Atomic operations

Marc Nieper-Wißkirchen wrote in : > C11 has introduced atomic types and atomic operations. When they are not > available, one can use locks/mutexes instead. > > It would be nice if there was a Gnulib module that abstracts over t

Re: Module suggestion: Atomic operations

Hi Marc, > At least one type in is guaranteed to be > lock-free, the atomic flag. Since C18, it can be used in signal > handlers, where Posix locks won't work because they are not > async-safe. Moreover, provides memory fences, which I > don't know how to emulate in general and which also seem t

Re: Module suggestion: Atomic operations

Hi Bruno, Am Mo., 25. Mai 2020 um 09:24 Uhr schrieb Bruno Haible : > Pools have the drawback that they add a configuration requirement on the > application: What is the default size of the pool? When to increase the > pool size? By how much? When to shrink the pool? The developer would have > det

Re: Module suggestion: Atomic operations

Hi Marc, > One problem with as given is that atomic values have no > destructors. Thus, we cannot simply attach locks to them in a pre-C11 > implementation because there is no place to destroy the locks. Ah... > Thus, we would have to work with a pool of locks shared by all atomic > variables.

Re: Module suggestion: Atomic operations

Hi Bruno, Am So., 24. Mai 2020 um 22:54 Uhr schrieb Bruno Haible : > Yes, given that the platform support for these atomic types/operations is > increasing, it would accelerate the adoption if there was a Gnulib module, > like you describe it. Program developers could then adopt > without losing

Re: Module suggestion: Atomic operations

Hi Marc, > C11 has introduced atomic types and atomic operations. When they are not > available, one can use locks/mutexes instead. > > It would be nice if there was a Gnulib module that abstracts over this, > much like the threadlib module and friends abstract over a specific > threading implem

Module suggestion: Atomic operations

C11 has introduced atomic types and atomic operations. When they are not available, one can use locks/mutexes instead. It would be nice if there was a Gnulib module that abstracts over this, much like the threadlib module and friends abstract over a specific threading implementation. What I am t

Re: new module suggestion: fprintftime-check

* Bruno Haible: > Florian Weimer wrote: >> The standards do not provide a way to report errors for malformed format >> strings. I think the current behavior is acceptable, all things >> considered. > > OK, then I'm fine with Assaf's approach to create a new, separate function > that does only the

Re: new module suggestion: fprintftime-check

Florian Weimer wrote: > The standards do not provide a way to report errors for malformed format > strings. I think the current behavior is acceptable, all things > considered. OK, then I'm fine with Assaf's approach to create a new, separate function that does only the syntax checking. Bruno

Re: new module suggestion: fprintftime-check

* Bruno Haible: > [CCing Florian Weimer. > Florian, the thread started at > https://lists.gnu.org/archive/html/bug-gnulib/2018-12/msg00149.html ] > > Assaf Gordon wrote: >> The comment even says: >>/* Unknown format; output the format, including the '%', >> since this is most lik

Re: new module suggestion: fprintftime-check

Ben Pfaff wrote: On Sat, Dec 29, 2018 at 09:22:17AM -0800, Paul Eggert wrote: (Using ptrdiff_t is part of my campaign to prefer ptrdiff_t to size_t. While we're at it, let's change the other size_t args to ptrdiff_t, but I digress) Have you said anything about this campaign elsewhere? I'd

Re: new module suggestion: fprintftime-check

On Sat, Dec 29, 2018 at 09:22:17AM -0800, Paul Eggert wrote: > (Using ptrdiff_t is part of my campaign to prefer ptrdiff_t to size_t. While > we're at it, let's change the other size_t args to ptrdiff_t, but I > digress) Have you said anything about this campaign elsewhere? I'd like to hear m

Re: new module suggestion: fprintftime-check

I suspect that changing this behavior would be a disruptive backwards-incompatible change (but other opinions are welcomed). I wouldn't mind a change as long as it changes the API enough so that compilers complain if we don't also update the calling code. For example, nstrftime could take an a

Re: new module suggestion: fprintftime-check

On 2018-12-28 11:08 p.m., Bruno Haible wrote: [CCing Florian Weimer. Florian, the thread started at https://lists.gnu.org/archive/html/bug-gnulib/2018-12/msg00149.html ] Assaf Gordon wrote: The comment even says: /* Unknown format; output the format, including the '%', since

Re: new module suggestion: fprintftime-check

[CCing Florian Weimer. Florian, the thread started at https://lists.gnu.org/archive/html/bug-gnulib/2018-12/msg00149.html ] Assaf Gordon wrote: > The comment even says: >/* Unknown format; output the format, including the '%', > since this is most likely the right thing to do if

Re: new module suggestion: fprintftime-check

Hello Bruno, On 2018-12-28 9:34 a.m., Bruno Haible wrote: This function enables syntax-check of the format string. First question: Should this syntax-check be integrated into the nstrftime() and fprintftime() functions? These functions are gnulib inventions, therefore they could be extended to

Re: new module suggestion: fprintftime-check

Hi Assaf, > This function enables syntax-check of the format string. First question: Should this syntax-check be integrated into the nstrftime() and fprintftime() functions? These functions are gnulib inventions, therefore they could be extended to return - an error indicator (maybe EINVAL?),

new module suggestion: fprintftime-check

Hello, I'd like to suggest the following new module: fprintftime-check. It uses the same infrastructure as fprintftime (i.e. #include "nstrtime,c") to implement a new function: int fprintftime_check (const char *format, const char** err_ptr); This function enables syntax-check of the format s

Re: module suggestion: realpath

Sam Steingold <[EMAIL PROTECTED]> writes: > Bruno Haible wrote: >> Linux manpage: >> >> BUGS >>Avoid using this function. It is broken by design since it >>is impossible to determine a suitable size for the output >>buffer, resolved_path. According to POSIX a

Re: module suggestion: realpath

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruno Haible wrote: > Sam Steingold wrote: >> CLISP comes with a replacement realpath implementation for platforms >> which lacks it (are there still such platforms?). > > If someone provides a correct implementation of realpath for gnulib, we will >

Re: module suggestion: realpath

Sam Steingold wrote: > > There is an alternative modules 'canonicalize-lgpl'; it has fewer > > dependencies. > > how is it functionally different? > if it is not, why two versions? It is functionally the same. The 'canonicalize' module also has a mode CAN_ALL_BUT_LAST that correspondings to clisp

Re: module suggestion: realpath

> * Bruno Haible <[EMAIL PROTECTED]> [2007-10-28 05:43:54 +0200]: > > Sam Steingold wrote: >> > But it's better to use canonicalize_file_name() >> >> it comes with a huge dependecy set... > > There is an alternative modules 'canonicalize-lgpl'; it has fewer > dependencies. how is it functionally

Re: module suggestion: realpath

Sam Steingold wrote: > > But it's better to use canonicalize_file_name() > > it comes with a huge dependecy set... There is an alternative modules 'canonicalize-lgpl'; it has fewer dependencies. Bruno

Re: module suggestion: realpath

> * Bruno Haible <[EMAIL PROTECTED]> [2007-10-27 00:25:01 +0200]: > > Sam Steingold wrote: >> CLISP comes with a replacement realpath implementation for platforms >> which lacks it (are there still such platforms?). > > If someone provides a correct implementation of realpath for gnulib, > we will

Re: module suggestion: realpath

Sam Steingold wrote: > CLISP comes with a replacement realpath implementation for platforms > which lacks it (are there still such platforms?). If someone provides a correct implementation of realpath for gnulib, we will accept it. But it's better to use canonicalize_file_name(), because - real

Re: module suggestion: realpath

On 10/26/07, Ben Pfaff <[EMAIL PROTECTED]> wrote: > > ... realpath implementation for platforms > > which lacks it (are there still such platforms?). > > gnulib has an implementation of canonicalize_file_name. Is that > sufficient? 1. Normally, long names don't bother me too much. Nevertheless

Re: module suggestion: realpath

Sam Steingold <[EMAIL PROTECTED]> writes: > CLISP comes with a replacement realpath implementation for platforms > which lacks it (are there still such platforms?). gnulib has an implementation of canonicalize_file_name. Is that sufficient? -- "Unix... is not so much a product as it is a pains

module suggestion: realpath

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CLISP comes with a replacement realpath implementation for platforms which lacks it (are there still such platforms?). I think gnulib is a good home for the code (or, rather, CLISP is not). Sam. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/