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

[via libc-commits]

keepitupkitty 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.

Okay, for overlay mode it makes sense thus binary compatibility 

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