reopening fprintf I18N issue

[Mark Brown]

U-

Gary Miller and some ISO folks will be at the AG meeting in Austin. We can
work this out there....I agree that I have not seen a 100% correct and clear
interpretation of this text yet.

Mark

Ulrich Drepper wrote:
> 
> 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   `------------------------

-- 
Mark S. Brown                                                   bmark@us.ibm.com
Senior Technical Staff Member                          512.838.3926  T/L678.3926
IBM RS/6000 AIX System Architecture                        Mark Brown/Austin/IBM
IBM Corporation, Austin, Texas