Re: printf (the utility) expected range of integer values

2020-10-26 Thread Robert Elz via austin-group-l at The Open Group
Date:Mon, 26 Oct 2020 15:02:26 +0100 From:Joerg Schilling Message-ID: <5f96d6f2.jkFuBT5X4/F/wqwv%joerg.schill...@fokus.fraunhofer.de> | If the code you are using is from FreeBSD (Garret Damore) Where it originated I don't know for sure, but it has been in the

Re: printf (the utility) expected range of integer values

2020-10-26 Thread Joerg Schilling via austin-group-l at The Open Group
Robert Elz wrote: > Date:Mon, 26 Oct 2020 15:02:26 +0100 > From:Joerg Schilling > Message-ID: > <5f96d6f2.jkFuBT5X4/F/wqwv%joerg.schill...@fokus.fraunhofer.de> > > | If the code you are using is from FreeBSD (Garret Damore) > > Where it originated I don't know

Re: printf (the utility) expected range of integer values

2020-10-26 Thread Robert Elz via austin-group-l at The Open Group
Date:Mon, 26 Oct 2020 19:18:10 +0100 From:Joerg Schilling Message-ID: <5f9712e2.+zlga0iaqihkovkz%joerg.schill...@fokus.fraunhofer.de> | There is a simple rule of thumb: If you like to use %n$ for localization, | use a matching number of arguments and % units with

Re: printf (the utility) expected range of integer values

2020-10-26 Thread Joerg Schilling via austin-group-l at The Open Group
Robert Elz via austin-group-l at The Open Group wrote: > I should have included dash and yash in that list - their error messages > are very similar to what /usr/bin/printf on NetBSD prints (and the NetBSD sh, > which uses the same source code for its builtin printf), but when I looked >

Re: printf (the utility) expected range of integer values

2020-10-26 Thread Geoff Clare via austin-group-l at The Open Group
Robert Elz wrote, on 24 Oct 2020: > > Is there somewhere, anywhere, where it is possible to infer what > range of values printf (the utility, not the C library function) > is expected to handle? > > I can find nothing in the XCU 3.printf page, nor in XBD 5 (and also > not in XBD 12, which would

Re: printf (the utility) expected range of integer values

2020-10-24 Thread Robert Elz via austin-group-l at The Open Group
Date:Sat, 24 Oct 2020 19:22:07 + (UTC) From:shwaresyst Message-ID: <1984361807.3011984.1603567327...@mail.yahoo.com> | Could an implementor represent integers as an internal | form with 0 bits You're concentrating on a reductio-ad-absurdum comment I threw

Re: printf (the utility) expected range of integer values

2020-10-24 Thread shwaresyst via austin-group-l at The Open Group
Could an implementor represent integers as an internal form with 0 bits (in which the only value that doesn't overflow is 0) and hence always print 0 for any %d (%u/%x/%d) conversion, with an error message about overflow for any value with any bits set? No, the standard requires the internal

Re: printf (the utility) expected range of integer values

2020-10-24 Thread Alan Coopersmith via austin-group-l at The Open Group
On 10/24/20 11:05 AM, Robert Elz via austin-group-l at The Open Group wrote: It might be useful to know what the printf utility (the one from the filesystem) outputs for /path/to/printf '%d\n' 0xc000 on Solaris, AIX, HPUX, Linux, MacOS, and anything else similar anyone can

Re: printf (the utility) expected range of integer values

2020-10-24 Thread Robert Elz via austin-group-l at The Open Group
A couple of messages back I wrote: | But it is obvious that at least the NetBSD sh, bash, bosh, zsh, | and ksh93 have a builtin printf (the error messages differ...) I should have included dash and yash in that list - their error messages are very similar to what /usr/bin/printf on NetBSD

Re: printf (the utility) expected range of integer values

2020-10-24 Thread Robert Elz via austin-group-l at The Open Group
Date:Sat, 24 Oct 2020 16:47:41 + (UTC) From:shwaresyst Message-ID: <160402159.2963847.1603558061...@mail.yahoo.com> | The text relevant to all this I see is the paragraph at line 104150, page 3= | 114, c181.pdf, That is the text I quoted in the previous

RE: printf (the utility) expected range of integer values

2020-10-24 Thread shwaresyst via austin-group-l at The Open Group
The text relevant to all this I see is the paragraph at line 104150, page 3114, c181.pdf, which limits outputs to the internal representation range of the format characters used, converted back to text. This should probably be explicit that the conversion shall detect overflows, positive or