Menu ▾ ▴

#2330 include_next issues

WSL
closed
Keith Marshall
headers (2)
Support
invalid
User_Environment_Issue
True
2017-01-26
2017-01-07
Jason Hood
No

gcc 5.3.0, mingwrt-3.22.4

In building diffutils-3.5, I've come across some issues with the headers in
mingwrt-3.22.4 (3.21.1 works fine). I've supplied a batch program to test
four such issues.

test1: wchar.h ends up being included twice (the workaround was to remove
wchar.h)

test2: system string.h including local wchar.h prevents mbstate_t being
defined (workaround was to undefine __STRING_H_SOURCED__)

test3: including time.h before stdio.h with a local sys/types.h that
defines off_t as a macro failed (workaround was to include stdio before time)

test4: system ctype.h with a local wctype.h prevents wctype functions being
declared (workaround was to include ctype (and string) after wctype).

2 Attachments
inc_next.zip
include-next.patch

Discussion

  • Keith Marshall

    Keith Marshall - 2017-01-08
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -8,7 +8,7 @@
 wchar.h)

 test2: system string.h including local wchar.h prevents mbstate_t being
-defined (workaround was to undefine __STRING_H_SOURCED__)
+defined (workaround was to undefine `__STRING_H_SOURCED__`)

 test3: including time.h before stdio.h with a local sys/types.h that
 defines off_t as a macro failed (workaround was to include stdio before time)
    • status: unread --> assigned
    • assigned_to: Keith Marshall
    • Attachments has changed:

    Diff:

    --- old
+++ new
@@ -1 +1,2 @@
 inc_next.zip (2.2 kB; application/zip)
+include-next.patch (3.1 kB; text/x-diff)
    • Type: Bug --> Feature
    • Patch attached: False --> True
     

  • Keith Marshall

    Keith Marshall - 2017-01-08

    Ouch! While it's tempting to dismiss this as inappropriate abuse of GCC's #include_next (mis)feature, rather than as a MinGW bug per-se, perhaps the attached patch might make the mingwrt implementation more robust?

    FWIW, after deducing the proper commands to run, from your batch file, (I don't use Windows, so I couldn't run the batch file directly), I cannot reproduce any diagnostic output from either your test1 or test3 cases, (although I could see duplicate function prototype declarations, when adding GCC's -E option for test1). I do see diagnostic output from your test2, and test4 cases, which (together with the duplicate prototypes in test1) disappears after applying the patch.

     

    Last edit: Keith Marshall 2017-01-08

  • Jason Hood

    Jason Hood - 2017-01-09

    That fixed it, with the diffutils lib compiling fine (but my diffutils release still has the workarounds).

    I was almost going to do an MSYS bash script, but no, I thought, surely someone working on a Windows compiler would be using Windows...

     

  • Jason Hood

    Jason Hood - 2017-01-10

    Oops, turns out I forgot to include test3/sys/types.h in the zip. Using #include "sys/types.h" in time.h fixed it.

     

  • Keith Marshall

    Keith Marshall - 2017-01-26
    • status: assigned --> closed
    • Type: Feature --> Support
    • Resolution: none --> invalid
    • Category: Unknown --> User_Environment_Issue
     

  • Keith Marshall

    Keith Marshall - 2017-01-26

    Okay, I've committed [597dad]: it makes the proposed changes in <ctype.h> and <string.h>, but it doesn't touch <time.h>. How many other similar issues might crawl out of the woodwork, just because some other project is insinuating broken headers, with the same names as properly implemented system headers, into the -isystem include path ahead of the official system headers? That's a bug in whatever other project is committing this abuse, and I will not take responsibility for such issues.

    Please report such bugs to the project which is responsible; this is not a MinGW bug, and consequently, I'm closing it as "invalid".

     

    Related

    Commit: [597dad]