| 2dd10e69 | 01-Nov-2024 |
riastradh <riastradh@NetBSD.org> |
string.h: Fix various symbol visibility issues.
1. Order declarations according to POSIX 2024 to make this easier to
review side-by-side with the spec.
2. Fix visibility of memccpy: XSI-only, not
string.h: Fix various symbol visibility issues.
1. Order declarations according to POSIX 2024 to make this easier to
review side-by-side with the spec.
2. Fix visibility of memccpy: XSI-only, not POSIX in general; require
_XOPEN_SOURCE, not just _POSIX_C_SOURCE.
3. Omit redundant _XOPEN_SOURCE test around stpcpy/stpncpy.
4. Hide strdup in POSIX 2001. Not POSIX (without XSI) until 2008.
5. Hide strerror_r until POSIX 2001. Can't find evidence of it in
any earlier POSIX or X/Open. (Not 100% sure on this one, maybe
someone can double-check my research.)
6. Add restrict to strlcat/strlcpy.
7. Omit redundant _XOPEN_SOURCE test around strndup and strnlen.
8. Hide strtok_r until POSIX 2001. Can't find evidence of it in
any earlier POSIX or X/Open. (Not 100% sure on this one, maybe
someone can double-check my research.)
Carry the restrict qualifiers on strlcat/strlcpy to libkern too.
Main reference:
https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/string.h.html
PR standards/58804: string.h: wrong visibility for memccpy
show more ...
|
| 22f9aeea | 24-Jul-2024 |
kre <kre@NetBSD.org> |
PR lib/58461 PR lib/58453 portability fixes
Revert previous (1.4) and make the changes properly.
If base is invalid, what gets left in *endptr by strtoimax()
is unspecified (it is not guaranteed t
PR lib/58461 PR lib/58453 portability fixes
Revert previous (1.4) and make the changes properly.
If base is invalid, what gets left in *endptr by strtoimax()
is unspecified (it is not guaranteed to be either nptr or unaltered)
and so cannot (in that case) be used in any way at all.
Since it is hard to determine from some implementations of
strtoimax() whether this happened or not, simply duplicate
the validity test for base here, so we know that error (EINVAL
because base is invalid) cannot occur from strtoimax(). In that
case, if we get an EINVAL from strtoimax we can simply ignore it,
as all it can mean is the (optional in POSIX) case where no
conversion occurred (where strtoi() sets the status to ECANCELED).
Since NetBSD never did that, this all changes nothing here, but
makes strtoi() portable to other environments using a different
version of strtoimax().
NFCI.
No pullups required, nothing has really changed, there never was
a NetBSD bug to fix.
show more ...
|
| 00d1317f | 16-Jul-2024 |
riastradh <riastradh@NetBSD.org> |
amd64: Fix performance regression in uniprocessor atomics/membars.
Back in 2022, I eliminated the MFENCE hotpatch in membar_sync because
it's essentially always more expensive than LOCK ADD with no
amd64: Fix performance regression in uniprocessor atomics/membars.
Back in 2022, I eliminated the MFENCE hotpatch in membar_sync because
it's essentially always more expensive than LOCK ADD with no benefit
for CPU/CPU store-before-load ordering. (It is relevant only for
non-temporal stores or write-combining memory.)
https://mail-index.netbsd.org/source-changes/2022/07/30/msg140047.html
But in that change, I made a mistake and _also_ eliminated the LOCK
hotpatch on uniprocessor amd64. And our assembler gas helpfully
interprets uppercase LOCK just like lowercase lock and assembles them
the same way, so I didn't notice.
This change restores the LOCK hotpatch, so that when booting on a
uniprocessor system (or a uniprocessor guest on a multicore host),
the LOCK prefix is replaced by NOP for a cheaper instruction.
Found by puzzling over how my explanation for PR kern/57199 could
possibly be correct when (on an amd64 guest) ddb x/i membar_sync kept
showing the lock prefix even in uniprocessor boots.
show more ...
|