about summary refs log tree commit diff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* dns query core: detect udp truncation at recv timeRich Felker2022-10-191-4/+13
| | | | | | | | | | | | | | | | | | we already attempt to preclude this case by having res_send use a sufficiently large temporary buffer even if the caller did not provide one as large as or larger than the udp dns max of 512 bytes. however, it's possible that the caller passed a custom-crafted query packet using EDNS0, e.g. to get detailed DNSSEC results, with a larger udp size allowance. I have also seen claims that there are some broken nameservers in the wild that do not honor the dns udp limit of 512 and send large answers without the TC bit set, when the query was not using EDNS. we generally don't aim to support broken nameservers, but in this case both problems, if the latter is even real, have a common solution: using recvmsg instead of recvfrom so we can examine the MSG_TRUNC flag.
* getaddrinfo dns lookup: use larger answer buffer to handle long CNAMEsRich Felker2022-10-191-3/+5
| | | | | | | | | | | | | | | | | | | | | | | the size of 512 is not sufficient to get at least one address in the worst case where the name is at or near max length and resolves to a CNAME at or near max length. prior to tcp fallback, there was nothing we could do about this case anyway, but now it's fixable. the new limit 768 is chosen so as to admit roughly the number of addresses with a worst-case CNAME as could fit for a worst-case name that's not a CNAME in the old 512-byte limit. outside of this worst-case, the number of addresses that might be obtained is increased. MAXADDRS (48) was originally chosen as an upper bound on the combined number of A and AAAA records that could fit in 512-byte packets (31 and 17, respectively). it is not increased at this time. so as to prevent a situation where the A records consume almost all of these slots (at 768 bytes, a "best-case" name can fit almost 47 A records), the order of parsing is swapped to process AAAA first. this ensures roughly half of the slots are available to each address family.
* dns: implement tcp fallback in __res_msend query coreRich Felker2022-09-221-2/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tcp fallback was originally deemed unwanted and unnecessary, since we aim to return a bounded-size result from getaddrinfo anyway and normally plenty of address records fit in the 512-byte udp dns limit. however, this turned out to have several problems: - some recursive nameservers truncate by omitting all the answers, rather than sending as many as can fit. - a pathological worst-case CNAME for a worst-case name can fill the entire 512-byte space with just the two names, leaving no room for any addresses. - the res_* family of interfaces allow querying of non-address records such as TLSA (DANE), TXT, etc. which can be very large. for many of these, it's critical that the caller see the whole RRset. also, res_send/res_query are specified to return the complete, untruncated length so that the caller can retry with an appropriately-sized buffer. determining this is not possible without tcp. so, it's time to add tcp fallback. the fallback strategy implemented here uses one tcp socket per question (1 or 2 questions), initiated via tcp fastopen when possible. the connection is made to the nameserver that issued the truncated answer. right now, fallback happens unconditionally when truncation is seen. this can, and may later be, relaxed for queries made by the getaddrinfo system, since it will only use a bounded number of results anyway. retry is not attempted again after failure over tcp. the logic could easily be adapted to do that, but it's of questionable value, since the tcp stack automatically handles retransmission and the successs answer with TC=1 over udp strongly suggests that the nameserver has the full answer ready to give. further retry is likely just "take longer to fail".
* res_send: use a temp buffer if caller's buffer is under 512 bytesRich Felker2022-09-221-1/+9
| | | | | | | | | | | | | | | for extremely small buffer sizes, the DNS query core in __res_msend may malfunction completely, being unable to get even the headers to determine the response code. but there is also a problem for reasonable sizes under 512 bytes: __res_msend is unable to determine if the udp answer was truncated at the recv layer, in which case it may be incomplete, and res_send is then unable to honor its contract to return the length of the full, non-truncated answer. at present, res_send does not honor that contract anyway when the full answer would exceed 512 bytes, since there is no tcp fallback, but this change at least makes it consistent in a context where this is the only "full answer" to be had.
* adapt res_msend DNS query core for working with multiple socketsRich Felker2022-09-211-6/+11
| | | | | this is groundwork for TCP fallback support, but does not itself change behavior in any way.
* getaddrinfo: add EAI_NODATA error code to distinguish NODATA vs NxDomainRich Felker2022-09-205-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this was apparently omitted long ago out of a lack of understanding of its importance and the fact that POSIX doesn't specify it. despite not being officially standardized, however, it turns out that at least AIX, glibc, NetBSD, OpenBSD, QNX, and Solaris document and support it. in certain usage cases, such as implementing a DNS gateway on top of the stub resolver interfaces, it's necessary to distinguish the case where a name does not exit (NxDomain) from one where it exists but has no addresses (or other records) of the requested type (NODATA). in fact, even the legacy gethostbyname API had this distinction, which we were previously unable to support correctly because the backend lacked it. apart from fixing an important functionality gap, adding this distinction helps clarify to users how search domain fallback works (falling back in cases corresponding to EAI_NONAME, not in ones corresponding to EAI_NODATA), a topic that has been a source of ongoing confusion and frustration. as a result of this change, EAI_NONAME is no longer a valid universal error code for getaddrinfo in the case where AI_ADDRCONFIG has suppressed use of all address families. in order to return an accurate result in this case, getaddrinfo is modified to still perform at least one lookup. this will almost surely fail (with a network error, since there is no v4 or v6 network to query DNS over) unless a result comes from the hosts file or from ip literal parsing, but in case it does succeed, the result is replaced by EAI_NODATA. glibc has a related error code, EAI_ADDRFAMILY, that could be used for the AI_ADDRCONFIG case and certain NODATA cases, but distinguishing them properly in full generality seems to require additional DNS queries that are otherwise not useful. on glibc, it is only used for ip literals with mismatching family, not for DNS or hosts file results where the name has addresses only in the opposite family. since this seems misleading and inconsistent, and since EAI_NODATA already covers the semantic case where the "name" exists but doesn't have any addresses in the requested family, we do not adopt EAI_ADDRFAMILY at this time. this could be changed at some point if desired, but the logic for getting all the corner cases with AI_ADDRCONFIG right is slightly nontrivial.
* fix error cases in gethostbyaddr_rRich Felker2022-09-191-2/+3
| | | | | | | EAI_MEMORY is not possible (but would not provide errno if it were) and EAI_FAIL does not provide errno. treat the latter as EBADMSG to match how it's handled in gethostbyname2_r (it indicates erroneous or failure response from the nameserver).
* remove impossible error case from gethostbyname2_rRich Felker2022-09-191-1/+0
| | | | | | | | EAI_MEMORY is not possible because the resolver backend does not allocate. if it did, it would be necessary for us to explicitly return ENOMEM as the error, since errno is not guaranteed to reflect the error cause except in the case of EAI_SYSTEM, so the existing code was not correct anyway.
* fix return value of gethostnbyname[2]_r on result not foundRich Felker2022-09-191-1/+1
| | | | | | | | these functions are horribly underspecified, inconsistent between historical systems, and should never have been included. however, the signatures we have match the glibc ones, and the glibc behavior is to treat NxDomain and NODATA results as a success condition, not an ENOENT error.
* dns: treat names rejected by res_mkquery as nonexistent rather than errorRich Felker2022-09-191-1/+1
| | | | | | | | | | | | | this distinction only affects search, but allows search to continue when concatenating one of the search domains onto the requested name produces a result that's not valid. this can happen when the concatenation is too long, or one of the search list entries is itself not valid. as a consequence of this change, having "." in the search domains list will now be ignored/skipped rather than making the lookup abort with no results (due to producing a concatenation ending in ".."). this behavior could be changed later if needed.
* res_mkquery: error out on consecutive final dots in nameRich Felker2022-09-191-0/+1
| | | | | | | | | | | | | | | the main loop already errors out on zero-length labels within the name, but terminates before having a chance to check for an erroneous final zero-length label, instead producing a malformed query packet with a '.' byte instead of the terminating zero. rather than poke at the look logic, simply detect this condition early and error out without doing anything. this also fixes behavior of getaddrinfo when "." appears in the search domain list, which produces a name ending in ".." after concatenation, at least in the sense of no longer emitting malformed packets on the network. however, due to other issues, the lookup will still fail.
* fix thread leak on timer_create(SIGEV_THREAD) failureAlexey Izbyshev2022-09-191-1/+5
| | | | | | | | | | | | After commit 5b74eed3b301e2227385f3bf26d3bb7c2d822cf8 the timer thread doesn't check whether timer_create() actually created the timer, proceeding to wait for a signal that might never arrive. We can't fix this by simply checking for a negative timer_id after pthread_barrier_wait() because we have no way to distinguish a timer creation failure and a request to delete a timer with INT_MAX id if it happens to arrive quickly (a variation of this bug existed before 5b74eed3b301e2227385f3bf26d3bb7c2d822cf8, where the timer would be leaked in this case). So (ab)use cancel field of pthread_t instead.
* re-enable vdso clock_gettime on arm (32-bit) with workaroundRich Felker2022-09-191-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 4486c579cbf0d989080705f515d08cb48636ba88 disabled vdso clock_gettime on arm due to a Linux kernel bug that was not understood at the time, whereby the vdso function silently produced catastrophically wrong results on some systems. since then, the bug was tracked down to the way the arm kernel disabled use of vdso clock_gettime on kernels where the necessary timer was not available or was disabled. it simply patched out the symbols, but it only did this for the legacy time32 functions, and left the time64 function in place but non-operational. kernel commit 4405bdf3c57ec28d606bdf5325f1167505bfdcd4 (first present in 5.8) provided the fix. if this were a bug that impacted all users of the broken kernel versions, we could probably ignore it and assume it had been patched or replaced. however, it's very possible that these kernels appear in the wild in devices running time32 userspace (glibc, musl 1.1.x, or some other environment) where they appear to work fine, but where our new binaries would fail catastrophically if we used the time64 vdso function. since the kernel has not (yet?) given us a way to probe for the working time64 vdso function semantically, we work around the problem by refusing to use the time64 one unless the time32 one is also present. this will revert to not using vdso at all if the time32 one is ever removed, but at least that's safe against wrong results and is just a missed optimization.
* fix fwprintf missing output to open_wmemstream FILEsRich Felker2022-09-071-1/+5
| | | | | | | | | | | | | | | open_wmemstream's write method was written assuming no buffering, since it sets the FILE up with buf_len of zero in order to avoid issues with position/seeking. however, as a consequence of commit bd57e2b43a5b56c00a82adbde0e33e5820c81164, a FILE being written to by the printf core has a temporary local buffer for the duration of the operation if it was unbuffered to begin with. since this was disregarded by the wide memstream's write method, output produced through this code path, particularly numeric fields, was missing from the output wchar buffer. copy the equivalent logic for using the buffered data from the byte-oriented open_memstream.
* dns: fail if ipv6 is disabled and resolv.conf has only v6 nameservesRich Felker2022-08-261-0/+5
| | | | | | | | | | | | | | if resolv.conf lists no nameservers at all, the default of 127.0.0.1 is used. however, another "no nameservers" case arises where the system has ipv6 support disabled/configured-out and resolv.conf only contains v6 nameservers. this caused the resolver to repeat socket operations that will necessarily fail (sending to one or more wrong-family addresses) while waiting for a timeout. it would be contrary to configured intent to query 127.0.0.1 in this case, but the current behavior is not conducive to diagnosing the configuration problem. instead, fail immediately with EAI_SYSTEM and errno==EAFNOSUPPORT so that the configuration error is reportable.
* use kernel-provided AT_MINSIGSTKSZ for sysconf(_SC_[MIN]SIGSTKSZ)Rich Felker2022-08-261-2/+12
| | | | | | | | | | | | use the legacy constant values if the kernel does not provide AT_MINSIGSTKSZ (__getauxval will return 0 in this case) and as a safety check if something is wrong and the provided value is less than the legacy constant. sysconf(_SC_SIGSTKSZ) returns SIGSTKSZ adjusted for the difference between the legacy constant MINSIGSTKSZ and the runtime value, so that the working space the application has on top of the minimum remains invariant under changes to the minimum.
* add sysconf keys/values for signal stack sizeRich Felker2022-08-261-0/+3
| | | | | | | | | | | | | | | | as a result of ISA extensions exploding register file sizes on some archs, using a constant for minimum signal stack size no longer seems viably future-proof. add sysconf keys allowing the kernel to provide a machine-dependent minimum applications can query to ensure they allocate sufficient space for stacks. the key names and indices align with the same functionality in glibc. see commit d5a5045382315e36588ca225889baa36ed0ed38f for previous action on this subject. ultimately, the macros MINSIGSTKSZ and SIGSTKSZ probably need to be deprecated, but that is standards-amendment work outside the scope of a single implementation.
* fix fallback when ipv6 is disabled but resolv.conf has v6 nameservesRich Felker2022-08-241-1/+2
| | | | | | | | | | | | apparently this code path was never tested, as it's not usual to have v6 nameservers listed on a system without v6 networking support. but it was always intended to work. when reverting to binding a v4 address, also revert the family in the sockaddr structure and the socklen for it. otherwise bind will just fail due to mismatched family/sockaddr size. fix dns resolver fallback when v6 nameservers are listed by
* epoll_create: fail with EINVAL if size is non-positiveKristina Martsenko2022-08-241-0/+1
| | | | | | This is a part of the interface contract defined in the Linux man page (official for a Linux-specific interface) and asserted by test cases in the Linux Test Project (LTP).
* use alt signal stack when present for implementation-internal signalsRich Felker2022-08-203-3/+3
| | | | | | | | | | | | | | | | | | | | | | a request for this behavior has been open for a long time. the motivation is that application code, particularly under some language runtimes designed around very-low-footprint coroutine type constructs, may be operating with extremely small stack sizes unsuitable for receiving signals, using a separate signal stack for any signals it might handle. progress on this was blocked at one point trying to determine whether the implementation is actually entitled to clobber the alt stack, but the phrasing "available to the implementation" in the POSIX spec for sigaltstack seems to make it clear that the application cannot rely on the contents of this memory to be preserved in the absence of signal delivery (on the abstract machine, excluding implementation-internal signals) and that we can therefore use it for delivery of signals that "don't exist" on the abstract machine. no change is made for SIGTIMER since it is always blocked when used, and accepted via sigwaitinfo rather than execution of the signal handler.
* freopen: reset stream orientation (byte/wide) and encoding ruleRich Felker2022-08-171-0/+2
| | | | | | | | | | this is a requirement of the C language (orientation) and POSIX (encoding rule) that was somehow overlooked. we rely on the fact that the buffer pointers have been reset by fflush, so that any future stdio operations on the stream will go through the same code paths they would on a newly-opened file without an orientation set, thereby setting the orientation as they should.
* ldso: support DT_RELR relative relocation formatFangrui Song2022-08-021-1/+1
| | | | this resolves DT_RELR relocations in non-ldso, dynamic-linked objects.
* use syscall_arg_t and __scc macro for arguments to __alt_socketcallAlex Xu (Hello71)2022-08-021-3/+3
| | | | | otherwise, pointer arguments are sign-extended on x32, resulting in EFAULT.
* fix ESRCH error handling for clock_getcpuclockidEugene Yudin2022-08-011-0/+1
| | | | | | the syscall used to probe availability of the clock fails with EINVAL when the requested pid does not exist, but clock_getcpuclockid is specified to use ESRCH for this purpose.
* aarch64: add vforkSzabolcs Nagy2022-08-011-0/+9
| | | | | | | | | | | | The generic vfork implementation uses clone(SIGCHLD) which has fork semantics. Implement vfork as clone(SIGCHLD|CLONE_VM|CLONE_VFORK, 0) instead which has vfork semantics. (stack == 0 means sp is unchanged in the child.) Some users rely on vfork semantics when memory overcommit is disabled or when the vfork child runs code that synchronizes with the parent process (non-conforming).
* fix mishandling of errno in getaddrinfo AI_ADDRCONFIG logicRich Felker2022-08-011-0/+2
| | | | | | | | | | | | | | | | this code attempts to use the value of errno from failure of socket or connect to infer availability of the requested address family (v4 or v6). however, in the case where connect failed, there is an intervening call to close between connect and the use of errno. close is not required to preserve errno on success, and in fact the __aio_close code, which is called whenever aio is linked and thus always called in dynamic-linked programs, unconditionally clobbers errno. as a result, getaddrinfo fails with EAI_SYSTEM and errno=ENOENT rather than correctly determining that the address family was unavailable. this fix is based on report/patch by Jussi Nieminen, but simplified slightly to avoid breaking the case where socket, not connect, failed.
* avoid limited space of random temp file names if clock resolution is lowRich Felker2022-06-231-1/+1
| | | | | | | this is not an issue that was actually hit, but I noticed it during previous changes to __randname: if the resolution of tv_nsec is too low, the space of temp file names obtainable by a thread could plausibly be exhausted. mixing in tv_sec avoids this.
* remove random filename obfuscation that leaks ASLR informationRich Felker2022-06-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | the __randname function is used by various temp file creation interfaces as a backend to produce a name to attempt using. it does not have to produce results that are safe against guessing, and only aims to avoid unintentional collisions. mixing the address of an object on the stack in a reversible manner leaked ASLR information, potentially allowing an attacker who can observe the temp files created and their creation timestamps to narrow down the possible ASLR state of the process that created them. there is no actual value in mixing these addresses in; it was just obfuscation. so don't do it. instead, mix the tid, just to avoid collisions if multiple processes/threads stampede to create temp files at the same moment. even without this measure, they should not collide unless the clock source is very low resolution, but it's a cheap improvement. if/when we have a guaranteed-available userspace csprng, it could be used here instead. even though there is no need for cryptographic entropy here, it would avoid having to reason about clock resolution and such to determine whether the behavior is nice.
* ensure distinct query id for parallel A and AAAA queries in resolverRich Felker2022-06-031-0/+3
| | | | | | | | | | | | | | assuming a reasonable realtime clock, res_mkquery is highly unlikely to generate the same query id twice in a row, but it's possible with a very low-resolution system clock or under extreme delay of forward progress. when it happens, res_msend fails to wait for both answers, and instead stops listening after getting two answers to the same query (A or AAAA). to avoid this, increment one byte of the second query's id if it matches the first query's. don't bother checking if the second byte is also equal, since it doesn't matter; we just need to ensure that at least one byte is distinct.
* mntent: fix potential mishandling of extremely long linesRich Felker2022-05-151-0/+2
| | | | | | | | | | | commit 05973dc3bbc1aca9b3c8347de6879ed72147ab3b made it so that lines longer than INT_MAX can in theory be read, but did not use a suitable type for the positions determined by sscanf. we could change to using size_t, but since the signature for getmntent_r does not admit lines longer than INT_MAX, it does not make sense to support them in the legacy thread-unsafe form either -- the principle here is that there should not be an incentive to use the unsafe function to get added functionality.
* mntent: fix parsing lines with optional fieldsAlyssa Ross2022-05-151-3/+7
| | | | | | | | | | | | | | According to fstab(5), the last two fields are optional, but this wasn't accepted. After this change, only the first field is required, which matches glibc's behaviour. Using sscanf as before, it would have been impossible to differentiate between 0 fields and 4 fields, because sscanf would have returned 0 in both cases due to the use of assignment suppression and %n for the string fields (which is important to avoid copying any strings). So instead, before calling sscanf, initialize every string to the empty string, and then we can check which strings are empty afterwards to know how many fields were matched.
* fix constraint violation in qsort wrapper around qsort_rRich Felker2022-05-061-1/+1
| | | | | function pointer types do not implicitly convert to void *. a cast is required here.
* use __fstat instead of __fstatat with AT_EMPTY_PATH in __map_fileRich Felker2022-05-041-2/+1
| | | | | this isolates knowledge of the nonstandard AT_EMPTY_PATH extension to one place and returns __map_file to its prior simplicity.
* provide an internal namespace-safe __fstatRich Felker2022-05-042-2/+5
| | | | | | this avoids the need for implementation-internal callers to depend on the nonstandard AT_EMPTY_PATH extension to use __fstatat and isolates knowledge of that extension to the implementation of __fstat.
* only use fstatat and others legacy stat syscalls if they existRich Felker2022-05-011-1/+9
| | | | riscv32 and future architectures only provide statx.
* drop direct use of stat syscalls in internal __map_fileRich Felker2022-05-011-3/+3
| | | | | | this function is used to implement some baseline ISO C interfaces, so it cannot call any of the stat functions by their public names. use the namespace-safe __fstatat instead.
* provide an internal namespace-safe __fstatatRich Felker2022-05-012-1/+11
| | | | | this makes it so we can drop direct stat syscall use in interfaces that can't use the POSIX namespace.
* drop direct use of stat syscalls in fchmodatRich Felker2022-05-011-8/+7
| | | | | | | | | | | | | | | | instead, use the fstatat/stat functions, so that the logic for which syscalls are present and usable is all in fstatat. this results in a slight increase in cost for old kernels on 32-bit archs: now statx will be attempted first rather than just using the legacy time32 syscalls, despite us not caring about timestamps. however, it's not even clear that the legacy syscalls *should* succeed if the timestamps are out of range; arguably they should fail with EOVERFLOW. as such, paying a small cost here on old kernels seems well-motivated. with this change, fchmodat itself is no longer blocking ports to new archs that lack the legacy syscalls.
* drop use of stat operation in temporary file name generationRich Felker2022-05-012-10/+6
| | | | | | | | | | | | | | | | | this change serves two purposes: 1. it eliminates one of the few remaining uses of the kernel stat structure which will not be present in future archs, avoiding the need for growing ifdef logic here. 2. it potentially makes the operations less expensive when the candidate exists as a non-symlink by avoiding the need to read the inode (assuming the directory tables suffice to distinguish symlinks). this uses the idiom I discovered while rewriting realpath for commit 29ff7599a448232f2527841c2362643d246cee36 of being able to use the readlink operation as an inexpensive probe for file existence that doesn't following symlinks.
* only fallback to gettimeofday/settimeofday syscalls if they existStefan O'Rear2022-05-011-0/+4
| | | | riscv32 and future architectures only provide the clock_ functions.
* only use getrlimit/setrlimit syscalls if they existStefan O'Rear2022-05-012-1/+11
| | | | riscv32 and future architectures only provide prlimit64.
* don't remap internal-use syscall macros to nonexistent time32 syscallsStefan O'Rear2022-04-271-10/+10
| | | | | | riscv32 and future architectures lack the _time32 variants entirely, so don't try to use their numbers. instead, reflect that they're not present.
* add missing POSIX confstr keys for pthread CFLAGS/LDFLAGSRich Felker2022-04-201-1/+1
| | | | | | | | | | _CS_POSIX_V7_THREADS_CFLAGS and _CS_POSIX_V7_THREADS_LDFLAGS have been missing for a long time, which is a conformance defect. we were waiting on glibc to add them or at least agree on the numeric values they will have so as to keep the numbering aligned. it looks like they will be added to glibc with these numbers, and in any case, this list does not have any significant churn that would result in the numbers getting taken.
* fix incorrect parameter name in internal netlink.h RTA_OK macroOndrej Jirman2022-04-101-1/+1
| | | | the wrong name works only by accident.
* accept null pointer as message argument to gettext functionspsykose2022-03-271-0/+3
| | | | | | | | | | the change to support passing null was rejected in the past on the grounds that GNU gettext documented it as undefined, on an assumption that only glibc accepted it and that the standalone GNU gettext did not. but it turned out that both explicitly accept it. in light of this, since some software assumes null can be passed safely, allow it.
* fix invalid free of duplocale object when malloc has been replacedIsaiah Poston2022-03-161-0/+5
| | | | | | | | | | | | newlocale and freelocale use __libc_malloc and __libc_free, but duplocale used malloc. If malloc was replaced, this resulted in invalid free using the wrong allocator when passing the result of duplocale to freelocale. Instead, use libc-internal malloc for duplocale. This bug was introduced by commit 1e4204d522670a1d8b8ab85f1cfefa960547e8af.
* nice: return EPERM instead of EACCESAlexey Kodanev2022-03-081-1/+8
| | | | | To comply with POSIX, change errno from EACCES to EPERM when the caller did not have the required privilege.
* protect stack canary from leak via read-as-string by zeroing second bytejvoisin2022-03-081-0/+9
| | | | | | | | | This reduces entropy of the canary from 64-bit to 56-bit in exchange for mitigating non-terminated C string overflows by setting the second byte of the canary to nul, so that off-by-one write overflow with a nul byte can still be detected. Idea from GrapheneOS bionic commit 7024d880b51f03a796ff8832f1298f2f1531fd7b
* math: avoid runtime conversions of floating-point constantsSzabolcs Nagy2022-03-082-2/+6
| | | | | | | | | | | | | | | gcc-12 with -frounding-mode will do inexact constant conversions at runtime according to the runtime rounding mode. in the math library we want constants to be rounding mode independent so this patch fixes cases where new runtime conversions happen with gcc-12. fortunately this only affects two minor cases, the fix uses global initializers where rounding mode does not apply. after the patch the same amount of conversions happen with gcc-12 as with gcc-11.
* fix spurious failures by fgetws when buffer ends with partial characterRich Felker2022-02-201-6/+1
| | | | | | | | | | | | | | | | | | | | commit a90d9da1d1b14d81c4f93e1a6d1a686c3312e4ba made fgetws look for changes to errno by fgetwc to detect encoding errors, since ISO C did not allow the implementation to set the stream's error flag in this case, and the fgetwc interface did not admit any other way to detect the error. however, the possibility of fgetwc setting errno to EILSEQ in the success path was overlooked, and in fact this can happen if the buffer ends with a partial character, causing mbtowc to be called with only part of the character available. since that change was made, the C standard was amended to specify that fgetwc set the stream error flag on encoding errors, and commit 511d70738bce11a67219d0132ce725c323d00e4e made it do so. thus, there is no longer any need for fgetws to poke at errno to handle encoding errors. this commit reverts commit a90d9da1d1b14d81c4f93e1a6d1a686c3312e4ba and thereby fixes the problem.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-05-30 16:26:09 +0000