Re: Buffer size checking for scanf* functions

[Yair Lenga <yair.lenga@gmail.com>]


> 
> 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,

Yair

Sent from my iPad

> On Jul 5, 2022, at 3:39 PM, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote:
> The glibc does not support hooks for scanf and I don’t think we will even
> will, the printf hooks itself has some drawbacks (MT-safeness, etc.).  Also
> scan_s and similar ‘enhanced’ functions from TR-24731 have not been widely 
> implemented mainly because they do not actually improve much. Carlos and
> Martim, both GNU developers, wrote a paper discussing the problems with
> these interfaces [1].