Date: Sat, 24 Oct 2020 19:22:07 +0000 (UTC)
From: shwaresyst <shwares...@aol.com>
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 in,
obviously no-one is going to do that, but if you consider that 0 bits
is impossible, then try 2 bits instead, same question.
But:
| No, the standard requires the internal representation to be two's
| complement for conforming applications;
Not for the internal format used by printf when converting one string
form to another string form. For that the implementation can use whatever
it likes - I have considered using bignums (like bc/dc do) to allow really
big values to be handled. 2's complement is irrelevant, printf (the utility)
does no arithmetic on the values. All it does is print them.
The rest of what you write in that paragraph is irrelevant to printf,
which is a string manipulation program in reality. What the implementation
provides for programs that manipulate integers has no bearing on printf
which (at least as specified) doesn't do that (though the implementation
might, and most likely all currently do, use a form of integer for the
internal representation - none use "int" it seems though, they all use
a wider variant of that.
That question remains unanswered, is there a range that the printf utility
is required to support, and if so, where is that specified?
| The last value to be output on error, nominally, is the one before a
| multiply by 10 or add of next digit causes the overflow, is how I'd
| construe it.
Yes, that's how I read the text, or at least that looks to be the most
likely meaning. It just isn't what anyone (except zsh - and I didn't
test it for decimal input, yet anyway) actually does. Since the standard
is supposed to be saying what the users can expect of implementations, then
it appears that the standard is wrong (given that we both read what it
currently says the same way).
| For a short %d, I'd expect "32769" to output "3276",
There's no such thing as a short in the printf utility, but if the
range of integers handled in that utility was limited to [-32786..32767]
then yes, that's how I'd read it too. But assuming that there was a
strtos() (akin to strtol() etc - but generating a short) that function
would return 32767 for any input string 32767 or bigger (and if bigger,
also set errno). If this mythical printf utility with the restricted
range was using this mythical strtos() function to convert the string
form to its internal representation, it would print 32767 in the case
you give - the printf utility never sees the 3276 value, just the input
string "32769" and the output from strtos() 32767.
This is an exact analog of what most actual printf implementations seem to
do, except using 64 bits instead of 16. The ksh93 implementation I can
kind of understand, they clearly just ignore overflow, which means they're
not using strtoll() (or similar) but probably some home-brewed conversion
function
How the solaris version that Alan Coopersmith told us about (in a message
after yours) (and thanks for that info) gets -1 as the value to print is
kind of mind boggling though. That's just weird. The gnu version Alan
also included is just the same as most of the others it seems. zsh remains
the only one that does what the standard seems to require to be done.
kre
