Re: [1003.1(2013)/Issue7+TC1 0001066]: Solution proposal to the 2038 problem.

On 2016-08-12 13:16:09 +1000, Bruce Evans wrote: > On Thu, 11 Aug 2016, Austin Group Bug Tracker wrote: > > -- > > (0003344) Vincent Lefevre (reporter) - 2016-08-11 20:41 > > http://austingroupbugs.net/v

Re: Quoting: is "${foo-'a"b'"}" valid?

On 2016-09-09 09:02:11 -0400, Chet Ramey wrote: > On 9/9/16 7:44 AM, Vincent Lefevre wrote: > > On 2016-09-05 19:12:54 +, Mark Galeck wrote: > >> The standard says in the section 2.2.3 on Double-Quotes and $ : > >> "even number of unescaped double-quotes or s

Re: SIGCHLD trap in a shell

On 2017-04-25 23:49:56 +0200, Jilles Tjoelker wrote: > On Tue, Apr 25, 2017 at 03:21:24PM +0200, Vincent Lefevre wrote: > > I wonder how the following script is supposed to behave. > > > The POSIX spec seems ambiguous about SIGCHLD trap in a shell. It says: > > "[

Re: SIGCHLD trap in a shell

On 2017-04-25 16:00:54 +0200, Joerg Schilling wrote: > Vincent Lefevre <vincent-o...@vinc17.net> wrote: > > Only bash, ksh93 and zsh document what happens concerning SIGCHLD traps. > > Do you believe every shell should document SIGCHLD? > Wouldn't it be sufficient if SIG

Re: SIGCHLD trap in a shell

On 2017-04-26 06:12:25 +0700, Robert Elz wrote: > Date:Tue, 25 Apr 2017 15:21:24 +0200 > From: Vincent Lefevre <vincent-o...@vinc17.net> > Message-ID: <20170425132124.ga7...@cventin.lip.ens-lyon.fr> > > I see Jillles has said much the same

Re: SIGCHLD trap in a shell

On 2017-04-25 21:32:56 -0400, Chet Ramey wrote: > There is no requirement that a trap be executed each time a particular > signal is generated. There is no requirement that the system keep a > count of instances of a particular pending signal; only that the signal > is pending. SIGCHLD isn't

SIGCHLD trap in a shell

I wonder how the following script is supposed to behave. The POSIX spec seems ambiguous about SIGCHLD trap in a shell. It says: "[...] a signal specified using a symbolic name, without the SIG prefix, as listed in the tables of signal names in the header defined in XBD Headers"; there, SIGCHLD

Re: SIGCHLD trap in a shell

On 2017-04-27 08:45:37 +0700, Robert Elz wrote: > ps: the seq command in your example cannot (properly) have caused the > SIGCHLD that you (think you) counted, Well, I assume that this depends on the shell. But for most shells (if not all in practice), it is the seq command that causes the

Re: SIGCHLD trap in a shell

On 2017-05-10 20:32:41 +0700, Robert Elz wrote: > Date:Wed, 10 May 2017 14:44:43 +0200 > From: Vincent Lefevre <vincent-o...@vinc17.net> > Message-ID: <20170510124443.gd25...@cventin.lip.ens-lyon.fr> > > | But wouldn't it be useful to

Re: SIGCHLD trap in a shell

On 2017-05-11 11:24:54 +0100, Geoff Clare wrote: > Vincent Lefevre <vincent-o...@vinc17.net> wrote, on 11 May 2017: > > > > > What if the shell is not executing a loop? Given > > > > > > $SHELL -c 'set -m; date ; /bin/sleep 10; date' > > > >

Re: SIGCHLD trap in a shell

On 2017-05-11 11:04:56 -0400, Chet Ramey wrote: > Sigh. The message you responded to that prompted this sub-discussion was > the one in which I asked about shell behavior when monitor mode is set in > a non-interactive shell: > > > I'm curious what you think the shell should do in this case.

Re: SIGCHLD trap in a shell

On 2017-05-10 09:56:58 -0400, Chet Ramey wrote: > On 5/10/17 8:07 AM, Vincent Lefevre wrote: > > ksh93 does (isn't this a bug?), but not zsh. With > > > > zsh -c 'while true; do date; /bin/sleep 100; done' > > > > a kill -INT on the sleep process kills onl

Re: SIGCHLD trap in a shell

On 2017-04-27 08:50:23 -0400, Chet Ramey wrote: > On 4/26/17 8:07 PM, Vincent Lefevre wrote: > > It should kill itself with SIGINT to mimic what happens in an > > interactive shell. For instance, I expect > > > > bash -c 'set -m; while true; do date; sleep 1; do

Re: SIGCHLD trap in a shell

On 2017-05-10 13:43:44 +0200, Joerg Schilling wrote: > Vincent Lefevre <vincent-o...@vinc17.net> wrote: > > > On 2017-04-27 08:45:37 +0700, Robert Elz wrote: > > > ps: the seq command in your example cannot (properly) have caused the > > > SIGCHLD that you

Re: SIGCHLD trap in a shell

On 2017-05-10 19:26:10 +0700, Robert Elz wrote: > You absolutely cannot program scripts with any expectation of > receiving CHLD traps. But wouldn't it be useful to have the list of terminated processes as a new POSIX feature for shells? Something like what you mentioned at the C level in another

ambiguous SHELL specification

In Issue 7, 2016 Edition, Section 8.3 "Other Environment Variables", page 178, line 5864: SHELL This variable shall represent a pathname of the user's preferred command language interpreter. [...] This is ambiguous, as it does not exclude a relative pathname, and doesn't say

Re: fprintf, snprintf, etc., %n and overflow on the return value

On 2017-05-22 17:10:08 -0400, shwares...@aol.com wrote: > The expected behavior is nothing gets written, since the size_t n > argument is 0. Whether *() gets written to or not is ambiguous. > The implied behavior is that since it is only checking what the > buffer length should be, by the

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

On 2017-05-24 16:15:03 +0200, Joerg Schilling wrote: > I have no idea what "posh" targets, but given that: > > posh > $ exit > posh: exit: bad number I can't reproduce this issue: cventin:~> posh $ exit cventin:~> on a Debian/unstable machine (posh 0.12.6, 14 Feb 2016, so with a version from

fprintf, snprintf, etc., %n and overflow on the return value

I'm wondering what behavior is expected for the following program on a machine with 32-bit int's and 64-bit long's: #include int main(void) { long n = -1; snprintf (NULL, 0, "%1000s%ln", "", ); printf ("%ld\n", n); return 0; } i.e. in case of overflow on the return value

Re: fprintf, snprintf, etc., %n and overflow on the return value

On 2017-05-22 19:55:22 -0400, Shware Systems wrote: > I feel strtoi, or atoi, is appropriate because when * is used the > associated argument is of type int, not any integer type or > intmax_t, limiting the string representation too if they're to have > the same range. The argument associated

Re: fprintf, snprintf, etc., %n and overflow on the return value

On 2017-05-23 10:11:35 +0700, Robert Elz wrote: > Date:Tue, 23 May 2017 02:10:23 +0200 > From: Vincent Lefevre <vincent-o...@vinc17.net> > Message-ID: <20170523001023.ga19...@zira.vinc17.org> > > | If the intent were to have "

Re: Testing if two files are on the same file system

On 2017-10-24 21:11:45 +0200, Joerg Schilling wrote: > Nick Stoughton wrote: > > > If you are correct, this is a Linux kernel bug. > > > > Why? The stat command is not standardized. The --file-system argument > > changes the output of %i to something other than the inode

cp -i behavior when the response is meaningless

One currently has for "cp": -i Write a prompt to standard error before copying to any existing non-directory destination file. If the response from the standard input is affirmative, the copy shall be attempted; otherwise, it shall not. The problem is that the response can be

Re: Testing if two files are on the same file system

On 2017-10-18 17:27:04 +0200, Joerg Wunsch wrote: > As Wheeler, David A wrote: > > > It's not just spaces. Filesystem names may contain newlines and > > other control characters, too, so "df -P" is fundamentally unsafe. > > Well, it's a question of whether your goal is to be always on the >

nm -P and output format

For "nm -P", the output format is one of: "%s%s %s %d %d\n", , , , , "%s%s %s %o %o\n", , , , , "%s%s %s %x %x\n", , , , , But what should be and for undefined symbols? Under Linux, nm from binutils prints only blanks after the type for undefined symbols, which cannot match the specified

Re: About issue 0001108 and abs(INT_MIN)

On 2018-07-23 08:06:46 +, Schwarz, Konrad wrote: > I don't think such code (to detect whether an arbitrary type is > signed or unsigned) exists. For the signness, one can just do: (T) -1 < 0 Then, to get the minimum value of a signed type, assuming two's complement and no padding bits: (2

Re: About issue 0001108 and abs(INT_MIN)

On 2018-07-23 20:04:21 +0700, Robert Elz wrote: > Date:Mon, 23 Jul 2018 14:48:36 +0200 > From: Vincent Lefevre > Message-ID: <20180723124836.ga12...@zira.vinc17.org> > > | For the signness, one can just do: (T) -1 < 0 > > Until th

Re: About issue 0001108 and abs(INT_MIN)

On 2018-07-19 16:10:35 +0200, Joerg Schilling wrote: > /* > * These macros may not work on all platforms but as we depend > * on two's complement in many places, they do not reduce portability. > * The macros below work with 2s complement and ones complement machines. > * Verify with this

Re: About issue 0001108 and abs(INT_MIN)

On 2018-07-19 16:53:11 +0200, Joerg Schilling wrote: > Vincent Lefevre wrote: > > > The problem is not just the warning. If t is signed, > > > > ((t)(~((t)0) << (sizeof (t)*CHAR_BIT - 1))) > > > > will yield undefined behavior due to overflow. This

Re: About issue 0001108 and abs(INT_MIN)

On 2018-07-19 14:41:34 +0100, Davin McCall wrote: > I agree completely but, and sorry if I'm missing something, the labs() > function could still be required to return LONG_MIN if passed LONG_MIN, > correct? It's just that the implementation changes from: > >long labs(long i) >{ >    

About issue 0001108 and abs(INT_MIN)

As expected, the text in http://austingroupbugs.net/view.php?id=1108 makes Debian's c99 utility behave incorrectly. FYI, I've reported a bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903771 -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

Re: About issue 0001108 and abs(INT_MIN)

On 2018-07-23 20:24:11 +0700, Robert Elz wrote: > Date:Mon, 23 Jul 2018 15:13:21 +0200 > From: Vincent Lefevre > Message-ID: <20180723131321.gb12...@zira.vinc17.org> > > | No, this is not impossible. The result of the test is 0. > >

Re: [1003.1(2016)/Issue7+TC2 0001108]: LONG_MIN must be <= -2147483648

On 2018-06-07 16:10:03 +, Austin Group Bug Tracker wrote: > On P567 L19829 (abs), replaceIf the result cannot be > represented, the behavior is undefined.withIf > the result cannot be represented, the result shall be > {INT_MIN}. > On P567 L19838 (abs), replaceIn two's-complement >

Re: [1003.1(2016)/Issue7+TC2 0001108]: LONG_MIN must be <= -2147483648

On 2018-07-11 21:10:16 +, Austin Group Bug Tracker wrote: > (0004050) cmsmith (reporter) - 2018-07-11 21:10 > http://austingroupbugs.net/view.php?id=1108#c4050 > -- > These changes seem to invalidate compilers for use in

initstate, etc. specification

The description of initstate, etc. is rather unclear, if not erroneous. One can read: "Values for the amount of state information are 8, 32, 64, 128, and 256 bytes." But earlier, it is said: "The random() function shall use a non-linear additive feedback random-number generator employing a

Re: [1003.1(2016)/Issue7+TC2 0001178]: atan2: Description of IEC 60559 Floating-Point option is unclear

On 2019-02-15 10:19:03 +, Austin Group Bug Tracker wrote: > New proposed resolution: > > On page 611 line 21228 section atan2(), change:[MX]If the > correct value would cause underflow, a range error may occur, and atan(), > atan2f(), and atan2l() shall return an implementation-defined value

Re: shell `var=value function`

On 2019-06-10 08:38:52 -0700, enh wrote: > but here's mksh: > > ~$ mksh > $ hello() { echo boing=$BOING; } > $ BOING=123 hello > boing=123 > $ echo $BOING > 123 > $ > > and ksh, since that seems to come up on this list: > > $ ksh > ~ [1]$ hello() { echo boing=$BOING; } > ~ [2]$ BOING=123 hello

Re: Use of "negative" in pow() ERRORS (was: [1003.1(2016/18)/Issue7+TC2 0001302]: Alignment with C17)

On 2020-11-12 10:05:16 +, Geoff Clare via austin-group-l at The Open Group wrote: > The problem is that the phrase "negative zero" is commonly used to > mean -0.0, so some people naturally assume that "negative" on its > own includes "negative zero". In the IEEE 754-2019 standard, "negative

Re: Use of "negative" in pow() ERRORS (was: [1003.1(2016/18)/Issue7+TC2 0001302]: Alignment with C17)

On 2020-11-09 09:39:25 +, Geoff Clare via austin-group-l at The Open Group wrote: > I believe this is a misuse of "negative". The RETURN VALUE section > says "For finite values of x < 0, and finite non-integer values of y, > a domain error shall occur ..." > > So the ERRORS section should

utilities and write errors

Shouldn't POSIX require that when a utility cannot write its output (e.g. due to ENOSPC or EPIPE), it shall be regarded as an error, i.e. the exit status be non zero, with a diagnostic message if possible? -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML -

Re: utilities and write errors

On 2021-07-05 13:53:45 +0700, Robert Elz via austin-group-l at The Open Group wrote: > Once again, buffering exists and is known to exist - and what's more, > the standard actually *required* stdout to be buffered whenever it is > not associated with a terminal (which is no big surprise, as

Re: utilities and write errors

On 2021-06-29 14:11:45 +0100, Stephane Chazelas via austin-group-l at The Open Group wrote: > 2021-06-29 09:49:40 +0100, Geoff Clare via austin-group-l at The Open Group: > [...] > > > If in general, then forget it - the users would lynch you (you'd probably > > > suicide first) if you

Re: What string representations of "zero" expr should consider as "zero"?

On 2021-07-02 09:31:11 +0100, Geoff Clare via austin-group-l at The Open Group wrote: > I would say the standard is unclear. To me the most reasonable > interpretation of "The expression evaluates to null or zero" is > that it evaluates to either a null string or a zero-valued integer. >

Re: What string representations of "zero" expr should consider as "zero"?

On 2021-07-02 14:30:44 +0100, Geoff Clare via austin-group-l at The Open Group wrote: > > With busybox expr (version 1.30.1), I get: > > > > $ busybox expr 0 ; echo $? > > 0 > > 1 > > $ busybox expr -0 ; echo $? > > -0 > > 0 > > $ busybox expr "" \| -0 ; echo $? > > -0 > > 0 > > $ busybox expr

Re: What string representations of "zero" expr should consider as "zero"?

On 2021-07-02 10:54:30 +, shwaresyst via austin-group-l at The Open Group wrote: > To the extent XBD 11.1, #6 applies I suppose you mean 12.1 (Utility Argument Syntax). But #6 says "Unless otherwise specified", which is the case for expr, which explicitly says when the argument is read as a

Re: utilities and write errors

On 2021-06-29 22:43:49 +0700, Robert Elz via austin-group-l at The Open Group wrote: > Date:Tue, 29 Jun 2021 09:49:40 +0100 > From:"Geoff Clare via austin-group-l at The Open Group" > > Message-ID: <20210629084940.GA8391@localhost> > > | You are wrong when you

Re: utilities and write errors

On 2021-06-29 13:30:53 -0700, L A Walsh wrote: > On 2021/06/27 14:33, tg...@mirbsd.org via austin-group-l at The Open Group > wrote: > > Don Cragun via austin-group-l at The Open Group dixit: > > > > > • When an unrecoverable error condition is > > > encountered, the utility shall exit with

Re: utilities and write errors

On 2021-06-30 00:46:00 +, mirabilos via austin-group-l at The Open Group wrote: > Using the same shorthand, I changed mksh tonight to do pretty much > what you described, in a second patch: > > @@ pseudo @@ > int > call_builtin(func_t builtinfunc, int argc, char *argv[]) > { > int

Re: utilities and write errors

On 2021-06-29 17:28:40 +0100, Stephane Chazelas via austin-group-l at The Open Group wrote: > 2021-06-29 16:28:17 +0200, Vincent Lefevre via austin-group-l at The Open > Group: > [...] > > > ( > > > sleep 1 > > > set +o errexit -o xtrace > > > p

Re: utilities and write errors

On 2021-06-29 17:28:40 +0100, Stephane Chazelas via austin-group-l at The Open Group wrote: > But utilities are meant to behave the same whether they're > builtin or not. A non-builtin pwd writting to a closed pipe > would not cause the shell to exit. Another difference between implementations

Re: utilities and write errors

On 2021-06-29 20:59:51 -0700, L A Walsh wrote: > On 2021/06/29 17:55, Vincent Lefevre wrote: > > On 2021-06-29 13:30:53 -0700, L A Walsh wrote: > > > --- > > >No. the pwd utility has had its stdout redirected by its > > > parent, "the shell". S

Re: utilities and write errors

On 2021-06-28 20:01:03 +0700, Robert Elz via austin-group-l at The Open Group wrote: > if a utility is invoked with any of stdin/out/err closed then what happens > is very explicitly unspecified in POSIX. My guess is that that is largely > because if the utility then opens a file it will be

Re: utilities and write errors

On 2021-06-28 22:02:22 +, tg...@mirbsd.org via austin-group-l at The Open Group wrote: > What’s currently left of Vincent’s issue is that the utility tries > to write to its stdout¹ which the shell has connected to something > that does not accept writes: /dev/full on systems that have it, an

Re: utilities and write errors

On 2021-06-28 21:28:37 +0700, Robert Elz wrote: > Date:Mon, 28 Jun 2021 15:48:33 +0200 > From: Vincent Lefevre > Message-ID: <20210628134833.ga46...@zira.vinc17.org> > > | So, if writing to a closed fd yields unspecified behaviour, what > |

Re: utilities and write errors

I forgot another useful case with write error checking. For instance, I expect the following command to terminate, which is not the case with ksh: ( trap '' PIPE; while pwd; do :; done; ) | head Worse, with ksh93, when I hit Ctrl-C to interrupt this command, a ksh93 process is still running,

Re: utilities and write errors

On 2021-07-07 00:48:28 +0700, Robert Elz via austin-group-l at The Open Group wrote: > | > Implementor of what? > | Of pwd. > > Who has no idea whether or not buffering is being used. When using stdio, the implementor knows that buffering *may* be used. Thus he needs to call fflush at the

Re: utilities and write errors

On 2021-07-13 22:37:55 +0700, Robert Elz via austin-group-l at The Open Group wrote: > We'll start with the EXIT STATUS section of cd: > > 82508 >0 Either the -e option or the -P option is not in effect, and an error > occurred. > 82511 >1 Both the -e and the -P options are in effect, and an

pwd and CONSEQUENCES OF ERRORS

https://austingroupbugs.net/view.php?id=1488 about pwd and CONSEQUENCES OF ERRORS considers ENOSPC only. But are there other errors that may yield a partial write? I'm thinking of EFBIG and EPIPE, in particular. -- Vincent Lefèvre - Web: 100% accessible validated

Re: Posix issue 8 pending change to system().

On 2021-10-23 22:57:09 -0500, Rob Landley via austin-group-l at The Open Group wrote: > On 10/23/21 8:39 PM, Vincent Lefevre wrote: > > On 2021-10-23 18:08:37 -0500, Rob Landley via austin-group-l at The Open > > Group wrote: > >> Testing: > >> > >&g

Behavior of "sh -c +c"

On 2021-10-30 14:33:04 +0100, Stephane Chazelas via austin-group-l at The Open Group wrote: > POSIX ended up mandating that bug (mandating that system("+c") > should run an interactive shell for instance), because, like the > the Unix libc implementors, they overlooked the issue. It is > clearly

Re: Behavior of "sh -c +c"

On 2021-11-03 16:41:40 +, Stephane Chazelas via austin-group-l at The Open Group wrote: > 2021-11-03 17:06:07 +0100, Vincent Lefevre via austin-group-l at The Open > Group: > [...] > > ksh93 and mksh run an interactive shell, but I wonder whether this > > should

Re: asctime and ctime

On 2021-10-23 08:53:06 -0700, Scott Lurndal via austin-group-l at The Open Group wrote: > On Sat, Oct 23, 2021 at 01:51:15PM +0200, Vincent Lefevre via austin-group-l > at The Open Group wrote: > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/asctime.html > >

Re: Posix issue 8 pending change to system().

On 2021-10-23 18:08:37 -0500, Rob Landley via austin-group-l at The Open Group wrote: > Testing: > > $ bash -c '-i echo hello' > bash: - : invalid option > $ dash -c '-i echo hello' > dash: 0: Illegal option - > # android > $ sh -c "-i echo hello" > sh: sh: - : unknown option > >

behavior of fgets in case of a read error

POSIX does not say anything about the contents of the array in case of a read error with fgets. ISO C17 says "the array contents are indeterminate" and N2861 says "the members of the array have unspecified values". In both cases, this is a bit unintuitive concerning s[n-1], as one may get a value

Re: utilities and write errors

On 2021-07-25 09:16:16 +0700, Robert Elz via austin-group-l at The Open Group wrote: > I say that pwd must write to standard output, but that nothing says that > that write must actually succeed - because there simply is no text that > requires that (if there were, someone would have quoted it by

sh and .profile in Issue 7

In Issue 7, there are a few references to the .profile file: * Page 2344 line 74642: Uses of files as command scripts, or for configuration or control, are exempt. For example, it is not required that sh be able to read an arbitrarily large .profile. * Page 3308 line 111414:

behavior of the QUIT character (^\) in the shell command line

What is the behavior of the QUIT character (^\) when typing a command in an interactive sh shell? https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html just says that if the shell is interactive, SIGQUIT shall be ignored. Results with various POSIX and non-POSIX shells: With bash

Re: behavior of the QUIT character (^\) in the shell command line

On 2022-12-18 08:27:31 +0700, Robert Elz wrote: > | https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html just > | says that if the shell is interactive, SIGQUIT shall be ignored. > > That just means that the shell doesn't exit with a core dump when the > signal is generated

Re: sh 'continue' shenanigans: negating

On 2024-02-15 10:54:09 +0700, Robert Elz via austin-group-l at The Open Group wrote: > I suspect you're confusing exit status and the ? special param - they're > not the same thing. Every utility, and the shell compound commands, have > an exit status. What actually appears in ? is specified,

Re: behavior of test ! = -o ! ''

On 2024-04-03 16:43:42 +0200, Vincent Lefevre wrote: > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html > says for >4 arguments with XSI: > > In addition, the string comparison binary primaries '=' and "!=" > shall have a higher prece

behavior of test ! = -o ! ''

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html says for >4 arguments with XSI: In addition, the string comparison binary primaries '=' and "!=" shall have a higher precedence than any unary primary. (note the "shall"). So, what about the following command? test ! =

Re: behavior of test ! = -o ! ''

On 2024-04-03 16:57:50 +0200, Vincent Lefevre wrote: > However, same question for > > test -e = -o ! '' > > Here, with ksh93u+m 1.0.8-1 under Debian: > > $ test -e = -o ! '' ; echo $? > > 1 > > which I think