| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
the _CS_V6_ENV and _CS_V7_ENV constants are required to be available for use
with confstr. glibc defines these constants with values 1148 and 1149,
respectively.
the only missing (and required) confstr constants are
_CS_POSIX_V7_THREADS_CFLAGS and _CS_POSIX_V7_THREADS_LDFLAGS which remain
unavailable in glibc.
|
| |
|
|
|
|
|
|
| |
this error resulted in an out-of-bounds read, as opposed to a reported
error, when calling the function with an argument one greater than the
max valid index.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
some of these may have been from ancient (pre-SUSv2) POSIX versions;
more likely, they were from POSIX drafts or glibc interpretations of
what ancient versions of POSIX should have added (instead they made
they described functionality mandatory and/or dropped it completely).
others are purely glibc-isms, many of them ill-thought-out, like
providing ways to lookup the min/max values of types at runtime
(despite the impossibility of them changing at runtime and the
impossibility of representing ULONG_MAX in a return value of type
long).
since our sysconf implementation does not support or return meaningful
values for any of these, it's harmful to have the macros around;
applications' build scripts may detect and attempt to use them, only
to get -1/EINVAL as a result.
if removing them does break some applications, and it's determined
that the usage was reasonable, some of these could be added back on an
as-needed basis, but they should return actual meaningful values, not
junk like they were returning before.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
based on patch by Timo Teräs. previously, the value zero was used as a
literal zero, meaning that all invalid sysconf "names", which should
result in sysconf returning -1, had to be explicitly listed. (in
addition, it was not possible for sysconf to set errno to EINVAL, as
there was no distinction between -1 as an error and -1 as a valid
result.)
now, the value 0 is used for invalid/undefined slots in the table and
a new switch table entry is used for returning literal zeros.
in addition, an off-by-one error in checking against the table size is
fixed.
|
| |
|
|
|
|
|
|
| |
the syscall is deprecated (replaced by prlimit64) and does not work
correctly on x32. this change mildly increases size, but is likely
needed anyway for newer archs that might omit deprecated syscalls.
|
|
|
|
|
|
|
| |
the previous handling of cases that could not fit in the 16-bit table
or which required non-constant results was extremely ugly and could
not scale. the new code remaps these keys into a contiguous range
that's efficient for a switch statement.
|
|
|
|
| |
per the specification, the terminating null byte is counted.
|
|
|
|
|
| |
this is the number of realtime signals available, not the maximum
signal number or total number of signals.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PAGE_SIZE was hardcoded to 4096, which is historically what most
systems use, but on several archs it is a kernel config parameter,
user space can only know it at execution time from the aux vector.
PAGE_SIZE and PAGESIZE are not defined on archs where page size is
a runtime parameter, applications should use sysconf(_SC_PAGE_SIZE)
to query it. Internally libc code defines PAGE_SIZE to libc.page_size,
which is set to aux[AT_PAGESZ] in __init_libc and early in __dynlink
as well. (Note that libc.page_size can be accessed without GOT, ie.
before relocations are done)
Some fpathconf settings are hardcoded to 4096, these should be actually
queried from the filesystem using statfs.
|
|
|
|
| |
the value of MQ_PRIO_MAX does not fit, so it needs to use OFLOW.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
also update another newish feature in sysconf, stackaddr
|
|
|
|
|
| |
i've been trying out openmp and it seems like it won't be much use
without this...
|
|
|
|
|
| |
this caused glib to try to allocate >2gb for getpwnam_r, and probably
numerous other problems.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
multiple opens of the same named semaphore must return the same
pointer, and only the last close can unmap it. thus the ugly global
state keeping track of mappings. the maximum number of distinct named
semaphores that can be opened is limited sufficiently small that the
linear searches take trivial time, especially compared to the syscall
overhead of these functions.
|
| |
|
|
|