[RFC] fixincludes: vxworks: add hack around ioLib.h/unistd.h mutual inclusion

[Bruce Korb]

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
>