This means we can add a trailing «\» to every element, so that they
can be removed without requiring modification of other lines, and can
be easily sorted.
Replace the old usage of $(nil) which could possibly end up with junk
added if such variable is ever defined, in the environment.
This makes code using it non-portable, and requires the namespeced
headers from libbsd, instead of any generic system headers. It also
requires more code changes than the overlay mode.
On glibc 2.29 reallocarray() was moved to _DEFAULT_SOURCE.
Closes: !20
Based-on-patch-by: Callum Farmer <gmbr3@opensuse.org>
Signed-off-by: Guillem Jover <guillem@hadrons.org>
We test once whether __GLIBC__ is not defined, so we do not need to test
whether it is on the OR branch afterwards. We decouple the glibc version
restriction check from the _*_SOURCE variable, as that contains an
implicit opposite version check.
The former used to be the reference implementation, but it has been
stagnant to the point of not showing much signs of life. Switch to
the currently active and more complete implementation for references.
On the Hurd a small read(3) might end up (indirectly) copying the data
on the stack, which we will end up finding even when we have cleared
the buffer.
To avoid these side effects, we add a new function, that we force not
to be inlined, so that we can reuse the same stack space, that will
blank any possible stack side effects. This should be portable
regardless of stack growing up or down.
Diagnosis-by: Samuel Thibault <sthibault@debian.org>
Ideally we'd recommend getwline(3), but unfortunately even though it
was part of the ISO/IEC TR 24731-2:2010 draft, it did not make it into
C11 and is not widely implemented.
While we are only doing a pointer difference and not dereferencing it,
it's easier and more correct to do the pointer difference before passing
it to reallocarray().
Warned-by: gcc
While using fully uppercase man page titles has been the usual
convention for a very long time, it is rather ugly and something that
some other projects are switching away from.
Fix the following build failure with big endian SH (e.g. sh4aeb):
,---
In file included from nlist.c:44:
nlist.c: In function '__elf_is_okay__':
local-elf.h:223:25: error: 'ELFDATA2LMSB' undeclared (first use in this function); did you mean 'ELFDATA2LSB'?
223 | #define ELF_TARG_DATA ELFDATA2LMSB
| ^~~~~~~~~~~~
`---
Fixes: http://autobuild.buildroot.org/results/2980fb79c208454195d77383f1ece9afbd7f981bCloses: !19
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Guillem Jover <guillem@hadrons.org>
The arc4random() support for OpenBSD does not build. The intention was
to include any portability code so that the library could be easily
ported to such systems, but it makes little sense to build it on OpenBSD
where most of the functionality will be already present, or the software
would have been ported anyway.
[guillem@hadrons.org: Reword commit message to add rationale. ]
Closes: !15
Signed-off-by: Guillem Jover <guillem@hadrons.org>
- Remove trailing spaces.
- Declare file-scope functions and variables static.
- Declare functions with a proper prototype.
- Do not mix declarations and code for C90 conformance.
- Do not compare size_t and ssize_t variables.
Streams opened with for example open_memstream(3) will have no associated
file descriptor, and fileno(3) will fail.
Signed-off-by: Guillem Jover <guillem@hadrons.org>
This does not work with libcs that do not declare the structure
in a header file, like musl. And gets in the way of supporting
non-fd based streams.
Signed-off-by: Guillem Jover <guillem@hadrons.org>
This reverts commit beafad2657.
This test was already handled later on as part of the BUILD_LIBBSD_CTOR
conditional. Adding it to the unconditional set made the build fail when
the system does not have GNU .init_array section support.
Closes: #9
Analysis-by: Duncan Overbruck <mail@duncano.de>
We should not assume that something will implicitly check for this tool,
as we need it ourselves, and this is an internal implementation detail
of right now libtool.
Fixes: commit f11ab67223
We already search for it in `./configure` so let's respect
the result of that search.
This helps with cross-compilation and any other cases
where one might want to choose a different toolchain.
Closes: !16
Bug: https://bugs.gentoo.org/831863
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Guillem Jover <guillem@hadrons.org>
Mention the involved function instead of stating an implicit "this
function". Mention libbsd when proposing using an alternative libmd
to make the context clear.
When using the recent dlsym() based wrapper, we are not requiring any
symbol from libmd, as we resolve those dynamically at run-time. We were
ending up linking against libmd because in another part of the code we
require (depending on the architecture) the SHA512 functions for the
getentropy() local implementation. But that function might be provided
by the system libc on some systems, which means we end up not linking
against libmd at all.
To solve this we go back to the previous simpler solution of linking
directly, which had the main drawback of then making programs fail to
link when not specifying -lmd (on platforms that need it). And then
switch the .so link point from a symlink to a linker script, so that we
can inject the -lmd library as-needed. This is similar to what glibc is
doing.
Fixes: commit 31f034e386
To be able to rework the md5 deprecation logic, we need to detangle when
we depend on libmd due to requiring MD5 functions, which might be
otherwise provided by libc, or when we require SHA functions for the
internal getentropy() implementation.
The nlist() function is limited to handle ELF binaries of the same class
as size as the size_t of the architecture built.
In addition the SIZE_T_MAX macro is BSD specific, and was falling back
to the wrong constant on most 64-bit non-BSD systems.
Warned-by: gcc
Because some of the symbols are not otherwise referenced, GCC would like
to remove them.
Closes: !14
Signed-off-by: Guillem Jover <guillem@hadrons.org>
