We regressed on this recently: code under the upstream-* directories has
_PATH_BSHELL defined as a call to __bionic_get_shell_path(). In our own
code, we may as well just call it directly.
Bug: https://issuetracker.google.com/129030706
Test: ran tests
Change-Id: Ic2423f521272be95e67f94771772fe8072636ef0
We don't need this now that popen always uses O_CLOEXEC, and it's unsafe
because _fwalk takes a lock. (In <= P, the equivalent code walked the
list without a lock in the child.)
Bug: http://b/129156634
Test: ran tests
Change-Id: Ic9cee7eb59cfc9397f370d1dc47ea3d3326179ca
I failed to convince the compiler/linker to just refrain (via factoring out,
attribute `noinline`, or meddling with `--icf=none`), but luckily I noticed
that we should have CHECK_FP in each function for a better error message,
and the distinct error messages keep the two functions apart.
(Also add a missing CHECK_FP to `clearerr_unlocked`.)
Bug: http://b/116969207
Test: manual with a modified `crasher`
Change-Id: Ic122e90e94f7e22f486be57d3dac7137a225d682
There's TLS space used for unknown errno values, and a call to printf
shouldn't clobber that. No-one will ever hit this in real life, but
since it's easily fixed...
Bug: http://b/112776560
Test: ran tests
Change-Id: I8c2437f2e5214e652119791d4e162a197b049d5b
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
POSIX says "The popen() function shall ensure that any streams from
previous popen() calls that remain open in the parent process are closed
in the new child process". It doesn't appear to disallow all popen(3) file
descriptors from being O_CLOEXEC, and it's not obvious why anyone would want
them inherited. Let's see if we can make the stricter guarantee...
Bug: N/A
Test: ran tests
Change-Id: I2c85170d730b211637afb8ba10df150ca3237262
Add two functions to allow objects that own a file descriptor to
enforce that only they can close their file descriptor.
Use them in FILE* and DIR*.
Bug: http://b/110100358
Test: bionic_unit_tests
Test: aosp/master boots without errors
Test: treehugger
Change-Id: Iecd6e8b26c62217271e0822dc3d2d7888b091a45
pclose(3) is now an alias for fclose(3). We could add a FORTIFY check
that you use pclose(3) if and only if you used popen(3), but there seems
little value to that when we can just do the right thing.
This patch also adds the missing locking to _fwalk --- we need to lock
both the global list of FILE*s and also each FILE* we touch. POSIX says
that "The popen() function shall ensure that any streams from previous
popen() calls that remain open in the parent process are closed in the
new child process", which we implement via _fwalk(fclose) in the child,
but we might want to just make *all* popen(3) file descriptors O_CLOEXEC
in all cases.
Ignore fewer errors in popen(3) failure cases.
Improve popen(3) test coverage.
Bug: http://b/72470344
Test: ran tests
Change-Id: Ic937594bf28ec88b375f7e5825b9c05f500af438
We've ignored %n for a long time, but that's dangerous too because it
makes it unclear whether the corresponding pointer argument should be
supplied or not.
Remove the ambiguity by just rejecting %n outright.
Bug: http://b/31832608
Test: ran tests
Change-Id: Ic046ad3436a30c6f8f580ea738bdcaeb01c858f8
Trivial, obvious counterpart to the standard ferror(3) and clearerr(3),
and lets us build bison out of the box.
Bug: http://b/64273806
Test: ran tests
Change-Id: I20affabddb71210051165c41e86adfe5ae04f77f
We've been using #pragma once for new internal files, but let's be more bold.
Bug: N/A
Test: builds
Change-Id: I7e2ee2730043bd884f9571cdbd8b524043030c07
Now that we have a clang that supports transparent overloads, we can
kill all of this cruft, and restore our upstream sources to their
untouched glory. Woohoo!
Bug: 12231437
Test: Built aosp_marlin; no obvious patch-related aosp_mips issues.
Change-Id: I520a19d014f12137f80e43f973dccd6711c571cd
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
Merge CT_CCL and CT_STRING handling before we add %m.
Also fix an accidental scanf/wscanf difference.
Add currently-disabled tests for questionable behavior noticed during
code review that isn't a regression, but should be fixed later.
Bug: http://b/68672236
Bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202240
Test: ran tests
Change-Id: I3eec9b7dfce84f63c68426406224822c52551d64
Strictly, POSIX says "If a '-' is in the scanlist and is not the first
wide character, nor the second where the first wide character is a '^',
nor the last wide character, the behavior is implementation-defined",
but it seems unreasonable for swscanf to interpret `a-c` differently
from sscanf. Make ours behave the same as each other by making swscanf
work the same as sscanf.
Bug: http://b/68672236
Test: ran tests
Change-Id: Ia84805897628d7128e901b468e02504373730e61
Just trivial use of macros.
The %s/%ls case in __find_arguments was backwards in the wide copy of
the code, but not problematically so because all pointers are the same
size anyway.
Bug: http://b/67371539
Test: ran tests
Change-Id: I8d34915d75ae5425c56c59510a16c328fc481d20
Android is UTF-8. Don't make everyone pay to convert UTF-8 to ASCII just
so we can recognize '%'. With UTF-8 we can just strchr forwards.
Before:
---------------------------------------------------------------
Benchmark Time CPU Iterations
---------------------------------------------------------------
BM_stdio_printf_literal 1290 ns 1290 ns 442554
BM_stdio_printf_s 1204 ns 1204 ns 582446
BM_stdio_printf_d 1206 ns 1206 ns 578311
BM_stdio_printf_1$s 2263 ns 2263 ns 310002
After:
---------------------------------------------------------------
Benchmark Time CPU Iterations
---------------------------------------------------------------
BM_stdio_printf_literal 178 ns 178 ns 3394001
BM_stdio_printf_s 246 ns 246 ns 2850284
BM_stdio_printf_d 252 ns 252 ns 2778610
BM_stdio_printf_1$s 363 ns 363 ns 1929011
Add missing __find_arguments error checking to the wide variant to match
the regular one.
Also replace various char/wchar_t differences with the macro.
Bug: http://b/67371539
Test: ran tests
Change-Id: I18f122009c22699943ab5d666a98ea594a972c40
Fix the 'j' (intmax_t/uintmax_t) length qualifier in the wide
variant. (With new tests that fail without this fix.)
Fix a typo in the wide support for intmax_t*, which isn't testable because
%n is disabled on Android (and will be removed in a later cleanup pass).
Also move the public vfprintf/vfwprint functions into stdio.cpp.
Bug: http://b/67371539
Test: ran tests
Change-Id: Ib003599b1e9cb789044a068940b59e447f2cb7cb
This patch switches to C++ (in anticipation of needing it later), removes
a little duplication (via a macro for now), and ensures uniform support
for %C/%lc and %S/%ls between regular and wide (with new tests).
Since it's so hard to debug problems in printf (as the time I've wasted
already today will testify), that's all I want to do in this change. The
other 500 lines of diff can wait...
(Also merge "floatio.h" into "local.h" now all the users are in forked
code.)
Bug: http://b/67371539
Test: ran tests
Change-Id: I083353d89c32b9302d759ca6967cc6d8a62cd8a5
Also simplify trivial one-liners like perror/puts/fputs, and clean up
fread/fwrite slightly.
Fix perror to match POSIX.
Add basic perror and *_unlocked tests.
Bug: N/A
Test: ran tests
Change-Id: I63f83c8e0c15c3c4096509d17421ac331b6fc23d
Move all the new checks over to the existing __fortify_fatal.
Bug: http://b/67455242
Test: ran tests
Change-Id: Idb899c58c32d52d3b423caf1a91feb7defcba9b3
Applications fopening files and then blindly trying to read are
widespread, leading to a recurring problem of SELinux tightening
resulting in segfaults. Add a friendly diagnostic for this case.
Bug: http://b/67455242
Test: bionic-unit-tests32/64 on sailfish
Change-Id: I1734fa94487c4eff9b55a02c6b01baf6b265d236
Implement __freading and __fwriting, and clarify the documentation that was
the cause of these not being implemented for years.
Bug: http://b/17157253
Test: ran tests
Change-Id: I89542c8131b13889e2585417a024050ecf2abcb7
We've never really used __restrict: only <string.h> and <stdio.h> (which
are still very similar to upstream BSD headers) consistently have these
annotations. Neither clang nor GCC warns for trivial cases, and there's
little obvious documentation benefit.
Bug: http://b/30833514
Test: builds
Change-Id: I3e4384281865475d0c55d764b546d8166419ee31
"Although not explicitly required by this volume of POSIX.1-2008, a good
implementation of append (a) mode would cause the O_APPEND flag to be set."
Yeah, about that...
Bug: N/A
Test: ran tests
Change-Id: I23c4bc5c1ebc92e0cb44025d2d313f321f9ffa68
