we can find another way to issue an #error, but using a preprocessed
assembler for that purpose and clobbering libc.a with an empty .o
just for the sake of #error reporting is way too much of a burden.
(size_t)(num * size) == 0
but both num and size are nonzero.
Reported by: Ilja van Sprundel
Approved by: jasone
Security: Integer overflow; calloc was allocating 1 byte in
response to a request for a multiple of 2^32 (or 2^64)
bytes instead of returning NULL.
The symptom is that syslog() fails to log anything but the "ident"
string if LOG_PERROR is specified to openlog(3) and the extensible
printf is in action.
For unclear, likely quaint historical reasons, syslog uses fwopen()
on a stack buffer, rather than using the more straightforward
and faster snprintf().
Along the way, fflush(3) is called, and since the callback writer
function returns zero instead of the length "written", __SERR
naturally gets set on the filedescriptor.
The extensible printf, in difference from the normal printf refuses
to output anything to an __SERR marked filedescriptor, and thus
the actual syslog message is supressed.
MFC: after 2 weeks
old resolver opened just one socket, BIND9's resolver may
open more than one sockets. And, BIND9's resolver doesn't
close the socket on timeout. So, we need this check.
Reported by: freebsd-cvs-src__at__oldach.net (Helge Oldach), bz
Hinted by: rwatson
integer. Presently, our implementation employs an approach that
converts the value to int64_t, then back to int, unfortunately,
this approach can be problematic when the the difference between
the two time_low is larger than 0x7fffffff, as the value is then
truncated to int.
To quote the test case from the original PR, the following is
true with the current implementation:
865e1a56-b9d9-11d9-ba27-0003476f2e88 < 062ac45c-b9d9-11d9-ba27-0003476f2e88
However, according to the DCE specification, the expected result
should be:
865e1a56-b9d9-11d9-ba27-0003476f2e88 > 062ac45c-b9d9-11d9-ba27-0003476f2e88
This commit adds a new intermediate variable which uses int64_t
to store the result of subtraction between the two time_low values,
which would not introduce different semantic of the MSB found in
time_low value.
PR: 83107
Submitted by: Steve Sears <sjs at acm dot org>
MFC After: 1 month
in rev. 1.34. Mainly I missed the fact that the buffer is used for two
purposes:
1) storing a group line from the group file;
2) __gr_parse_entry() parses the buffer and tries to put the group
members to the remaining part of the buffer and can fail if there
is no enough room for them.
Re-arrange the buffer size checks to account the latter case.
Submitted by: Kirk R Webb
MFC after: 2 weeks