Re: [musl] [C23 printf 2/3] C23: implement the wN length specifiers for printf

[Rich Felker <dalias@libc.org>]

On Tue, May 30, 2023 at 01:28:33PM -0400, Rich Felker wrote:
> On Tue, May 30, 2023 at 08:46:36AM +0200, Jₑₙₛ Gustedt wrote:
> > Rich,
> > 
> > on Mon, 29 May 2023 21:48:22 -0400 you (Rich Felker <dalias@libc.org>)
> > wrote:
> > 
> > > On Mon, May 29, 2023 at 09:21:55PM +0200, Jₑₙₛ Gustedt wrote:
> > > > Rich,
> > > > 
> > > > on Mon, 29 May 2023 11:46:40 -0400 you (Rich Felker
> > > > <dalias@libc.org>) wrote:
> > > >   
> > > > > On Mon, May 29, 2023 at 09:14:13AM +0200, Jₑₙₛ Gustedt wrote:  
> > >  [...]  
> > >  [...]  
> > >  [...]  
> > > > > 
> > > > > OK I think I can communicate better with code than natural
> > > > > language text, so here's a diff, completely untested, of what I
> > > > > had in mind.  
> > > > 
> > > > that's ... ugh ... not so prety, I think
> > > > 
> > > > In my current version I track the desired width, if there is w
> > > > specifier, and then do the adjustments after the loop. That takes
> > > > indeed care of undefined character sequences.
> > > > 
> > > > I find that much better readable, and also easier to extend (later
> > > > there comes the `wf` case and the `128`, and perhaps some day
> > > > `256`)  
> > > 
> > > It sounds like the core issue is that you don't like the state machine
> > > approach to how musl's printf processes format specifiers.
> > 
> > It is well suited for simple grammars, I agree with that, but here the
> > grammar is becomming more complex. Be it just for the fact that you'd
> > have to enlargen the set of possible values to match decimal digits.
> 
> I don't think it's really any more complex. It's just a few gratuitous
> aliases that have a very small number of edge paths. The wf ones
> almost entirely collapse with the w ones, and if we wanted to get rid
> of the gratuitous separate hh/h loading, they'd entirely collapse. But
> the version I posted as code is probably enough smaller to be
> perferable. I guess I should take a look at that and see...

Ah, now I remember why we handle h/hh despite them seeing useless.
They're needed for %n, and once you distinguish them for that, there's
hardly any point in trying to treat them the same as bare elsewhere.

Rich