Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
73 user(s) are online (67 user(s) are browsing Forums)

Members: 1
Guests: 72

MartinW, more...

Support us!

Headlines

 
  Register To Post  

Bug in Newlib Header?
Just popping in
Just popping in


See User information
I believe I've stumbled across a bug in one of the newlib header files (the ones from the most recent SDK). I was trying to compile GIFLIB, where one of the files has the following bit of code:

#ifndef SIZE_MAX
    #define SIZE_MAX     UINTPTR_MAX
#endif

It compiled fine when using clib2, but when using newlib I got the following error when SIZE_MAX was referenced:

In file included from openbsd-reallocarray.c:8:
openbsd-reallocarray.cIn function 'openbsd_reallocarray':
openbsd-reallocarray.c:25:19error'ULONG_MAX' undeclared (first use in this function)
      
nmemb && SIZE_MAX nmemb size) {
                   ^~~~~~~~
openbsd-reallocarray.c:25:19note'ULONG_MAX' is defined in header '<limits.h>'did you forget to '#include <limits.h>'?
openbsd-reallocarray.c:10:1:
+
#include <limits.h>

The file indeed does not include <limits.h>, but it does include <stdint.h>. The clib2 version of <stdint.h> contains the following:

#ifndef    _LIMITS_H
#include <limits.h>
#endif /* _LIMITS_H */

So <stdint.h> includes <limits.h>, and everything works fine. The newlib version of <stdint.h>, however, contains the following:

#if defined(__GNUC__) && \
  
( (__GNUC__ >= 4) || \
    
( (__GNUC__ >= 3) && defined(__GNUC_MINOR__) && (__GNUC_MINOR__ 2) ) )
/* gcc > 3.2 implicitly defines the values we are interested */
#define __STDINT_EXP(x) __##x##__
#else
#define __STDINT_EXP(x) x
#include <limits.h>
#endif

In other words, <limits.h> is included only if the version of GCC is 3.2 or earlier. That seems odd, which makes me think that "#include <limits.h>" should come after the #endif, not before it.

I made this change, and was able to build GIFLIB without error. I recompiled a number of my other projects, and nothing seems to have been broken by the change. But the flow of system headers can be complex and difficult to follow, so I thought I'd see if others can confirm that this is a bug, or explain why it isn't.

Go to top
Re: Bug in Newlib Header?
Site Builder
Site Builder


See User information
@msteed
Yeah, it seems you are right. I will forward it to the os4 developers and will be fixed in the next SDK release, if not earlier.

Thank you for this message.

Follow me on
Ko-fi, Twitter, YouTube, Twitch
Go to top
Re: Bug in Newlib Header?
Home away from home
Home away from home


See User information
@walkero

As a workaround we could move
#include <limits.h>

from
#if defined(__GNUC__) && \ 
  ( (__GNUC__ >= 4) || \ 
    
( (__GNUC__ >= 3) && defined(__GNUC_MINOR__) && (__GNUC_MINOR__ > 2) ) 
/* gcc > 3.2 implicitly defines the values we are interested */ 
#define __STDINT_EXP(x) __##x##__ 
#else 
#define __STDINT_EXP(x) x 
#include <limits.h> 
#endif

to
#if defined(__GNUC__) && \ 
  ( (__GNUC__ >= 4) || \ 
    
( (__GNUC__ >= 3) && defined(__GNUC_MINOR__) && (__GNUC_MINOR__ > 2) ) 
/* gcc > 3.2 implicitly defines the values we are interested */ 
#define __STDINT_EXP(x) __##x##__ 
#else 
#define __STDINT_EXP(x) x 
#endif
#include <limits.h>


for a quick fix...correct?

Go to top
Re: Bug in Newlib Header?
Site Builder
Site Builder


See User information
@Raziel
I think that's what msteed described as a solution that worked for him as well. So, yeah, until the next SDK release it would be wise to do so.

Follow me on
Ko-fi, Twitter, YouTube, Twitch
Go to top
Re: Bug in Newlib Header?
Just popping in
Just popping in


See User information
@Raziel, @walkero

Quote:
I think that's what msteed described as a solution that worked for him as well.

Yes, that's exactly what I did.

The bug seems to be something that's rarely encountered, since it's been around for some time (it was in at least the previous version of the SDK (53.30), too).

Go to top
Re: Bug in Newlib Header?
Home away from home
Home away from home


See User information
@msteed
@walkero

workaround in place...nice catch, thank you

Go to top

  Register To Post

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project