the existing file descriptor. Instead, let dup2() atomically close the
old file descriptor when assigning the newly opened file to the same
descriptor. This closes a race in a multithreaded application where a
concurrent open() could allocate the existing file descriptor in between
the calls to close() and dup2().
PR: threads/79887
Submitted by: Dmitrij Tejblum tejblum of yandex-team.ru
Reviewed by: davidxu
MFC after: 1 week
bottom of the manpages and order them consistently.
GNU groff doesn't care about the ordering, and doesn't even mention
CAVEATS and SECURITY CONSIDERATIONS as common sections and where to put
them.
Found by: mdocml lint run
Reviewed by: ru
by *sprintf(), etc.
- Explicitly initialize _fl_mutex to PTHREAD_MUTEX_INITIALIZER for all FILE
objects. This is currently a nop on FreeBSD, but is import for other
platforms (or in the future) where PTHREAD_MUTEX_INITIALIZER is not simply
zero.
PR: threads/141198
Reported by: Jeremy Huddleston @ Apple
MFC after: 2 weeks
Prior to this commit, fread/fwrite calls with size * nmemb > SIZE_MAX
were handled by reading or writing (size_t)(size * nmemb) bytes; for
example, on 32-bit platforms, fread(ptr, 641, 6700417, f) would read 1
byte and indicate that the requested 6700417 blocks had been read.
This commit adds a check for such integer overflows, and treats them as
if an overly large request was passed to read/write; i.e., it sets errno
to EINVAL, sets the error indicator on the file, and returns a short
object count (0, to be specific).
The overflow check involves an integer division, so as a performance
optimization we check first to see if both size and nmemb are less than
2^16; if they are, no overflow is possible and we avoid the division.
We assume here that size_t is at least 32 bits; this appears to be true
on all platforms FreeBSD supports.
Although this commit fixes an integer overflow, it is not likely to have
any security implications, since any program which would be affected by
this bug fix is quite clearly already very confused.
Reviewed by: kib
MFC after: 1 month
and moving the default initialization of prec into the else clause.
The clang static analyzer erroneously thought that nsec can be used
uninitialized here; it was not actually possible, but better to make
the code clearer. (Clang can't know that sprintf() won't modify *pi
behind the scenes.)
uninitialized. Initialize it to a safe value so that there's no
chance of returning an error if stack garbage happens to be equal to
(size_t)-1 or (size_t)-2.
Found by: Clang static analyzer
MFC after: 7 days
- Tolerate applications that pass a NULL pointer for the buffer and
claim that the capacity of the buffer is nonzero.
- If an application passes in a non-NULL buffer pointer and claims the
buffer has zero capacity, we should free (well, realloc) it
anyway. It could have been obtained from malloc(0), so failing to
free it would be a small memory leak.
MFC After: 2 weeks
Reported by: naddy
PR: ports/138320
Right now nmemb is returned when size is 0. In newer versions of the
standards, it is explicitly required that fwrite() should return 0.
Submitted by: Christoph Mallon
Approved by: re (kib)
because it means getdelim() returns -1 for both error and EOF, and
never returns 0. However, this is what the original GNU implementation
does, and POSIX inherited the bug.
Reported by: marcus@
dprintf() is a simple wrapper around another function, so we may as
well implement it. But also like getline(), we can't prototype it by
default right now because it would break too many ports.
wcscasecmp(), and wcsncasecmp().
- Make some previously non-standard extensions visible
if POSIX_VISIBLE >= 200809.
- Use restrict qualifiers in stpcpy().
- Declare off_t and size_t in stdio.h.
- Bump __FreeBSD_version in case the new symbols (particularly
getline()) cause issues with ports.
Reviewed by: standards@
The integer thousands' separator code is rewritten in order to
avoid having to preallocate a buffer for the largest possible
digit string with the most possible instances of the longest
possible multibyte thousands' separator. The new version inserts
thousands' separators for integers using the same code as floating point.
sets up a fake buffered FILE and then effectively calls itself
recursively. Unfortunately, gcc doesn't know how to do tail call
elimination in this case, and actually makes things worse by
inlining __sbprintf(). This means that f[w]printf() to stderr was
allocating about 5k of stack on 64-bit platforms, much of which was
never used.
I've reorganized things to eliminate the waste. In addition to saving
some stack space, this improves performance in my tests by anywhere
from 5% to 17% (depending on the test) when -fstack-protector is
enabled. I found no statistically significant performance difference
when stack protection is turned off. (The tests redirected stderr to
/dev/null.)
to get rid of restrict qualifier discarding. This lets libc compile
cleanly in gnu99 mode.
Suggested by: kib, christoph.mallon at gmx.de
Approved by: kib (mentor)
slightly less evil inline functions, and move the buffering state into
a struct. This will make it possible for helper routines to produce
output for printf() directly, making it possible to untangle the code
somewhat.
In wprintf(), use the same buffering mechanism to reduce diffs to
printf(). This has the side-effect of causing wprintf() to catch write
errors that it previously ignored.
