limits.h fix

limits.h fix

[Mike Stump]

Currently, if a user has their own "limits.h", the:

  #include_next <limits.h>

in syslimits.h can find it, this is wrong.  Instead, we want that file
to find the system limits.h.  The below patch fixes this.

Thanks to Geoff for pointing out the solution...

Ok?

	* gsyslimits.h: Don't include_next <limits.h> here...
	* limitx.h: instead, include_next <limits.h> here.
	* limity.h: Simplify.

Doing diffs in .:
--- ./gsyslimits.h.~1~	2006-11-26 12:31:50.000000000 -0800
+++ ./gsyslimits.h	2007-04-02 12:37:38.000000000 -0700
@@ -4,5 +4,3 @@
    instead of this text.  */
 
 #define _GCC_NEXT_LIMITS_H		/* tell gcc's limits.h to recurse */
-#include_next <limits.h>
-#undef _GCC_NEXT_LIMITS_H
--- ./limitx.h.~1~	2006-11-26 12:31:48.000000000 -0800
+++ ./limitx.h	2007-04-02 13:51:40.000000000 -0700
@@ -1,12 +1,11 @@
 /* This administrivia gets added to the beginning of limits.h
    if the system has its own version of limits.h.  */
 
-/* We use _GCC_LIMITS_H_ because we want this not to match
-   any macros that the system's limits.h uses for its own purposes.  */
-#ifndef _GCC_LIMITS_H_  /* Terminated in limity.h.  */
-#define _GCC_LIMITS_H_
-
 #ifndef _LIBC_LIMITS_H_
 /* Use "..." so that we find syslimits.h only in this same directory.  */
 #include "syslimits.h"
 #endif
+#ifdef _GCC_NEXT_LIMITS_H
+#include_next <limits.h>
+#undef _GCC_NEXT_LIMITS_H
+#endif
--- ./limity.h.~1~	2006-11-26 12:31:49.000000000 -0800
+++ ./limity.h	2007-04-02 12:33:24.000000000 -0700
@@ -1,10 +0,0 @@
-/* This administrivia gets added to the end of limits.h
-   if the system has its own version of limits.h.  */
-
-#else /* not _GCC_LIMITS_H_ */
-
-#ifdef _GCC_NEXT_LIMITS_H
-#include_next <limits.h>		/* recurse down to the real one */
-#endif
-
-#endif /* not _GCC_LIMITS_H_ */
--------------

Re: limits.h fix

[Ian Lance Taylor]

mrs@apple.com (Mike Stump) writes:

> Currently, if a user has their own "limits.h", the:
> 
>   #include_next <limits.h>
> 
> in syslimits.h can find it, this is wrong.  Instead, we want that file
> to find the system limits.h.  The below patch fixes this.

Can you explain the problem in more detail?  I don't understand what
goes wrong.  And I don't understand how your proposed patch fixes it.
If your proposed patch is correct, then we can and should simplify
quite a bit further.

gcc's limits.h handling is rather complicated because it has to
correctly handle a number of different situations.  As far as I can
see, your patch is going to break the case where the system provides a
<limits.h> file and fixincludes has to modify that <limits.h> file.

Ian

Re: limits.h fix

[Mike Stump]

On Apr 5, 2007, at 9:00 AM, Ian Lance Taylor wrote:
> Can you explain the problem in more detail?

An example of how this goes wrong would be:

mrs2 $ mkdir quotedir
mrs2 $ touch quotedir/limits.h
mrs2 $ cat >t.c
#include <limits.h>
mrs2 $ gcc -E -iquotequotedir t.c | more
mrs2 $ gcc -E -iquotequotedir t.c | grep quotedir
# 1 "quotedir/limits.h" 1 3 4

The user intends that a

   #include "limits.h"

includes his limits.h.  And that a:

   #include <limits.h>

defines those things speced by the standard and his platform (and the  
compiler), and does not inlcude his limits.h.  Above, we see that the  
wrong limits.h is included.

Now, next, it helps to understand the semantics of #include_next.   
Those semantics are to search up the stack and include the next found  
file ignoring if the directory searched is a "" or a <> directory.

Next, it helps to understand that if one includes a file with "" from  
the same directory, then search stack is re-searched from the top  
(meaning, we begin the seach with the "" directories).  In our case,  
syslimits.h has the #include_next, and this is the only file that  
precisely can't have this construct, because it would then search the  
"" directories.

> And I don't understand how your proposed patch fixes it.

By removing the construct that can't work and replacing it with one  
that works,  What works is if the file that includes syslimits.h  
instead does the #include_next, and that's just what the patch does.

> If your proposed patch is correct, then we can and should simplify  
> quite a bit further.

Bug fixes first.  If a cleanup patch breaks anything, I want the  
cleanup patch to be individually revertible without backing out the  
change in functionality patch, so, I want to get mine in first.

> gcc's limits.h handling is rather complicated because it has to  
> correctly handle a number of different situations.  As far as I can  
> see, your patch is going to break the case where the system  
> provides a <limits.h> file and fixincludes has to modify that  
> <limits.h> file.

We can have someone from such a system test my patch and tell us if  
it does.  We engineered it to not break them.  What are your  
concerns?  The fixed limits.h file is installed as syslimits.h and is  
included by the gcc installed limits.h, as originally designed, that  
part of the design is untouched and unchanged.

Re: limits.h fix

[Ian Lance Taylor]

Mike Stump <mrs@apple.com> writes:

> On Apr 5, 2007, at 9:00 AM, Ian Lance Taylor wrote:
> > Can you explain the problem in more detail?
> 
> An example of how this goes wrong would be:
> 
> mrs2 $ mkdir quotedir
> mrs2 $ touch quotedir/limits.h
> mrs2 $ cat >t.c
> #include <limits.h>
> mrs2 $ gcc -E -iquotequotedir t.c | more
> mrs2 $ gcc -E -iquotequotedir t.c | grep quotedir
> # 1 "quotedir/limits.h" 1 3 4

Thanks for the explanation.

> > gcc's limits.h handling is rather complicated because it has to
> > correctly handle a number of different situations.  As far as I can
> > see, your patch is going to break the case where the system
> > provides a <limits.h> file and fixincludes has to modify that
> > <limits.h> file.
> 
> We can have someone from such a system test my patch and tell us if
> it does.  We engineered it to not break them.  What are your
> concerns?  The fixed limits.h file is installed as syslimits.h and is
> included by the gcc installed limits.h, as originally designed, that
> part of the design is untouched and unchanged.

You're right, I was wrong.  I don't see a problem with your patch.
You could move the #include_next inside the #ifndef _LIBC_LIMITS_H_,
but it's not a big deal.


One problem I have always had with the current limits.h handling is
that LIMITS_H_TEST is awkward for cross-compilers.  I think this could
all be simplified by introducing #include_try_next which would
silently do nothing if there was no next header file.  Then we could
eliminate limitx.h, limity.h, and gsyslimits.h, and simply change
glimits.h to always start with #include_try_next <limits.h>.  However,
I have not actually tried to implement that.

Ian

Re: limits.h fix

[Mike Stump]

On Apr 2, 2007, at 2:11 PM, Mike Stump wrote:
> Currently, if a user has their own "limits.h", the:
>
>   #include_next <limits.h>
>
> in syslimits.h can find it, this is wrong.  Instead, we want that file
> to find the system limits.h.  The below patch fixes this.
>
> Thanks to Geoff for pointing out the solution...
>
> Ok?

http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00074.html

Ping?

Re: limits.h fix

[Mike Stump]

Ping?

On Apr 25, 2007, at 7:15 PM, Mike Stump wrote:
> On Apr 2, 2007, at 2:11 PM, Mike Stump wrote:
>> Currently, if a user has their own "limits.h", the:
>>
>>  #include_next <limits.h>
>>
>> in syslimits.h can find it, this is wrong.  Instead, we want that  
>> file
>> to find the system limits.h.  The below patch fixes this.
>>
>> Thanks to Geoff for pointing out the solution...
>>
>> Ok?
>
> http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00074.html
>
> Ping?

Re: limits.h fix

[Mike Stump]

On Apr 2, 2007, at 2:11 PM, Mike Stump wrote:
> Currently, if a user has their own "limits.h", the:
>
>   #include_next <limits.h>
>
> in syslimits.h can find it, this is wrong.  Instead, we want that file
> to find the system limits.h.  The below patch fixes this.

In addition, I think the patch also fixes:

#import <limits.h>

int main(int argc, char **argv)
{
   char path [PATH_MAX];
   path[0] = '\0';
   return 0;
}

Re: limits.h fix

[Andrew Pinski]

On 4/2/07, Mike Stump <mrs@apple.com> wrote:
> Currently, if a user has their own "limits.h", the:
>
>   #include_next <limits.h>
>
> in syslimits.h can find it, this is wrong.  Instead, we want that file
> to find the system limits.h.  The below patch fixes this.
>
> Thanks to Geoff for pointing out the solution...

Can you make sure this does not break glibc's limit.h which actually
does #include_next <limits.h> if GCC's limits.h has not been included.

Thanks,
Andrew Pinski

Re: limits.h fix

[Mike Stump]

PIng?

On May 2, 2007, at 11:16 AM, Mike Stump wrote:
> Ping?
> On Apr 25, 2007, at 7:15 PM, Mike Stump wrote:
>> On Apr 2, 2007, at 2:11 PM, Mike Stump wrote:
>>> Currently, if a user has their own "limits.h", the:
>>>
>>>  #include_next <limits.h>
>>>
>>> in syslimits.h can find it, this is wrong.  Instead, we want that  
>>> file
>>> to find the system limits.h.  The below patch fixes this.
>>>
>>> Thanks to Geoff for pointing out the solution...
>>>
>>> Ok?
>>
>> http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00074.html
>>
>> Ping?

Re: limits.h fix

[Mike Stump]

On Apr 5, 2007, at 6:12 PM, Ian Lance Taylor wrote:
> Mike Stump <mrs@apple.com> writes:
>
>> On Apr 5, 2007, at 9:00 AM, Ian Lance Taylor wrote:
>> We can have someone from such a system test my patch and tell us if
>> it does.  We engineered it to not break them.  What are your
>> concerns?  The fixed limits.h file is installed as syslimits.h and is
>> included by the gcc installed limits.h, as originally designed, that
>> part of the design is untouched and unchanged.
>
> You're right [... ]  I don't see a problem with your patch.

So, since they've now knighted, oops, I mean, blessed you...

Ping?

> http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00074.html
>
> Ping?

Re: limits.h fix

[Ian Lance Taylor]

Mike Stump <mrs@apple.com> writes:

> On Apr 5, 2007, at 6:12 PM, Ian Lance Taylor wrote:
> > Mike Stump <mrs@apple.com> writes:
> >
> >> On Apr 5, 2007, at 9:00 AM, Ian Lance Taylor wrote:
> >> We can have someone from such a system test my patch and tell us if
> >> it does.  We engineered it to not break them.  What are your
> >> concerns?  The fixed limits.h file is installed as syslimits.h and is
> >> included by the gcc installed limits.h, as originally designed, that
> >> part of the design is untouched and unchanged.
> >
> > You're right [... ]  I don't see a problem with your patch.
> 
> So, since they've now knighted, oops, I mean, blessed you...
> 
> Ping?
> 
> > http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00074.html
> >
> > Ping?

This is OK if you follow up with a patch to remove limity.h.

Thanks.

Ian