Recommended headers include order

[Sylvain Beucler]

Hi,

I got a weird compilation warning when upgrading gnulib today.

Here's a test program:
  #include <string.h>
  #include <SDL.h>
  int main(void)
  {
    printf("sizeof(Sint8) = %d\n", sizeof(Sint8));
    printf("sizeof(int8_t) = %d\n", sizeof(int8_t));
    printf("sizeof(unsigned char) = %d\n", sizeof(unsigned char));
  }

With <string.h> it gives 4,4,1 (wrong)
Without <string.h> it gives 1,1,1 (correct)
With <string.h> below <SDL.h> it gives 1,1,1 (correct)

Afaics Gnulib's string.h will define __attribute__ to be empty:

  #ifndef __attribute__
  /* This feature is available in gcc versions 2.5 and later.  */
  # if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) || __STRICT_ANSI__
  #  define __attribute__(Spec) /* empty */
  # endif


This will alter the processing of <sys/types.h> included from <SDL.h>,
in particular the definition of int8_t at ligne 195:

  /* For GCC 2.7 and later, we can use specific type-size attributes.  */
  # define __intN_t(N, MODE) \
    typedef int int##N##_t __attribute__ ((__mode__ (MODE)))
  # define __u_intN_t(N, MODE) \
    typedef unsigned int u_int##N##_t __attribute__ ((__mode__ (MODE)))
  
  # ifndef __int8_t_defined
  #  define __int8_t_defined
  __intN_t (8, __QI__);

With <string.h> the last line expands to:
  typedef int int8_t ;
Without <string.h> it expands to:
  typedef int int8_t __attribute__ ((__mode__ (__QI__)));

This results in a different storage size for int8_t, which eventually
triggers a compile-test test from SDL_stdinc.h which abords
compilation:

  /usr/include/SDL/SDL_stdinc.h:108: error: size of array ‘SDL_dummy_sint8’ is 
negative

(I disabled that compile-time test for testing the program at the top
of this message)


So question is: what is the preferred way to include Gnulib headers?
I tend to include them first because they are meant to be the portable
foundation of the program.

In this case however this brings troubles and I should not include it
first.

Note that this issue just happened today, I never saw it before, and I
didn't recently touch my impacted code, so it might just be a bug.

Since SDL is also a kind of portability layer, maybe there's a
chicken-an-egg issue here.

What do you think?

-- 
Sylvain