1f462dec34
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 |
||
|---|---|---|
| .. | ||
| img | ||
| 32-bit-abi.md | ||
| clang_fortify_anatomy.md | ||
| defines.md | ||
| EINTR.md | ||
| elf-tls.md | ||
| fdsan.md | ||
| fdtrack.md | ||
| libc_assembler.md | ||
| native_allocator.md | ||
| NOTICE | ||
| status.md | ||