Coming to C23 via WG14 N2630.
This one is a little interesting, because it actually changes existing
behavior. Previously "0b101" would be parsed as "0", "b", "101" by these
functions. I'm led to believe that glibc plans to actually have separate
versions of these functions for C23 and pre-C23, so callers can have the
behavior they (implicitly) specify by virtue of which -std= they compile
with. Android has never really done anything like that, and I'm pretty
sure app developers have more than enough to worry about with API levels
without having to deal with the cartesian product of API level and C
standard.
Therefore, my plan A is "if you're running on Android >= U, you get C23
behavior". My plan B in the (I think unlikely) event that that actually
causes trouble for anyone is "if you're _targeting_ Android >= U, you
get C23 behavior". I don't think we'd actually want to have two versions
of each of these functions under any circumstances --- that seems by far
the most confusing option.
Test: treehugger
Change-Id: I0bbb30315d3fabd306905ad1484361f5d8745935
libc had some -Wimplicit-fallthrough warnings. They all seem to be
benign. We're trying to enable this flag globally, so we need to
annotate these breaks here.
Bug: 112564944
Test: Builds
Change-Id: I5afae694cc4cf26ad1a61e2c8ae91f00cda7c733
Makes no difference to the benchmarks, but does make the code a bit
more readable.
Bug: http://b/68672236
Test: ran tests, benchmarks
Change-Id: I63fa5f78d077c86e4f4f194f2c76ab5510c29109
