FW: is "syslimits.h" likely to change?

FW: is "syslimits.h" likely to change?

[Mark Galeck (CW)]

Hello,

GCC has this internal include file "included/syslimits.h".   This file, uses a non-standard C include directive "include_next" to recursively include "limits.h" from a second location.  

I need to change this syslimits.h for our internal use, since I cannot easily handle "include_next" in our build system (it is non-standard).  I can keep the same functionality, by adding another "system" include directory, and instead of

#include_next <limits.h>

I would have

#include <sys-include/limits.h>

Entirely the same functionality.  

But of course, if you guys change the GCC source  to remove the file syslimits.h or change it to a different functionality, I would be left incompatible.     


So, is syslimits.h likely to disappear or change?

Thank you,

Mark 

Re: FW: is "syslimits.h" likely to change?

[Ian Lance Taylor]

"Mark Galeck (CW)" <mgaleck@Brocade.com> writes:

> GCC has this internal include file "included/syslimits.h".   This file, uses a non-standard C include directive "include_next" to recursively include "limits.h" from a second location.  
>
> I need to change this syslimits.h for our internal use, since I cannot easily handle "include_next" in our build system (it is non-standard).  I can keep the same functionality, by adding another "system" include directory, and instead of
>
> #include_next <limits.h>
>
> I would have
>
> #include <sys-include/limits.h>
>
> Entirely the same functionality.  
>
> But of course, if you guys change the GCC source  to remove the file syslimits.h or change it to a different functionality, I would be left incompatible.     
>
>
> So, is syslimits.h likely to disappear or change?

It is not likely to disappear or change--it has been the same for many
years--but that is not a promise that it will never disappear or change.
It's an internal header, not something exposed to user view in any way.
I recommend that you simply ignore it in your build system.

Ian

RE: FW: is "syslimits.h" likely to change?

[Mark Galeck (CW)]

Thank you Ian, hopefully I will be compatible then for a long time, as Larry Wall would say "at least until the heat death of the Universe".

I can't "ignore it" :)  My build system cannot handle "include_next" - it cannot handle the situation where you are finding a header file in one -I directory, and later when you are trying to find it again, you ignore that directory and find it in a subsequent -I directory.  The system is extremely fast, like a sports car than will only go on asphalt (standard C and a GCC-like compiler). 
    
>I recommend that you simply ignore it in your build system.

Re: FW: is "syslimits.h" likely to change?

[Dave Korn]

On 12/04/2012 16:38, Mark Galeck (CW) wrote:
> Thank you Ian, hopefully I will be compatible then for a long time, as
> Larry Wall would say "at least until the heat death of the Universe".
> 
> I can't "ignore it" :)  My build system cannot handle "include_next" - it
> cannot handle the situation where you are finding a header file in one -I
> directory, and later when you are trying to find it again, you ignore that
> directory and find it in a subsequent -I directory.  The system is
> extremely fast, like a sports car than will only go on asphalt (standard C
> and a GCC-like compiler).

  I'm curious why your build system even needs to handle it?  The GCC version
of syslimits.h is a private thing, that GCC uses just for its own purposes to
adjust or override some of the definitions in the system's native syslimits.h;
if you aren't using GCC, then it shouldn't matter, and if you are, then it
should be automatic and transparent.  And if you're generating dependencies,
and using GCC as a compiler, then you should also use "gcc -M" to generate the
dependencies, since it'll get them canonically right, rather than any sort of
external makedepends utility.

  So, why does your build system care about it?

    cheers,
      DaveK