H8: Minor cleanup in newlib/libc/include/sys/config.h.

  This patch defines the _POINTER_INT, _READ_WRITE_RETURN_TYPE, and
_READ_WRITE_BUFSIZE_TYPE macros explicitly for the H8 family, avoiding the
use of their default definitions. It also removes the unused H8300 macro.

Signed-off-by: Jan Dubiec <jdx@o2.pl>
---
 newlib/libc/include/sys/config.h | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)
  

Hi Jan,

Even though the H8300 flag isn't used within newlib, it is possible user
code could be referring to it since it is made available
via the header file.  If the first definition is wrong, that one can be
removed, but in the 2nd case, it appears to be correct.

-- Jeff J.

On Sun, Jul 12, 2026 at 10:19 PM Jan Dubiec <jdx@o2.pl> wrote:

> This patch defines the _POINTER_INT, _READ_WRITE_RETURN_TYPE, and
> _READ_WRITE_BUFSIZE_TYPE macros explicitly for the H8 family, avoiding the
> use of their default definitions. It also removes the unused H8300 macro.
>
> Signed-off-by: Jan Dubiec <jdx@o2.pl>
> ---
>  newlib/libc/include/sys/config.h | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/newlib/libc/include/sys/config.h
> b/newlib/libc/include/sys/config.h
> index c3cd51e86..7fbcb4992 100644
> --- a/newlib/libc/include/sys/config.h
> +++ b/newlib/libc/include/sys/config.h
> @@ -20,9 +20,6 @@
>  /* exceptions first */
>  #if defined(__H8500__) || defined(__W65__)
>  #define __SMALL_BITFIELDS
> -/* ???  This conditional is true for the h8500 and the w65, defining H8300
> -   in those cases probably isn't the right thing to do.  */
> -#define H8300 1
>  #endif
>
>  /* 16 bit integer machines */
> @@ -36,16 +33,18 @@
>
>  #if defined (__H8300__) || defined (__H8300H__) || defined(__H8300S__) ||
> defined (__H8300SX__)
>  #define __SMALL_BITFIELDS
> -#define H8300 1
>  #undef INT_MAX
>  #undef UINT_MAX
>  #define INT_MAX __INT_MAX__
>  #define UINT_MAX (__INT_MAX__ * 2U + 1)
> +#define _POINTER_INT __INTPTR_TYPE__
> +#define _READ_WRITE_RETURN_TYPE _ssize_t
> +#define _READ_WRITE_BUFSIZE_TYPE size_t
>  #endif
>
>  #if (defined(__CR16__) || defined(__CR16C__) ||defined(__CR16CP__))
>  #ifndef __INT32__
> -#define __SMALL_BITFIELDS
> +#define __SMALL_BITFIELDS
>  #undef INT_MAX
>  #undef UINT_MAX
>  #define INT_MAX 32767
> --
> 2.54.0
>
>
  

On 15.07.2026 01:57, Jeff Johnston wrote:
> Hi Jan,
> 
> Even though the H8300 flag isn't used within newlib, it is possible user 
> code could be referring to it since it is made available

IMO, it's unlikely, since the compiler already provides the __H8300H__, 
__H8300S__, and __H8300SX__ macros. But it's not a big deal.

> via the header file.  If the first definition is wrong, that one can be 
> removed, but in the 2nd case, it appears to be correct.
Do you mean something like in the attached patch?

/J.D.
newlib/libc/include/sys/config.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/newlib/libc/include/sys/config.h b/newlib/libc/include/sys/config.h
index c3cd51e86..e9e8c0b96 100644
--- a/newlib/libc/include/sys/config.h
+++ b/newlib/libc/include/sys/config.h
@@ -20,9 +20,6 @@
 /* exceptions first */
 #if defined(__H8500__) || defined(__W65__)
 #define __SMALL_BITFIELDS
-/* ???  This conditional is true for the h8500 and the w65, defining H8300
-   in those cases probably isn't the right thing to do.  */
-#define H8300 1
 #endif
 
 /* 16 bit integer machines */
@@ -41,11 +38,14 @@
 #undef UINT_MAX
 #define INT_MAX __INT_MAX__
 #define UINT_MAX (__INT_MAX__ * 2U + 1)
+#define _POINTER_INT __INTPTR_TYPE__
+#define _READ_WRITE_RETURN_TYPE _ssize_t
+#define _READ_WRITE_BUFSIZE_TYPE size_t
 #endif
 
 #if (defined(__CR16__) || defined(__CR16C__) ||defined(__CR16CP__))
 #ifndef __INT32__
-#define __SMALL_BITFIELDS      
+#define __SMALL_BITFIELDS
 #undef INT_MAX
 #undef UINT_MAX
 #define INT_MAX 32767
  

Yes.  Thanks.  Patch applied.

-- Jeff J.

On Wed, Jul 15, 2026 at 7:23 PM Jan Dubiec <jdx@o2.pl> wrote:

> On 15.07.2026 01:57, Jeff Johnston wrote:
> > Hi Jan,
> >
> > Even though the H8300 flag isn't used within newlib, it is possible user
> > code could be referring to it since it is made available
>
> IMO, it's unlikely, since the compiler already provides the __H8300H__,
> __H8300S__, and __H8300SX__ macros. But it's not a big deal.
>
> > via the header file.  If the first definition is wrong, that one can be
> > removed, but in the 2nd case, it appears to be correct.
> Do you mean something like in the attached patch?
>
> /J.D.
>
>