originally, compilers did not provide these macros and we had to provide them ourselves. this meant we were redefining them, which was technically invalid unless the token sequence of the original definition matched exactly. the original patch proposed by Jules Maselbas to fix this made the definitions conditional on them not already being defined; however I suggested using #undef to avoid any possibly-wrong definitions already in place and ensure that the definitions are 1. the version adopted as commit 8b7048680731707d135ea231f81eb3eaf52378ee made this change. unfortunately, gcc is loud about not liking #undef of any __STDC_* macro name, and while warnings are suppressed in the system include path, there is apparently no way to suppress this warning if the system include dir has also been provided via -I. while normally we don't go out of our way to satisfy warnings over style in the public headers, in this case, it seems to be a matter of disagreement over contract of which part of "the implementation" is entitled to define or undefine macros belonging to the implementation, and it's quite reasonable to conclude that the compiler may reject attempts to undefine them. this commit reverts to the originally-submitted version of the patch making the definitions conditional.
Author: Xiaojuan Zhai <zhaixiaojuan@loongson.cn> Author: Meidan Li <limeidan@loongson.cn> Author: Guoqi Chen <chenguoqi@loongson.cn> Author: Xiaolin Zhao <zhaoxiaolin@loongson.cn> Author: Fan peng <fanpeng@loongson.cn> Author: Jiantao Shan <shanjiantao@loongson.cn> Author: Xuhui Qiang <qiangxuhui@loongson.cn> Author: Jingyun Hua <huajingyun@loongson.cn> Author: Liu xue <liuxue@loongson.cn> Author: Hongliang Wang <wanghongliang@loongson.cn>
commit f247462b0831cbf163e976ee9a909748c674b88b incorrectly hid ppoll in the presence of _GNU_SOURCE due to an oversight that defining _BSD_SOURCE does not implicitly define _GNU_SOURCE. at present, headers still have to explicitly check for each feature profile level; this may be changed at some point in the future via features.h, but has not been changed yet.
Undefine any previous __STDC_UTF_{16,32}__ macros before defining
them to prenvent any warnings of redefining macros.
This happens as a result of some compiler versions defining the macros
themselves.
See Linux commit 9300f00439743c4a34d735e1a27118eb68a1504e ("RISC-V: Add
ptrace support for vectors").
Note: Some relocation types were only used by binutils and accidentally exposed to previous versions of psABI. One of the values has been reused by GOT32_PCREL.
the ppoll function has been accepted as a future part of the standard as the outcome of Austin Group tracker issue 1263. at some point it should be exposed unconditionally, but for now, expose it in the default feature profile.
commit 37bb3cce4598c19288628e675eaf1cda6e96958f suppressed the declaration for C++, where it is wrongly interpreted as declaring the function as taking no arguments. with C23 removing non-prototype declarations, that problem is now also relevant to C. the non-prototype declaration for basename originates with commit 06aec8d7152dfb8360cb7ed9b3d7215ca0b0b500, where it was designed to avoid conflicts with programs which declare basename with the GNU signature taking const char *. that change was probably misguided, as it represents not only misaligned expectations with the caller, but also undefined behavior (calling a function that's been declared with the wrong type). we could opt to fix the declaration, but since glibc, with the gratuitously incompatible GNU-basename function, seems to be the only implementation that declares it in string.h, it seems better to just remove the declaration. this provides some warning if applications are being built expecting the GNU behavior but not getting it. if we declared it here, it would only produce a warning if the caller also declares it themselves (rare) or if the caller attempts to pass a const-qualified pointer.