The printf specifier %n is not supported on Android's libc and will soon be removed from Fuchsia's
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Other than the clang-format issues, this looks fine. However, I'm not really knowledgable enough/the owner of the Fuschia/Android stuff, so I'd prefer an approval 'in concept' come from someone more involved with that.
Conditionally apply clang-format suggestions. It doesn't make sense to apply the suggestions in the tests because the style would diverge from the rest of the file.
+enh to review Android changes.
sorry, took me this long to log in :-(
yeah, lgtm, thanks! %n hasn't worked for about 10 years; it changed from being silently ignored (which, in retrospect, was a cure every bit as bad as the disease) to causing a FORTIFY abort in Q/API 29. but, yeah, since it doesn't do what the C standard says in any version of Android that the NDK still supports, it makes sense for clang to just reject it regardless of API level.
in case anyone's thinking "citation needed": search for %n on https://android.googlesource.com/platform/bionic/+/master/docs/status.md
and in case anyone's thinking "please don't be so lazy --- go and look up when %n was _initially_ disabled!", it was so long ago that we weren't even using git for version control back then, and the corresponding bug has gone out of retention, so i literally don't have the history left. given that, i think "forever" is a good approximation :-)
This doesn't leave much room to use __attribute__((format(printf))) on custom printf implementations that do support %n on Android does it?
+1 to this point; whether this is or is not supported depends on which libc the user is linking against.
it would be pretty hard to get into that situation though? apps are clones of the zygote, so you don't have any choice over your libc on Android: it's all bionic, all the time. (our seccomp policies also mean "good luck trying to run a static musl/glibc binary".) clang's Android target already assumes bionic in other ways --- things like whether math functions set errno, or whatever, so this seems in keeping to me.
ah, you don't mean *printf* implementations, you mean "other functions that take printf arguments"? yeah, that's a more interesting case. though that one's already broken: there's already no way to say what subset of printf formats you do/don't support. (all the ones in the Android OS itself are all subsets of the bionic printf; many equal, but several *much* smaller. that would be a pretty cool thing to be able to specify, but that's a much bigger bug, and this change brings us closer to reality than we currently are, for the 99% case :-) )