Re: reopening fprintf I18N issue

[Ulrich Drepper <drepper at redhat dot com>]

Sorrya for the late reply, I'm still catching up.

> This is an incorrect interpretation. The printf() class of functions
> is always _byte_based_; a char is a byte in ISO C. Note that there
> is no "l" (ell) qualifier present (SUSv2), thus the argument to %s
> is to be a pointer to an array of char (ISO C) -- this is because it
> is going to be treated as bytes. Note the "if precision....that many
> bytes are written" sentence.

I believe you that this is what current implementations do because it
is what one expects from a non-locale-aware implementation.

> As to what is going on in the test results, let me add something:
> 
> [FAIL] printf([%-6.1s],??????) 
>     sys[[<SPC><SPC><SPC><SPC><SPC><SPC>]] != exp[[<SPC><SPC><SPC><SPC><SPC>]]
>                                                   ^
>                                                    There should be an
>                                                    undisplayable single byte
>                                                    here if you look at the
>                                                    actual output!

There is none in the files I got and this is good so.  The problem is
that if this byte would be there the entire output is unusable.  I
just changed the code to implement it the way you suggest it and now I
cannot even use iconv anymore.  I cannot imagine that this is what
people want to use.

This leaves in my opinion only two ways out:

- just like the test output I have, the byte is simply omitted.  This
  has the big drawback that now the output precision is not honored in
  some case and string concatenation etc might fail because junk
  characters are included in the string.

- do it the way I've implemented it.  It always provides a usable output.


I do not really know what to do.  Writing out garbage bytes seems much
worse than diverging from the behavior of other implementations.


> > [FAIL] printf([%-6.3s],??????) 
> >     sys[[?<SPC><SPC><SPC><SPC>]] != exp[[?<SPC><SPC><SPC>]]
>                                             ^
>                                             a single byte here as well.

Neither here is this byte present.  I guess your Japanese guys are
agreeing with me that this additional byte is bad.

> Now, onward to the swprintf() issue. Gary thinks the spec here is horribly
> muddled, and that both the test and glibc are doing the wrong thing. We are
> going to submit an aardvark to Austin Group on this. For what it is worth,
> glibc is closer the Gary's expected behavior.

I've got meanwhile some comments from the original author of the amd1
specs.  His intentions were a bit different from what I had
implemented and this is I've changed now.  I think my implementation
is now in line what ISO C99 is intended to be.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------