Re: Buffer size checking for scanf* functions

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

> On 5 Jul 2022, at 18:50, Yair Lenga <yair.lenga@gmail.com> wrote:
> 
> 
>> 
>> Adhemerval,
> 
> Thanks for taking time to review my posting.
> 
> I agree 100% with the critic on annex K. I believe there is (almost) universal agreement that it was half baked solution, rushed into the standard without proper review - which is why it got very little traction.
> 
> However, the fact the the annex K has many flaws does not mean that there are no good ideas in it. In particular, the ability to create “safer” vararg lists for atomic types, and use them in scanf* and similar, is significant improvement (IHMO). I believe it improve safety, while keeping code clean, readable, and can be used for many use cases (e.g., my scanf from a result set, parsing csv-like data, …).
> 
> Also worth mentioning that one mentioned alternative (OBS - object size checking) can fit into the proposed scanf change, given it ability to identify object sizes for static/dynamic char *.
> 
> Hoping to get feedback on my proposal for this limited use case.
> 
> Also, regarding the proposal for using stringifying macros, etc. Those are interesting ideas, but will break code clarity/readability . They Will not fit nicely into large scale projects, given their limitation (e.g. with dynamic size strings, etc.)
> 
> Thanks again for your time/ideas/feedback,

The main issue of extending standard interfaces with non standard 
functionality is the burden of keeping compatibility over releases.  
The scanf family itself requires glibc to provide multiple symbols
to handle C99, originally on glibc ‘a’ was synonymous of ‘m’ and 
the C standard defines ‘a’ to being synonymous of ‘f’.

It means that for -std=c99 glibc does a symbol redirection to a
different one to handle this difference.  If we add another non
standard extension it might require extra additional handling in
the future if C or POSIX reassign the conversion modifier to
something else.

We can follow the scanf_s idea and handle c, s, and [ conversion
as a pair or argument.  This will need also another symbol
redirection (since this interface is not compatible with standard
scanf family) and to export multiple new symbols.

I don’t have a a strong opinion, but if the idea is to add such 
extensions I think it would require some more discussion to avoid 
the scanf_s mistakes and maybe add some useful extension like to
handle non standard types supported by GCC (like int128 and
float128).

It also has the drawback to be an ad-hoc solution that will be
eventually phase out if standard ended up provide simila
functionality

I really think using current standard %m is really a much better 
approach than trying to extending scanf to use fixed sizes buffers.
It does dynamic allocation, but since your idea is to use dynamic
size strings anyway it might fit.