Previous GCC versions do not support the C23 change that
allows labels on declarations.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
(cherry picked from commit ec119972cb)
This avoids changing _res.options, which inteferes with change
detection as part of automatic reloading of /etc/resolv.conf.
Reviewed-by: DJ Delorie <dj@redhat.com>
(cherry picked from commit 868ab8923a)
In single-request mode, there is no second response after an error
because the second query has not been sent yet. Waiting for it
introduces an unnecessary timeout.
Reviewed-by: DJ Delorie <dj@redhat.com>
(cherry picked from commit af625987d6)
It was raised on libc-help [1] that some Linux kernel interfaces expect
the libc to define __USE_TIME_BITS64 to indicate the time_t size for the
kABI. Different than defined by the initial y2038 design document [2],
the __USE_TIME_BITS64 is only defined for ABIs that support more than
one time_t size (by defining the _TIME_BITS for each module).
The 64 bit time_t redirects are now enabled using a different internal
define (__USE_TIME64_REDIRECTS). There is no expected change in semantic
or code generation.
Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu, and
arm-linux-gnueabi
[1] https://sourceware.org/pipermail/libc-help/2024-January/006557.html
[2] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
Reviewed-by: DJ Delorie <dj@redhat.com>
(cherry picked from commit a4ed0471d7)
This change relicenses the IBM portions of resolv/base64.c and
resolv/res_debug.c to a new license that does not have use-limited
patent language. The top-level LICENSE file is updated with the
license.
The relicensing was approved by IBM.
Signed-off-by: Brad Topol, IBM Director of Open Technologies <btopol@us.ibm.com>
Signed-off-by: Richard Fontana <rfontana@redhat.com>
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Starting with commit 40c0add7d4
"resolve: Remove __res_context_query alloca usage"
there is an endless loop in __res_context_query if
__res_context_mkquery fails e.g. if type is invalid. Then the
scratch buffer is resized to MAXPACKET size and it is retried again.
Before the mentioned commit, it was retried only once and with the
mentioned commit, there is no check and it retries in an endless loop.
This is observable with xtest resolv/tst-resolv-qtypes which times out
after 300s.
This patch retries mkquery only once as before the mentioned commit.
Furthermore, scratch_buffer_set_array_size is now only called with
nelem=2 if type is T_QUERY_A_AND_AAAA (also see mentioned commit).
The test tst-resolv-qtypes is also adjusted to verify that <func>
is really returning with -1 in case of an invalid type.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
After refactoring the alloca usage in 40c0add7d4 ("resolve: Remove
__res_context_query alloca usage") a few unaligned accesses to HEADER
fields surfaced. These unaligned accesses led to problems when running
the resolv test suite on sparc32-linux (leon) as many tests failed due to
SIGBUS crashes.
The issue(s) occured during T_QUERY_A_AND_AAAA queries as the second query
now can start on an unaligned address (previously it was explicitly aligned).
With this patch the unaligned accesses are now fixed by using the
UHEADER instead to ensure the fields are accessed with byte
loads/stores.
The patch has been verfied by running the resolv test suite on sparc32
and x86_64.
Signed-off-by: Ludwig Rydberg <ludwig.rydberg@gaisler.com>
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
pool_max_size denotes total allocated rows in pool but possibly not yet
initialized. it's pool_size that represents number of actually occupied
rows hence use it when freeing pool to avoid freeing random addresses.
Signed-off-by: Jan Palus <jpalus@fastmail.com>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
The bufsize on current Linux build is:
size_t bufsize = (type == 439963904 ? 2 : 1) * (12 + 4 + 255 + 1);
So with upper bound as 544 (2 * (12 + 4 + 255 + 1)). However, it might
increase to 2 * PACKETSIZE later with malloc. The default scratch_buffer
should fullfill the most usual allocation requirement.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Joe Simmons-Talbott <josimmon@redhat.com>
Without passing alt_dns_packet_buffer, __res_context_search can only
store 2048 bytes (what fits into dns_packet_buffer). However,
the function returns the total packet size, and the subsequent
DNS parsing code in _nss_dns_gethostbyname4_r reads beyond the end
of the stack-allocated buffer.
Fixes commit f282cdbe7f ("resolv: Implement no-aaaa
stub resolver option") and bug 30842.
4d3f846b88 ("hurd: Fix __TIMESIZE on x86_64") incidentaly dropped it
because it fixed hurd 64bit into setting __TIMESIZE to 64, and that case
was not having gai_suspend defined yet.
They are both used by __libc_freeres to free all library malloc
allocated resources to help tooling like mtrace or valgrind with
memory leak tracking.
The current scheme uses assembly markers and linker script entries
to consolidate the free routine function pointers in the RELRO segment
and to be freed buffers in BSS.
This patch changes it to use specific free functions for
libc_freeres_ptrs buffers and call the function pointer array directly
with call_function_static_weak.
It allows the removal of both the internal macros and the linker
script sections.
Checked on x86_64-linux-gnu, i686-linux-gnu, and aarch64-linux-gnu.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
C2x adds binary integer constants starting with 0b or 0B, and supports
those constants in strtol-family functions when the base passed is 0
or 2. Implement that strtol support for glibc.
As discussed at
<https://sourceware.org/pipermail/libc-alpha/2020-December/120414.html>,
this is incompatible with previous C standard versions, in that such
an input string starting with 0b or 0B was previously required to be
parsed as 0 (with the rest of the string unprocessed). Thus, as
proposed there, this patch adds 20 new __isoc23_* functions with
appropriate header redirection support. This patch does *not* do
anything about scanf %i (which will need 12 new functions per long
double variant, so 12, 24 or 36 depending on the glibc configuration),
instead leaving that for a future patch. The function names would
remain as __isoc23_* even if C2x ends up published in 2024 rather than
2023.
Making this change leads to the question of what should happen to
internal uses of these functions in glibc and its tests. The header
redirection (which applies for _GNU_SOURCE or any other feature test
macros enabling C2x features) has the effect of redirecting internal
uses but without those uses then ending up at a hidden alias (see the
comment in include/stdio.h about interaction with libc_hidden_proto).
It seems desirable for the default for internal uses to be the same
versions used by normal code using _GNU_SOURCE, so rather than doing
anything to disable that redirection, similar macro definitions to
those in include/stdio.h are added to the include/ headers for the new
functions.
Given that the default for uses in glibc is for the redirections to
apply, the next question is whether the C2x semantics are correct for
all those uses. Uses with the base fixed to 10, 16 or any other value
other than 0 or 2 can be ignored. I think this leaves the following
internal uses to consider (an important consideration for review of
this patch will be both whether this list is complete and whether my
conclusions on all entries in it are correct):
benchtests/bench-malloc-simple.c
benchtests/bench-string.h
elf/sotruss-lib.c
math/libm-test-support.c
nptl/perf.c
nscd/nscd_conf.c
nss/nss_files/files-parse.c
posix/tst-fnmatch.c
posix/wordexp.c
resolv/inet_addr.c
rt/tst-mqueue7.c
soft-fp/testit.c
stdlib/fmtmsg.c
support/support_test_main.c
support/test-container.c
sysdeps/pthread/tst-mutex10.c
I think all of these places are OK with the new semantics, except for
resolv/inet_addr.c, where the POSIX semantics of inet_addr do not
allow for binary constants; thus, I changed that file (to use
__strtoul_internal, whose semantics are unchanged) and added a test
for this case. In the case of posix/wordexp.c I think accepting
binary constants is OK since POSIX explicitly allows additional forms
of shell arithmetic expressions, and in stdlib/fmtmsg.c SEV_LEVEL is
not in POSIX so again I think accepting binary constants is OK.
Functions such as __strtol_internal, which are only exported for
compatibility with old binaries from when those were used in inline
functions in headers, have unchanged semantics; the __*_l_internal
versions (purely internal to libc and not exported) have a new
argument to specify whether to accept binary constants.
As well as for the standard functions, the header redirection also
applies to the *_l versions (GNU extensions), and to legacy functions
such as strtoq, to avoid confusing inconsistency (the *q functions
redirect to __isoc23_*ll rather than needing their own __isoc23_*
entry points). For the functions that are only declared with
_GNU_SOURCE, this means the old versions are no longer available for
normal user programs at all. An internal __GLIBC_USE_C2X_STRTOL macro
is used to control the redirections in the headers, and cases in glibc
that wish to avoid the redirections - the function implementations
themselves and the tests of the old versions of the GNU functions -
then undefine and redefine that macro to allow the old versions to be
accessed. (There would of course be greater complexity should we wish
to make any of the old versions into compat symbols / avoid them being
defined at all for new glibc ABIs.)
strtol_l.c has some similarity to strtol.c in gnulib, but has already
diverged some way (and isn't listed at all at
https://sourceware.org/glibc/wiki/SharedSourceFiles unlike strtoll.c
and strtoul.c); I haven't made any attempts at gnulib compatibility in
the changes to that file.
I note incidentally that inttypes.h and wchar.h are missing the
__nonnull present on declarations of this family of functions in
stdlib.h; I didn't make any changes in that regard for the new
declarations added.
This patch is split out of
<https://sourceware.org/pipermail/libc-alpha/2022-December/144122.html>.
atoi has undefined behavior on out-of-range input, which makes it
problematic to use anywhere in glibc that might be processing input
out-of-range for atoi but not specified to produce undefined behavior
for the function calling atoi. Change some uses of atoi to call
strtol instead; this avoids the undefined behavior, though there is no
guarantee that the overflow handling of strtol is really right in
those places either. This also serves to avoid localplt test failures
given an installed header redirection for strtol (which means that the
call from the inline atoi implementation doesn't end up at a hidden
alias from libc_hidden_proto).
Certainly, the use of atoi is questionable in argp-help.c (shared with
gnulib, so shouldn't depend on glibc implementation details, and
processing user-provided input), and maybe also in argp-parse.c (I'm
not sure what that code in argp-parse.c is meant to be used for). I
also changed inet/rexec.c and resolv/res_init.c similarly to use
strtol to avoid such localplt failures, although given those files (in
those versions) are only used in glibc it's not problematic for them
to rely on the specific behavior of glibc's atoi on out-of-range input
(in the absence of compiler optimizations based on the undefined
behavior) in the same way it's problematic for gnulib code to do so.
There may be other uses of atoi (or atol or atoll), in any of glibc's
installed code, for which it would also be appropriate to avoid the
undefined behavior on out-of-range input; this patch only fixes the
specific cases needed to avoid localplt failures.
Tested for x86_64.
clang emits an warning when a double alias redirection is used, to warn
the the original symbol will be used even when weak definition is
overridden. However, this is a common pattern for weak_alias, where
multiple alias are set to same symbol.
Reviewed-by: Fangrui Song <maskray@google.com>
This fixes this compiler error:
tst-resolv-invalid-cname.c: In function ‘test_mode_to_string’:
tst-resolv-invalid-cname.c:164:10: error: label at end of compound statement
case test_mode_num:
^~~~~~~~~~~~~
Fixes commit 9caf782276
("resolv: Add new tst-resolv-invalid-cname").
Introduce struct alloc_buffer to this function, and use it and
struct ns_rr_cursor in gaih_getanswer_slice. Adjust gaih_getanswer
and gaih_getanswer_noaaaa accordingly.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
If the name is not a host name, skip adding it to the result, instead
of reporting query failure. This fixes bug 12154 for getaddrinfo.
This commit still keeps the old parsing code, and only adjusts when
a host name is copied.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Allocate the pointer arrays only at the end, when their sizes
are known. This addresses bug 29305.
Skip over invalid names instead of failing lookups. This partially
fixes bug 12154 (for gethostbyname, fixing getaddrinfo requires
different changes).
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
res_use_inet6 always returns false since commit 3f8b44be0a
("resolv: Remove support for RES_USE_INET6 and the inet6 option").
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
The simplification takes advantage of the split from getanswer_r.
It fixes various aliases issues, and optimizes NSS buffer usage.
The new DNS packet parsing helpers are used, too.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
And expand the use of name_ok and qtype in getanswer_ptr (the
former also in getanswer_r).
After further cleanups, not much code will be shared between the
two functions.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
The public parser functions around the ns_rr record type produce
textual domain names, but usually, this is not what we need while
parsing DNS packets within glibc. This commit adds two new helper
functions, __ns_rr_cursor_init and __ns_rr_cursor_next, for writing
packet parsers, and struct ns_rr_cursor, struct ns_rr_wire as
supporting types.
In theory, it is possible to avoid copying the owner name
into the rname field in __ns_rr_cursor_next, but this would need
more functions that work on compressed names.
Eventually, __res_context_send could be enhanced to preserve the
result of the packet parsing that is necessary for matching the
incoming UDP packets, so that this works does not have to be done
twice.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
This function is useful for checking that the question name is
uncompressed (as it should be).
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
During packet parsing, only the binary name is available. If the name
equality check is performed before conversion to text, we can sometimes
skip the last step.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
During package parsing, only the binary representation is available,
and it is convenient to check that directly for conformance with host
name requirements.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
This avoids a compilation error:
tst-resolv-noaaaa.c: In function 'response':
tst-resolv-noaaaa.c:74:11: error: a label can only be part of a statement and a declaration is not a statement
char ipv4[4] = {192, 0, 2, i + 1};
^~~~
tst-resolv-noaaaa.c:79:11: error: a label can only be part of a statement and a declaration is not a statement
char *name = xasprintf ("ptr-%d", i);
^~~~
On 32-bit machines this has no affect. On 64-bit machines
{u}int_fast{16|32} are set as {u}int64_t which is often not
ideal. Particularly x86_64 this change both saves code size and
may save instruction cost.
Full xcheck passes on x86_64.
The structure HEADER is normally aligned to a word boundary but
sometimes it needs to be accessed when aligned on a byte boundary.
This change defines a new typedef, UHEADER, with alignment 1.
It is used to ensure the fields are accessed with byte loads and
stores when necessary.
V4: Change to res_mkquery.c deleted. Small whitespace fix.
V5: Move UHEADER typedef to resolv/resolv-internal.h. Replace all
HEADER usage with UHEADER in resolv/res_send.c.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The commit 737e873b30 ("resolv: Do not build libanl.so for ABIs starting
at 2.35") disabled building libanl for ports supporting only 2.35 and
later like OpenRISC.
However, the if statement was not updated quite correctly and the change
ends up disabling many tst-resolv* tests. This was not supposed to be
done and it causes test dependency errors like:
make: Entering directory 'gnu-home/glibc/resolv'
make: *** No rule to make target 'gnu-home/build-glibc/resolv/tst-resolv-res_ninit.out', needed by 'gnu-home/build-glibc/resolv/mtrace-tst-resolv-res_ninit.out'. Stop.
make: Leaving directory 'gnu-home/glibc/resolv'
This patch move the extra-libs += libanl definition and condition down
to be closer to other libanl definitions. The $(have-GLIBC_2.34)
condition now includes libanl-routines and libanl-shared-only-routines as
well.
Also, I have added a comment to endif of $(have-thread-library) to help
show the bondary of the have-thread-library definitions.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
I used these shell commands:
../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright
(cd ../glibc && git commit -am"[this commit message]")
and then ignored the output, which consisted lines saying "FOO: warning:
copyright statement not found" for each of 7061 files FOO.
I then removed trailing white space from math/tgmath.h,
support/tst-support-open-dev-null-range.c, and
sysdeps/x86_64/multiarch/strlen-vec.S, to work around the following
obscure pre-commit check failure diagnostics from Savannah. I don't
know why I run into these diagnostics whereas others evidently do not.
remote: *** 912-#endif
remote: *** 913:
remote: *** 914-
remote: *** error: lines with trailing whitespace found
...
remote: *** error: sysdeps/unix/sysv/linux/statx_cp.c: trailing lines
Replace a call to sprintf with an equivalent pair of stpcpy/strcpy calls
to avoid a GCC 12 -Wformat-overflow false positive due to recent optimizer
improvements.
It is at least "more random" than 0xffff & __getpid ();
Signed-off-by: Cristian Rodríguez <crrodriguez@opensuse.org>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
