[libc-commits] [libc] [libc] Add __isoc99_fscanf alias. (PR #213125)

[Alexey Samsonov via libc-commits]

vonosmas wrote:

> > > I do not think that _just_ stubbing the function is a correct approach since isoc99_*scanf implies %a specifier which is used for string allocation to be present since it was made as a GNU extension and it was there way before POSIX's issue 7 %m modifier + it conflicts with %a specifier too.
> > > https://man7.org/linux/man-pages/man3/sscanf.3.html#NOTES
> > 
> > 
> > We do not support (and I don't think ever will support) old-style GNU variant of using `%a` for allocation. llvm-libc just treats `%a` as a floating-point specifier.
> > _However_, I noticed that we have a `TODO` to add support for `%m` as well. @michaelrj-google - do you remember if there were any blockers for it? (in either case, I don't think it should prevent this PR from merging).
> 
> If you won't be supporting gnu extensions in scanf is there reason for those aliasas? Is it binary compatibility?

Note that we only enable these aliases in "overlay" mode. In this mode the application code is compiled with system libc headers, but links in llvm-libc implementations (of course, it can only work for a subset of libc functionality, but that includes scanf and friends, where llvm-libc code can operate using system-libc definition of `FILE`).

If the code is compiled with glibc headers, then the calls to `fscanf` are `#define-`replaced with the calls to `__isoc99_fscanf`, so if we actually want application to use llvm-libc version, we should provide this symbol as well.

I suspect, musl-libc also provides these aliases, for a similar reason.

https://github.com/llvm/llvm-project/pull/213125