Improve detection and diagnosis of invalid values for conversions.
(In particular, integer conversions contain no spaces, and must always
contain at least 1 digit, '' is not valid).

Correctly handle extracting wide chars from empty strings.

Fix a (probably would have rarely been seen) bug I installed yesterday.

It turns out that mbtowc() needs to include the terminating \0 in

Correctly handle extracting wide chars from empty strings.

Fix a (probably would have rarely been seen) bug I installed yesterday.

It turns out that mbtowc() needs to include the terminating \0 in the
length arg passed to it, or it errors (EILSEQ) on a zero length (instead
of doing the sane thing and treating that the same as "\0" (treated as
being length 1). So, increase the length passed to mbtowc() by 1.
That makes no difference in the typical case, it is an upper limit on
the number of bytes to examine, and mbtowc() stops after it has
converted 1 character, so in the non "" input cases, nothing that
matters changes.

The rest of this you can skip if you like, not directly related to
this change...

Note: it is not clear to me what is correct here, POSIX looks to be
ambiguous, or strange anyway; in the RETURN VALUE section it says:

If s is not a null pointer, mbtowc() shall either return 0 (if s points
to the null byte), or return the number of bytes [...]

Further for the error possibilities it says:

[EILSEQ] An invalid character sequence is detected. In the POSIX locale
an [EILSEQ] error cannot occur since all byte values are valid
characters.

On the other hand our mbtowc(3) says:

There are special cases:

n == 0 In this case, the first n bytes of the array pointed to by
s never form a complete character. Thus, the mbtowc()
always fails.

Since EILSEQ is the only defined error for mbtowc() in POSIX, and
cannot happen (according to it) in the POSIX locale, that "always fails"
in our manual page looks dubious.

What actually happens in our mbtowc() in the POSIX locale, is that if
passed n==0 (and *s == '\0') mbtowc() returns 0 (that's good) but
also sets errno to EILSEQ (not so good - though this is not one of
the functions guaranteed to not alter errno if it doesn't fail).

In other locales it returns -1 (with errno == EILSEQ) when n == 0.
(Well, in some other locales anyway, I didn't go and test all of them).

Where POSIX gets weird, is that earlier it says:

At most n bytes of the array pointed to by s shall be examined.

If n == 0, then no bytes can be examined. In that case mbtowc()
cannot test whether s points to the null byte, even in the POSIX locale.

So it is unclear (to me) what should be returned in that case.

show more ...

Add %C format conversion and -L option to printf(1)

%C does what everyone always thought %c should do, but doesn't,
and operates rather like the %c conversion in printf(3) (to be
more precise, like

Add %C format conversion and -L option to printf(1)

%C does what everyone always thought %c should do, but doesn't,
and operates rather like the %c conversion in printf(3) (to be
more precise, like %lc). It takes a code point integer value
in the current locale's LC_CTYPE and prints the character designated.

-L (this printf's first, and only, option) makes the floating conversions
use long double instead of double.

In the manual (printf.1) document both of those, and also be more
precise as to when things are affecting bytes, and when they're
manipulating characters (which makes no difference if LC_ALL=C).

show more ...

PR bin/58534 -- printf(1) source code comment fix

Update the comment near the start of main() in printf.c so it
explains what is really happening and why, rather than being a
whole bunch of incorrec

PR bin/58534 -- printf(1) source code comment fix

Update the comment near the start of main() in printf.c so it
explains what is really happening and why, rather than being a
whole bunch of incorrect BS about what posix does or doesn't require.

This changes comments only, NFC (should be no binary change at all).

show more ...

Fix typo in comment.

Reported by Emanuele Torre in PR 58439.

fix typo

Changes for POSIX conformance.

1. exit(1) with an error message on stderr if an I/O error occurs.
1a. To work properly when built into /bin/sh sprinkle clearerr() at
appropriate places.

2. Ve

Changes for POSIX conformance.

1. exit(1) with an error message on stderr if an I/O error occurs.
1a. To work properly when built into /bin/sh sprinkle clearerr() at
appropriate places.

2. Verify that when a 'X data value is used with one of the numeric
conversions, that nothing follows the 'X'. It used to be unclear
in the standard whether this was required or not, it is clear that
with numeric conversions the entire data value must be used, or an
error must result. But with string conversions, that isn't the case
and unused parts are simply ignored. This one is a numeric conversion
with a string value, so which applies? The standard used to contain
an example of '+3 being converted, producing the same as '+ ignoring
the '3' with no mention of any error, so that's the approach we adopted,
The forthcoming version now explicitly states that an error would also
be generated from that case, as the '3' was not used by the numeric
conversion.

2a. We support those conversions with floating as well as integer conversions,
as the standard used to suggest that was required (but it makes no sense,
the values are always integers, printing them in a floating format is
dumb). The standard has been revised to make it clear that only the
integer numeric conversions %d %u %x (etc) are supposed to handle the 'X
form of data value. We still allow it with the floating formats as an
extension, for backward compat, just in case someone (other than the ATF
tests) is using it. It might go away.

2b. These formats are sypposed to convert 'X where 'X' is a character
(perhaps multibyte encoded) in the current LC_CTYPE locale category.
We don't handle that, only 1 byte characters are handled currently.
However the framework is now there to allow code to (one hopes, easily)
be added to handle multi-byte locales. (Note that for the purposes of
#2 above, 'X' must be a single character, not a single byte.)

show more ...

make value an int to avoid all the casts and conversion warnings.

Change octal and hex parsing to not use strtoul so that they don't handle
'-'. From Martijn van Duren.
Also add a warning if the conversion fails (like the gnu printf does)

Amend the previous change: we can have (almost) the best of both
worlds, as when the first arg (which should be the format) contains
no % conversions, and there are more args, the results are unspeci

Amend the previous change: we can have (almost) the best of both
worlds, as when the first arg (which should be the format) contains
no % conversions, and there are more args, the results are unspecified
(according to POSIX).

We can use this so the previous usage
printf -- format arg...
(which is stupid, and pointless, but used to work) continues to
simply ignore the -- (unspecified results mean we can do whatever
feels good...)

This brings back the #if 0'd block from the previous modification
(so there is no longer anything that needs cleaning up later) but runs
the getopt() loop it contained only when there are at least 2 args
(so any 1 arg printf always uses that arg as the format string,
whatever it contains, including just "--") and also only when the
first (format) arg contains no '%' characters (which guarantees no %
conversions without needing to actually parse the arg). This is the
(or a) "unspecified results" case from POSIX, so we are free to do
anything we like - including assuming that we might have options
(we don't) and pretending to process them.

show more ...

Stop assuming that printf handles options in any way at all
(it doesn't - that is, shouldn't) which includes processing -- as an
"end of options". The first arg is (always) the format string.

Remov

Stop assuming that printf handles options in any way at all
(it doesn't - that is, shouldn't) which includes processing -- as an
"end of options". The first arg is (always) the format string.

Remove call to getopt() (but still do associated changes to argc/argv)

Note: for now this is #if 0's out instead of being deleted, the old
code should be fully removed sometime soon.

Problem pointed out on tech-userlevel by Thierry Laronde.

show more ...

Revert previous, it was based upon a misreading of the POSIX
spec. POSIX requires "as if by calling strtod()" which we
did already ... by calling strtod(). Go back to doing that.

Always convert input numbers (from the command line) in the C
locale, not as set in the environment. Conforms with POSIX spec.

A truly ancient bug found by Edgar Fuss

When printf is running builtin in a sh, global vars aren't reset to
0 between invocations. This affects "rval" which remembers state
from a previous %b \c a

A truly ancient bug found by Edgar Fuss

When printf is running builtin in a sh, global vars aren't reset to
0 between invocations. This affects "rval" which remembers state
from a previous %b \c and thereafter always exits after the first
format conversion, until we get a conversion that generates an
error (which resets the flag almost by accident)

printf %b abc\\c
abc (no \n)
printf %s%s hello world
hello (no \n, of course, no world ...)
printf %s%s hello world
hello
printf %s%s hello world
hello
printf %d hello
printf: hello: expected numeric value
0 (no \n)
printf %s%s hello world
helloworld (no \n, and we are back!)

This affects both /bin/sh and /bin/csh (and has for a very long time).

XXX pullup -8

show more ...

Printf's that support \e for escape all seem to also support \E.
Except us. Now we do as well.

Tighten syntax a little (no more %*4.*2d nonsense).
Include the format collected so far in "missing format char" err message.
Minor KNF and whitespace.

PR standards/53563

POSIX requires that signed numbers (strings preceded by '+' or '-')
be allowed as inputs to all of the integer format conversions, including
those which treat the data as unsigned

PR standards/53563

POSIX requires that signed numbers (strings preceded by '+' or '-')
be allowed as inputs to all of the integer format conversions, including
those which treat the data as unsigned.

Hence we do not need a variant function whose only difference from its
companion is to reject strings starting with '-' - instead we use
the primary function (getintmax()) for everything and remove getuintmax().

Minor update to the man page to indicate that the arg to all of the
integer conversions (diouxX) must be an integer constant (with an
optional sign) and to make it blatantly clear that %o is octal and
%u is unsigned decimal (for some reason those weren't explicitly stated
unlike d i x and X). Delete "respectively", it is not needed (and does
not really apply).

XXX pullup -8

show more ...

NFC: More KNF (remove () around returned constants).

NFC: whitespace & KNF.

Add support for F a and A formats (which go with the eEfgG formats
already supported.)

Avoid printing error messages twice when an invalid
escape sequence (\ sequence) is present in an arg to a %b
conversion.

From leot@ on tech-userlevel:

Avoid running off into oblivion when a format string,
or arg to a %b conversion ends in an unescaped backslash.

Patch from Leo slightly modified by me.

fix some error handling.

WARNS=6

support grouping format.