[Bug libstdc++/53457] New: Accommodate non-compliant ioctl() on VxWorks

[Bug libstdc++/53457] New: Accommodate non-compliant ioctl() on VxWorks

[rbmj at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53457

             Bug #: 53457
           Summary: Accommodate non-compliant ioctl() on VxWorks
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: rbmj@verizon.net
                CC: rbmj@verizon.net
              Host: x86_64-linux-gnu
            Target: powerpc-wrs-vxworks
             Build: x86_64-linux-gnu


Created attachment 27480
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27480
Patch

On VxWorks, ioctl()'s third argument is of type int, so this added
macro wraps over ioctl to cast the third argument to an integer.
This *cannot* be in config/os/vxworks/os_defines.h as otherwise
the function prototype will trigger the macro and it will be ugly.

Alternate solution is to #ifdef at the call site.

Attached patch is against trunk.  Without it the compile fails because VxWorks
ioctl() requires third argument to be of type int, and C++ doesn't allow
implicit conversion from pointer to integer.

[Bug libstdc++/53457] Accommodate non-compliant ioctl() on VxWorks

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53457

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|rbmj at verizon dot net     |

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-05-22 20:31:22 UTC ---
I'm not an expert in this area, but isn't this something fixincludes could
handle?

[Bug libstdc++/53457] Accommodate non-compliant ioctl() on VxWorks

[rbmj at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53457

rbmj at verizon dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rbmj at verizon dot net

--- Comment #2 from rbmj at verizon dot net 2012-05-22 20:45:59 UTC ---
I'm not a fi

[Bug libstdc++/53457] Accommodate non-compliant ioctl() on VxWorks

[rbmj at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53457

--- Comment #3 from rbmj at verizon dot net 2012-05-23 13:13:16 UTC ---
I don't know much about fixincludes, but it *seems* to me like it could be done
with fixincludes.  I don't know how to get fixincludes to do that, though.

Also, sorry for the cut-off comment earlier.

[Bug libstdc++/53457] Accommodate non-compliant ioctl() on VxWorks

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53457

--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-05-23 13:47:49 UTC ---
Then, please investigate that possibility, maybe ask for help on the mailing
list too, in principle I consider it a better solution.

[Bug libstdc++/53457] Accommodate non-compliant ioctl() on VxWorks

[rbmj at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53457

--- Comment #5 from rbmj at verizon dot net 2012-05-24 20:39:20 UTC ---
Would something like the following fixincludes hacks work?

/*
 *  Wrap VxWorks ioctl to keep everything pretty
 */
fix = {
    hackname    = vxworks_ioctl_macro;
    files       = ioLib.h;
    test        = " -r vxWorks.h ";

    c_fix       = format;
    c_fix_arg   = "%0\n"
        "#define ioctl(fd, func, arg) ((ioctl)((fd), (func), ((int)(arg))))\n";
    c_fix_arg   = "extern[\t ]+int[\t ]+ioctl[\t ]*\([\t ,[:alnum:]]\);";

    test_text   = "`touch vxWorks.h`"
        "extern int ioctl ( int asdf1234, int jkl, int qwerty ) ;";
};


/*
 *  This hack makes makes unistd.h more POSIX-compliant on VxWorks
 */
fix = {
    hackname    = vxworks_unistd;
    files       = unistd.h;
    test        = " -r vxWorks.h ";

    select      = "#[\t ]*include[\t ]+<vxWorks.h>";
    c_fix       = format;
    c_fix_arg   = "%0\n#include <ioLib.h>\n"
        "#ifndef STDIN_FILENO\n"
        "#define STDIN_FILENO 0\n"
        "#endif\n"
        "#ifndef STDOUT_FILENO\n"
        "#define STDOUT_FILENO 1\n"
        "#endif\n"
        "#ifndef STDERR_FILENO\n"
        "#define STDERR_FILENO 2\n"
        "#endif\n";

    test_text   = "`touch vxWorks.h`"
        "#include <vxWorks.h>\n";
}; 

For some reason fixincludes doesn't seem to be doing *anything* when I build
though - I'm confused as to how I run it.  Though looking at fixincludes/README
and the make check tests, everything *looks* correct.

I'm not sure why fixincludes doesn't appear to be applying any fixes.  I can't
find any headers in GCC's build tree that it's applying to, and it's not
applying them to the system headers either.

[Bug libstdc++/53457] Accommodate non-compliant ioctl() on VxWorks

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53457

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-05-24 22:17:15 UTC ---
I think you should post your ongoing work on the mailing lists (gcc-patches and
CC libstdc++)

[Bug libstdc++/53457] Accommodate non-compliant ioctl() on VxWorks

[rbmj at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53457

--- Comment #7 from rbmj at verizon dot net 2012-06-25 18:23:02 UTC ---
Fixed with this (approved, but not committed) patch series:
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00382.html

[Bug libstdc++/53457] Accommodate non-compliant ioctl() on VxWorks

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53457

--- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-01 23:43:25 UTC ---
Can we close this now? I think we figured out that wasn't a C++ library-proper
issue, instead a fixincludes issue, but I don't understand whether the patches
are actually in and we can close this?!?

[Bug libstdc++/53457] Accommodate non-compliant ioctl() on VxWorks

[rbmj at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53457

--- Comment #9 from rbmj at verizon dot net 2012-10-02 01:08:00 UTC ---
Paolo:

This was wrapped up with several other fixincludes patches with regards to
vxWorks, and Bruce Korb has approved the set and has agreed to commit. 
However, he's currently busy and unable to commit until "the end of October".

Ref: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01619.html

Robert Mason

[Bug target/53457] Accommodate non-compliant ioctl() on VxWorks

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53457

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-10-02
          Component|libstdc++                   |target
     Ever Confirmed|0                           |1

--- Comment #10 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-02 09:56:34 UTC ---
Ah I see. The problem is that he wants to do the work in a special way,
otherwise if we had an unified patch ready to go in as-is I could do the work,
of course. Please let me know if I can help (maybe Bruce Korb can do the
preparatory work even if he cannot commit?!?). Anyway, this is now "target".

[Bug target/53457] Accommodate non-compliant ioctl() on VxWorks

[rbmj at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53457

--- Comment #11 from rbmj at verizon dot net 2012-10-02 18:21:50 UTC ---
I've tried to split it up as I think Bruce wanted; if you check the thread,
those patches should all be ready.

[Bug target/53457] Accommodate non-compliant ioctl() on VxWorks

[rbmj at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53457

rbmj at verizon dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #12 from rbmj at verizon dot net 2012-10-30 02:01:45 UTC ---
Fixed in 192952!