| Message ID | 20180525085857.12919-1-rasmus.villemoes@prevas.dk |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC] fixincludes: vxworks: add hack around ioLib.h/unistd.h mutual inclusion | expand |
Ick. Looks like the right fix to me and it is clearly constrained to vxworks platforms. Approved by me. On Fri, May 25, 2018 at 1:58 AM, Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote: > In old VxWorks headers (5.5), ioLib.h includes unistd.h via > > #include "unistd.h" > > We copy ioLib to include-fixed, with a few fixes applied. We also wrap > unistd.h, so that fixed header contains > > #include_next <unistd.h> > > This means that when user-code does > > #include <ioLib.h> > > they'll get the fixed header (as they should), and the include of > unistd.h from that picks up the fixed header (as it > should). Unfortunately, since "..." was used, it seems that "the > directory in the search path after the one where the current file was > found" for the include_next then ends up picking the include-fixed > directory again, so the fixed unistd.h just includes itself, and not the > system unistd.h - and at the time of the self-include, the guard macro > is defined, so we do not end up evaluating the include_next again. > > Changing to an angle-include instead still makes ioLib.h pick up the > fixed unistd.h, but since we now actually use the search path, > include_next works as intended. [In at least VxWorks 6.3, ioLib.h does > use <...> to include unistd.h, so this issue doesn't exist there.] > > There are lots of quote-includes like this in the VxWorks headers, and > I'm slightly surprised I can't find other examples of this kind of issue > in inclhack.def. In fact, I'd expect any #include "foo.h" in a fixed > header where foo.h is also fixed and has an #include_next <foo.h> would > have to be changed to #include <foo.h>. In fact, ioLib.h itself at > firsts seems to have the same problem with limits.h, since it also > contains > > #include "limits.h" > > However, in that case, the include-fixed version of limits.h does > > #include "syslimits.h" > > with an comment about explicitly using "..." so that we pick up > syslimits.h in the same directory, and _that_ file then does > > #include_next <limits.h> > > which again at first hits the include-fixed version, but this time > around we end up in the not _GCC_LIMITS_H_ branch, with > _GCC_NEXT_LIMITS_H defined, so we hit another > > #include_next <limits.h> > > and that time around limits.h was found via the include path, so we > finally end up recursing to the system limits.h. So this round-about > does seem to work for limits.h, but I'm wondering why that header file > alone gets special treatment by the gcc build system. > > Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> > --- > fixincludes/inclhack.def | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def > index d8bb17fe1a1..42c60e0c13b 100644 > --- a/fixincludes/inclhack.def > +++ b/fixincludes/inclhack.def > @@ -4843,6 +4843,22 @@ fix = { > test_text = "extern int write ( int , char * , size_t ) ;"; > }; > > +/* > + * This hack ensures the include_next in the fixed unistd.h actually > + * finds the system's unistd.h and not the fixed unistd.h again. > + */ > +fix = { > + hackname = vxworks_iolib_include_unistd; > + files = ioLib.h; > + mach = "*-*-vxworks*"; > + select = "#include \"unistd.h\""; > + > + c_fix = format; > + c_fix_arg = "#include <unistd.h>"; > + > + test_text = "#include \"unistd.h\""; > +}; > + > /* > * There are several name conflicts with C++ reserved words in X11 header > * files. These are fixed in some versions, so don't do the fixes if > -- > 2.15.1 >
On 05/25/2018 08:47 AM, Bruce Korb wrote: > Ick. Looks like the right fix to me and it is clearly constrained to > vxworks platforms. Approved by me. Thanks. Installed on the trunk. jeff
diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def index d8bb17fe1a1..42c60e0c13b 100644 --- a/fixincludes/inclhack.def +++ b/fixincludes/inclhack.def @@ -4843,6 +4843,22 @@ fix = { test_text = "extern int write ( int , char * , size_t ) ;"; }; +/* + * This hack ensures the include_next in the fixed unistd.h actually + * finds the system's unistd.h and not the fixed unistd.h again. + */ +fix = { + hackname = vxworks_iolib_include_unistd; + files = ioLib.h; + mach = "*-*-vxworks*"; + select = "#include \"unistd.h\""; + + c_fix = format; + c_fix_arg = "#include <unistd.h>"; + + test_text = "#include \"unistd.h\""; +}; + /* * There are several name conflicts with C++ reserved words in X11 header * files. These are fixed in some versions, so don't do the fixes if
In old VxWorks headers (5.5), ioLib.h includes unistd.h via #include "unistd.h" We copy ioLib to include-fixed, with a few fixes applied. We also wrap unistd.h, so that fixed header contains #include_next <unistd.h> This means that when user-code does #include <ioLib.h> they'll get the fixed header (as they should), and the include of unistd.h from that picks up the fixed header (as it should). Unfortunately, since "..." was used, it seems that "the directory in the search path after the one where the current file was found" for the include_next then ends up picking the include-fixed directory again, so the fixed unistd.h just includes itself, and not the system unistd.h - and at the time of the self-include, the guard macro is defined, so we do not end up evaluating the include_next again. Changing to an angle-include instead still makes ioLib.h pick up the fixed unistd.h, but since we now actually use the search path, include_next works as intended. [In at least VxWorks 6.3, ioLib.h does use <...> to include unistd.h, so this issue doesn't exist there.] There are lots of quote-includes like this in the VxWorks headers, and I'm slightly surprised I can't find other examples of this kind of issue in inclhack.def. In fact, I'd expect any #include "foo.h" in a fixed header where foo.h is also fixed and has an #include_next <foo.h> would have to be changed to #include <foo.h>. In fact, ioLib.h itself at firsts seems to have the same problem with limits.h, since it also contains #include "limits.h" However, in that case, the include-fixed version of limits.h does #include "syslimits.h" with an comment about explicitly using "..." so that we pick up syslimits.h in the same directory, and _that_ file then does #include_next <limits.h> which again at first hits the include-fixed version, but this time around we end up in the not _GCC_LIMITS_H_ branch, with _GCC_NEXT_LIMITS_H defined, so we hit another #include_next <limits.h> and that time around limits.h was found via the include path, so we finally end up recursing to the system limits.h. So this round-about does seem to work for limits.h, but I'm wondering why that header file alone gets special treatment by the gcc build system. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> --- fixincludes/inclhack.def | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)