Add the reasoning for why we use -isystem instead of -I, to avoid
confusing unsuspecting readers of the file.
Prompted-by: Alejandro Colomar <alx@kernel.org>
Handle the three potential system scenarios:
- system time_t is time64
- system time_t is time32 and supports time64
- system time_t is time32 and does not support time64
Add the explicit time32 and time64 functions when necessary and map
them accordingly for each of these cases.
These functions are used by code in the library, even though these
functions started as GNU extensions, they are present in all BSDs,
so we expose them as part of our interface on AIX.
Explicitly select what to include as part of the target ABI, instead of
letting autoconfiguration potentially break ABI if the system grows
functionality provided by the library.
Make almost all the library selectable per target. Do not install manual
pages for interfaces not included in the library. Control inclusion of
symbols in map file via pre-processor macros, and move the comments
describing the ABI selection to configure.ac.
For now the header files are included as is and filtered through
pre-processor conditionals. Eventually they might get switched to be
autogenerated at build time.
On most systems the err family of functions is already present, but are
missing the errc family of functions, which are also present on some
other systems. Splitting them into separate files will make it easer to
conditionally include one or the other.
These contain the fixes to the error handling logic.
In NetBSD the manual page for strtou.3 is generated from the strtoi.3
manual page applying some substitutions, the problem is that the
cross-references are then lost. We will still keep them separate.
Reported-by: Alejandro Colomar <alx@kernel.org>
Some linkers require the map file definitions to contain only symbols
that are present on the linked object, either in the map file or in the
sym file we generate from the map file.
This is preparatory work to be able to conditionally include symbols
in the man and sym files depending on the ABI definitions.
The code is only getting the address, but we might be performing an
addressing that is out-of-bounds. Avoid it and use the address form
instead.
Warned-by: cppcheck (objectIndex)
When the system provides implementations for user_from_uid() or
group_from_gid() we are not using these variables, so better not declare
them.
Fixes: commit 21d12b0211
The <sys/*> headers tend to define things that might be used by other
headers, so while they should be self-contained, it is better to simply
include them first.
This was made conditional, but the code part was accidentally left
untouched due to having ported it locally to use __progname, which
caused build failures on the stock repo.
Fixes: commit 046621d7967e7a0f08ae988bcf7e4cd1b6cf204c
When generating the .sym export file from the .map file, we are not
stripping these comments that are part of the same line as the symbol,
which causes ld(1) implementations to error out. Moving them before
the symbols avoids the need to strip them, as we are only keeping
actual symbol lines.
Get the program name from the COMM field from the proc filesystem.
We could use instead the information from the psinfo binary file under
/proc, but that seems to have a shorter string limit.
Although the function is documented as possibly returning NULL if it
cannot find a known source of information, we should still at least
attempt to port it to any supported system, and otherwise explicitly
mark it as not implementable for such systems if that was to be the
case.
This makes sure we include it when expected, alongside the man pages,
and the test cases, and do not accidentally break the ABI if the system
starts providing such interface.
We had several cases of code needing a strong alias, so we switch those
to use the new macro. This covers systems that support the alias
attribute and others such as macOS where we need to use assembler
directives to add the alias as the attribute is not supported.
The environ variable is supposed to be defined by the code using it, but
on glibc-based systems it will get defined if we request it, by including
<unistd.h> and defining _GNU_SOURCE.
AC_SYS_LARGEFILE in configure.ac is setting needed defines to make
64bit off_t on relevant platforms.
Fixes build on musl:
| src/funopen.c:68:28: error: unknown type name 'off64_t'; did you mean 'off_t'?
| funopen_seek(void *cookie, off64_t *offset, int whence)
| ^~~~~~~
| off_t
Closes: !24
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Guillem Jover <guillem@hadrons.org>
This function cannot be easily and (more importantly) correctly ported
without cooperation from the libc stdio layer. We already document that
users should be prepared to have the function not available on some
platforms and that they should ideally switch their code to other
more portable and better interfaces.
Instead of making the build fail, and requiring porters to add
exceptions for something that most probably cannot be ported correctly
anyway, simply print a warning and let it build. This will not be a
regression because on those systems libbsd would have never been built
before.
Prompted-by: Jens Finkhaeuser <jens@finkhaeuser.de>
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.
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.
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
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>