diff mbox series

endian.h: Define unsigned fixed-width integer types [BZ #31749]

Message ID 20240611084619.1110236-1-collin.funk1@gmail.com (mailing list archive)
State Superseded
Headers
Series endian.h: Define unsigned fixed-width integer types [BZ #31749] |

Checks

Context Check Description
redhat-pt-bot/TryBot-apply_patch success Patch applied to master at the time it was sent
redhat-pt-bot/TryBot-32bit success Build for i686
linaro-tcwg-bot/tcwg_glibc_build--master-aarch64 success Test passed
linaro-tcwg-bot/tcwg_glibc_check--master-aarch64 success Test passed
linaro-tcwg-bot/tcwg_glibc_build--master-arm success Test passed
linaro-tcwg-bot/tcwg_glibc_check--master-arm success Test passed

Commit Message

Collin Funk June 11, 2024, 8:45 a.m. UTC 
  The upcoming POSIX revision requires that uint16_t, uint32_t, and
uint64_t are defined in endian.h.  Optionally all symbols from
<stdint.h> may be defined.

This patch includes <bits/stdint-uintn.h> which defines the required
types and uint8_t.  This allows glibc to pass Gnulib's checks.

Signed-off-by: Collin Funk <collin.funk1@gmail.com>
---
 string/endian.h            | 3 +++
 string/test-endian-types.c | 1 -
 2 files changed, 3 insertions(+), 1 deletion(-)

Comments

Joseph Myers June 11, 2024, 1:04 p.m. UTC | #1 
On Tue, 11 Jun 2024, Collin Funk wrote:

>  #if defined __USE_MISC && !defined __ASSEMBLER__
> +/* Define uintN_t types.  */
> +#include <bits/stdint-uintn.h>
> +

__USE_MISC is not defined for any standard POSIX version.

Do you know the _POSIX_C_SOURCE value in the 2024 edition of POSIX (the 
most recent version I have is the February draft, which still has it as 
20yymmL; the HTML edition hasn't been published yet)?  We need to set up 
(in features.h) and document (in creature.texi) support for the new 
_XOPEN_SOURCE and _POSIX_C_SOURCE values, with associated internal 
conditions __GLIBC_USE (XOPEN2024) and __GLIBC_USE (POSIX2024), and go 
through all the changes in the new edition of POSIX, making sure that 
header declarations appear under appropriate conditions (or, as 
applicable, no longer appear for strict conformance with the latest 
version, in the case of any declarations that POSIX has removed) and that 
new features in general are properly implemented in glibc.

*In this particular case*, since <endian.h> wasn't in any previous version 
of POSIX, we don't actually need those conditionals - we could just remove 
__USE_MISC conditions around everything defined for the header in the new 
POSIX version (making sure to adjust the spaces after "#" accordingly for 
the removed #if level), and define the types in question unconditionally.
Collin Funk June 11, 2024, 2:58 p.m. UTC | #2 
Hi Joseph,

Joseph Myers <josmyers@redhat.com> writes:

> On Tue, 11 Jun 2024, Collin Funk wrote:
>
>>  #if defined __USE_MISC && !defined __ASSEMBLER__
>> +/* Define uintN_t types.  */
>> +#include <bits/stdint-uintn.h>
>> +
>
> __USE_MISC is not defined for any standard POSIX version.
>
> Do you know the _POSIX_C_SOURCE value in the 2024 edition of POSIX (the 
> most recent version I have is the February draft, which still has it as 
> 20yymmL; the HTML edition hasn't been published yet)?

No, I was using the February draft PDF as well.  I checked <features.h>
and didn't see a definition so I just left it behind __USE_MISC for the
time being.

> *In this particular case*, since <endian.h> wasn't in any previous version 
> of POSIX, we don't actually need those conditionals - we could just remove 
> __USE_MISC conditions around everything defined for the header in the new 
> POSIX version (making sure to adjust the spaces after "#" accordingly for 
> the removed #if level), and define the types in question unconditionally.

Sounds good, I can submit a revised patch.

Is the !defined __ASSEMBLER__ safe to remove?  It looks like perhaps
this header was at some point used in assembly code for constant macro
definitions without the functions.  Not sure if this is still the case
or if it should be worried about.

Collin
Joseph Myers June 11, 2024, 3:09 p.m. UTC | #3 
On Tue, 11 Jun 2024, Collin Funk wrote:

> Is the !defined __ASSEMBLER__ safe to remove?  It looks like perhaps
> this header was at some point used in assembly code for constant macro
> definitions without the functions.  Not sure if this is still the case
> or if it should be worried about.

That's the sort of thing that would best be tested with 
build-many-glibcs.py to see if any configurations are using <endian.h> 
(possibly indirectly) in assembly source at present.  It appears the 
original addition of that check was because of a use in SH strlen.S, which 
was removed in commit 3ce2865f93d42f4721d58088dd6ab1dac06ea85b "SH: 
Replace <endian.h> usage with pre-processor macros.", but maybe there are 
other places still relying on it in assembly source.
Collin Funk June 11, 2024, 3:16 p.m. UTC | #4 
Joseph Myers <josmyers@redhat.com> writes:

> That's the sort of thing that would best be tested with 
> build-many-glibcs.py to see if any configurations are using <endian.h> 
> (possibly indirectly) in assembly source at present.  It appears the 
> original addition of that check was because of a use in SH strlen.S, which 
> was removed in commit 3ce2865f93d42f4721d58088dd6ab1dac06ea85b "SH: 
> Replace <endian.h> usage with pre-processor macros.", but maybe there are 
> other places still relying on it in assembly source.

Thanks for the advice.  I'll do some testing and send an updated patch.

Collin
diff mbox series

Patch

diff --git a/string/endian.h b/string/endian.h
index fd20a2b198..1c5829d248 100644
--- a/string/endian.h
+++ b/string/endian.h
@@ -31,6 +31,9 @@ 
 #endif
 
 #if defined __USE_MISC && !defined __ASSEMBLER__
+/* Define uintN_t types.  */
+#include <bits/stdint-uintn.h>
+
 /* Conversion interfaces.  */
 # include <bits/byteswap.h>
 # include <bits/uintn-identity.h>
diff --git a/string/test-endian-types.c b/string/test-endian-types.c
index a0ff971f24..fa624e39c2 100644
--- a/string/test-endian-types.c
+++ b/string/test-endian-types.c
@@ -17,7 +17,6 @@ 
    <https://www.gnu.org/licenses/>.  */
 
 #include <endian.h>
-#include <stdint.h>
 
 int i;
 uint16_t u16;