| Age | Commit message (Collapse) | Author | Lines |
|---|
|
the difference of pointers is a signed type ptrdiff_t; if it is only
32-bit, left-shifting it by 30 bits produces undefined behavior. cast
the difference to an appropriate unsigned type, uint32_t, before
shifting to avoid this.
the a64l function is specified to return a signed 32-bit result in
type long. as noted in the bug report by Ed Schouten, converting
implicitly from uint32_t only produces the desired result when long is
a 32-bit type. since the computation has to be done in unsigned
arithmetic to avoid overflow, simply cast the result to int32_t.
further, POSIX leaves the behavior on invalid input unspecified but
not undefined, so we should not take the difference between the
potentially-null result of strchr and the base pointer without first
checking the result. the simplest behavior is just returning the
partial conversion already performed in this case, so do that.
|
|
the num_submatches field of some ast nodes was not initialized in
tre_add_tag_{left,right}, but was accessed later.
this was a benign bug since the uninitialized values were never used
(these values are created during tre_add_tags and copied around during
tre_expand_ast where they are also used in computations, but nothing
in the final tnfa depends on them).
|
|
|
|
previously if you called getprotobyname("egp") you would get
NULL because \008 is invalid octal and so the protocol id was
interpreted as 0 and name as "8egp".
|
|
commit 7e816a6487932cbb3cb71d94b609e50e81f4e5bf (version 1.1.11
release cycle) moved the code that performs wchar_t to multibyte
conversion across code that used the resulting length in bytes,
thereby breaking the unget buffer space check in ungetwc and
clobbering up to three bytes below the start of the buffer.
for allocated FILEs (all read-enabled FILEs except stdin), the
underflow clobbers at most the FILE-specific locale pointer. no stores
are performed through this pointer, but subsequent loads may result in
a crash or mismatching encoding rule (UTF-8 multibyte vs byte-based).
for stdin, the buffer lies in .bss and the underflow may clobber
another object. in practice, for libc.so the adjacent object seems to
be stderr's buffer, which is completely unused, but this could vary
with linking options, or when static linking.
applications which do not attempt to use more than one character of
ungetwc pushback, or which do not use ungetwc, are not affected.
|
|
per the powerpc psabi, offset 4 of the stack at call time belongs to
the callee and is used for spilling lr (return address). in addition,
offset 0 on the stack must contain a pointer to the previous stack
frame, or a null pointer for the initial stack frame of a thread.
__clone failed to setup any stack frame on the new thread's stack,
thereby allowing the start function it called to clobber offset 4 of
the new thread's struct __pthread, which contains the dtv pointer.
add code to setup a proper stack frame and align the stack pointer to
a multiple of 16 (also an abi requirement) if it was not already
aligned.
|
|
The variable nss is set to zero in following line.
|
|
based on patch submitted by Jaydeep Patil, with minor changes.
|
|
the two/three/four byte memmem specializations are not prepared to
handle haystacks shorter than the needle; they unconditionally read at
least up to the needle length and subtract from the haystack length.
if the haystack is shorter, the remaining haystack length underflows
and produces an unbounded search which will eventually either crash or
find a spurious match.
the top-level memmem function attempted to avoid this case already by
checking for haystack shorter than needle, but it failed to re-check
after using memchr to remove the maximal prefix not containing the
first byte of the needle.
|
|
the comparison f->wpos > f->buf has undefined behavior when f->wpos is
a null pointer, despite the intuition (and actual compiler behavior,
for all known compilers) being that NULL > ptr is false for all valid
pointers ptr.
the purpose of the comparison is to determine if the write buffer is
non-empty, and the idiom used elsewhere for that is comparison against
f->wbase, which is either a null pointer when not writing, or equal to
f->buf when writing. in the former case, both f->wpos and f->wbase are
null; in the latter they are both non-null and point into the same
array.
|
|
|
|
the idiom fprintf(f, "%.*s", n, "") was wrongly used in vfwprintf as a
means of producing n spaces; instead it produces no output. the
correct form is fprintf(f, "%*s", n, ""), using width instead of
precision, since for %s the later is a maximum rather than a minimum.
|
|
Some PowerPC CPUs (e.g. Freescale MPC85xx) have a completely different
instruction set for floating point operations (SPE).
Executing regular PowerPC floating point instructions results in
"Illegal instruction" errors.
Make it possible to run these devices in soft-float mode.
|
|
This is the minimal fix for __putenv leaving a pointer to freed heap
storage in __env_map array, which could later on lead to errors such
as double-free.
|
|
patch by Mahesh Bodapati and Jaydeep Patil of Imagination
Technologies.
|
|
this change is made in preparation for adding the mips64 port, which
needs a 64-bit (and mips64-specific) form of the R_INFO macro, but
it's a better abstraction anyway.
based on part of the mips64 port patch by Mahesh Bodapati and Jaydeep
Patil of Imagination Technologies.
|
|
expf(-NAN) was treated as expf(-large) which unconditionally
returns +0, so special case +-NAN.
reported by Petr Hosek.
|
|
This brings the call to an actually usable speed.
Quick unscientific benchmark: 14ns : 102ns :: vDSO : syscall
|
|
This is a GNU extension, but a fairly minor one, for a system call that
otherwise has no libc wrapper.
|
|
This is a workaround to treat * as literal * at the start of a BRE.
Ideally ^ would be treated as an anchor at the start of any BRE
subexpression and similarly $ would be an anchor at the end of any
subexpression. This is not required by the standard and hard to do
with the current code, but it's the existing practice. If it is
changed, * should be treated as literal after such anchor as well.
|
|
commit 7eaa76fc2e7993582989d3838b1ac32dd8abac09 made * invalid at
the start of a BRE subexpression, but it should be accepted as
literal * there according to the standard.
This patch does not fix subexpressions starting with ^*.
|
|
|
|
name_from_hosts failed to account for the possibility of an address
family error from name_from_numeric, wrongly counting such a return as
success and using the uninitialized address data as part of the
results passed up to the caller.
non-matching address family entries cannot simply be ignored or
results would be inconsistent with respect to whether AF_UNSPEC or a
specific address family is queried. instead, record that a
non-matching entry was seen, and fail the lookup with EAI_NONAME of no
matching-family entries are found.
|
|
No current ports do this, but it will be useful for porting to 64-bit ll/sc
architectures, such as mips64 and powerpc64.
|
|
commit e4355bd6bec89688e8c739cd7b4c76e675643dca moved the math asm
from external source files to inline asm, but unfortunately, all
current releases of clang use the wrong inline asm constraint codes
for float and double ("w" and "P" instead of "t" and "w",
respectively). this patch adds detection for the bug in configure,
and, for now, just disables the affected asm on broken clang versions.
|
|
in order to take advantage of the fpu in -mfloat-abi=softfp mode, the
__VFP_FP__ (presence of vfp fpu) was checked instead of checking for
__ARM_PCS_VFP (hardfloat EABI variant). however, the latter macro is
the one that's actually specified by the ABI documents rather than
being compiler-specific, and should also be checked in case __VFP_FP__
is not defined on some compilers or some configurations.
|
|
the reference implementation clamps rounds to [1000,999999999]. we
further limited rounds to at most 9999999 as a defense against extreme
run times, but wrongly clamped instead of treating out-of-bounds
values as an error, thereby producing implementation-specific hash
results. fixing this should not break anything since values of rounds
this high are not useful anyway.
|
|
like fputs (see commit 10a17dfbad2c267d885817abc9c7589fc7ff630b), the
message printing code for getopt assumed that fwrite only returns 0 on
failure, but it can also happen on success if the total length to be
written is zero. programs with zero-length argv[0] were affected.
commit 500c6886c654fd45e4926990fee2c61d816be197 introduced this
problem in getopt by fixing the fwrite behavior to conform to the
requirements of ISO C. previously the wrong expectations of the getopt
code were met by the fwrite implementation.
|
|
internally, the idiom of passing nmemb=1 to fwrite and interpreting
the return value of fwrite (which is necessarily 0 or 1) as
failure/success is fairly widely used. this is not correct, however,
when the size argument is unknown and may be zero, since C requires
fwrite to return 0 in that special case. previously fwrite always
returned nmemb on success, but this was changed for conformance with
ISO C by commit 500c6886c654fd45e4926990fee2c61d816be197.
|
|
when the size argument was zero but nmemb was nonzero, these functions
were returning nmemb, despite no data having been written.
conceptually this is not wrong, but the standard requires a return
value of zero in this case.
|
|
as specified, the int argument providing the character to write is
converted to type unsigned char. for the actual write to buffer,
conversion happened implicitly via the assignment operator; however,
the logic to check whether the argument was a newline used the
original int value. thus usage such as putchar('\n'+0x100) failed to
produce a flush.
|
|
when a write error occurred while flushing output due to a newline,
fwrite falsely reported all bytes up to and including the newline as
successfully written. in general, due to buffering such "spurious
success" returns are acceptable for stdio; however for line-buffered
mode it was subtly wrong. errors were still visible via ferror() or as
a short-write return if there was more data past the newline that
should have been written, but since the contract for line-buffered
mode is that everything up through the newline be written out
immediately, a discrepency was observable in the actual file contents.
|
|
the workaround was for a bug that botched .gpword references to local
labels, applying a nonsensical random offset of -0x4000 to them.
this reverses commit 5e396fb996a80b035d0f6ecf7fed50f68aa3ebb7 and a
removes a similar hack that was added to syscall_cp.s in the later
commit 756c8af8589265e99e454fe3adcda1d0bc5e1963. it turns out one
additional instance of the same idiom, the GETFUNCSYM macro in
arch/mips/reloc.h, was still affected by the assembler bug and does
not admit an easy workaround without making assumptions about how the
macro is used. the previous workarounds made static linking work but
left the early-stage dynamic linker broken and thus had limited
usefulness.
instead, affected users (using binutils versions older than 2.20) will
need to fix the bug on the binutils side; the trivial patch is commit
453f5985b13e35161984bf1bf657bbab11515aa4 in the binutils-gdb
repository.
|
|
the old __cp_cancel code path loaded the address of __cancel from the
GOT using the $gp register, which happened to be set to point to the
correct GOT by the calling C function, but there is no ABI requirement
that this happen. instead, go the roundabout way and compute the
address of __cancel via pc-relative and gp-relative addressing
starting with a fake return address generated by a bal instruction,
which is the same trick crt1 uses to bootstrap.
|
|
not only is pthread_kill expensive in this case; it also breaks
testing under qemu app-level emulation.
|
|
the linux man page specifies malloc_usable_size(0) to return 0 and
this is the semantics other implementations follow (jemalloc).
reported by Alexander Monakov.
|
|
10k elements stack is increased to 1000k, otherwise tnfa creation fails
for reasonable sized patterns: a single literal char can add 7 elements
to this stack, so regcomp of an 1500 char long pattern (with only litral
chars) fails with REG_ESPACE. (the new limit allows about < 150k chars,
this arbitrary limit allows most command line regex usage.)
ideally there would be no upper bound: regcomp dynamically reallocates
this buffer, every reallocation checks for allocation failure and at
the end this stack is freed so there is no reason for special bound.
however that may have unwanted effect on regcomp and regexec runtime
so this is a conservative change.
|
|
GDB is looking for a pointer to the ldso debug info in the data of the
..rld_map section.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
|
|
These are undefined escape sequences by the standard, but often
used in sed scripts.
|
|
The goto logic was hard to follow and modify. This is
in preparation for the BRE \+ and \? support.
|
|
The standard does not define semantics for \| in BRE, but some code
depends on it meaning alternation. Empty alternative expression is
allowed to be consistent with ERE.
Based on a patch by Rob Landley.
|
|
Previously repetitions were accepted after empty expressions like
in (*|?)|{2}, but in BRE the handling of * and \{\} were not
consistent: they were accepted as literals in some cases and
repetitions in others.
It is better to treat repetitions after an empty expression as an
error (this is allowed by the standard, and glibc mostly does the
same). This is hard to do consistently with the current logic so
the new rule is:
Reject repetitions after empty expressions, except after assertions
^*, $? and empty groups ()+ and never treat them as literals.
Empty alternation (|a) is undefined by the standard, but it can be
useful so that should be accepted.
|
|
This should not change the meaning of the code, just make the intent
clearer: advancing position is tied to adding a new literal.
|
|
this file's .data section was not aligned, and just happened to get
the correct alignment with past builds. it's likely that the move of
atomic.s from arch/arm/src to src/thread/arm caused the change in
alignment, which broke the atomic and thread-pointer access fragments
on actual armv5 hardware.
|
|
|
|
|
|
search is only performed if the search or domain keyword is used in
resolv.conf and the queried name has fewer than ndots dots. there is
no default domain and names with >=ndots dots are never subjected to
search; failure in the root scope is final.
the (non-POSIX) res_search API presently does not honor search. this
may be added at some point in the future if needed.
resolv.conf is now parsed twice, at two different layers of the code
involved. this will be fixed in a subsequent patch.
|
|
rcode of 3 (NxDomain) was treated as a hard EAI_NONAME failure, but it
should instead return 0 (no results) so the caller can continue
searching. this will be important for adding search domain support.
the top-level caller will automatically return EAI_NONAME if there are
zero results at the end.
also, the case where rcode is 0 (success) but there are no results was
not handled. this happens when the domain exists but there are no A or
AAAA records for it. in this case a hard EAI_NONAME should be imposed
to inhibit further search, since the name was defined and just does
not have any address associated with it. previously a misleading hard
failure of EAI_FAIL was reported.
|
|
|
