Re: [PATCH 2/3] Move register_t to system-specific header

Sebastian Huber <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <1780050212.86692.1550084486778.JavaMail.zimbra@embedded-brains.de>
----- Am 13. Feb 2019 um 18:06 schrieb Corinna Vinschen [email protected]:

> On Feb 13 14:19, Sebastian Huber wrote:
>> Signed-off-by: Sebastian Huber <[email protected]>
>> ---
>>  newlib/libc/include/machine/types.h           | 2 ++
>>  newlib/libc/include/sys/types.h               | 2 +-
>>  newlib/libc/sys/rtems/include/machine/types.h | 2 ++
>>  winsup/cygwin/include/machine/types.h         | 2 ++
>>  4 files changed, 7 insertions(+), 1 deletion(-)
>> 
>> diff --git a/newlib/libc/include/machine/types.h
>> b/newlib/libc/include/machine/types.h
>> index 19d0e8560..fab9cf72c 100644
>> --- a/newlib/libc/include/machine/types.h
>> +++ b/newlib/libc/include/machine/types.h
>> @@ -11,3 +11,5 @@ typedef	__uint64_t	u_quad_t;
>>  typedef	__int64_t	quad_t;
>>  typedef	quad_t *	qaddr_t;
>>  #endif
>> +
>> +typedef int register_t;
>> diff --git a/newlib/libc/include/sys/types.h b/newlib/libc/include/sys/types.h
>> index 2685df654..e05263d4e 100644
>> --- a/newlib/libc/include/sys/types.h
>> +++ b/newlib/libc/include/sys/types.h
>> @@ -36,7 +36,7 @@ typedef __uint32_t	u_int32_t;
>>  #if ___int64_t_defined
>>  typedef __uint64_t	u_int64_t;
>>  #endif
>> -typedef int register_t;
>> +
>>  #define __BIT_TYPES_DEFINED__ 1
> 
> Why move this out here?  Sure, it's wrong for 64 bit targets ATM,
> but moving it to rtems and Cygwin only means that the type suddenly
> disappears for other targets.  Better just fix it here for all targets,
> including defining uregister_t if __BSD_VISIBLE.

I found three <machine/types.h> in Newlib, one for Cygwin, one for RTEMS and one for the rest. I moved the definition of register_t to the <machine/types.h> which is included by <sys/types.h> at the end.

If I change the type to __intptr_t wounldn't this break ABI compatibility on Cygwin?
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.