identical pre-processor constants in x86_64

2011-09-26
2013-06-06
  • Andres Colubri

    Andres Colubri - 2011-09-26

    I'm building glib with x86_64-w64-mingw32 as the host architecture. It turns out that the following constants

    EOVERFLOW and EFBIG
    ENOTSOCK and WSAENOTSOCK

    appear to represent the same value, which leads to switch-case errors during compilation of glib.

    This doesn't happen when using i686-w64-mingw32 as the host. Should I bring this to the glib developers, or it might reflect an issue in the mingw headers?

     
  • Ozkan Sezer

    Ozkan Sezer - 2011-09-26

    I don't think that there's any point in taking this to glib developers.

    For the EOVERFLOW vs. EFBIG, I think the best solution would be the LFS-ish support *.c files just return EFBIG and not define EOVERFLOW in errno.h, (v2.0 branch + trunk).

    For ENOTSOCK vs. WSAENOTSOCK and similar others in trunk:  Kai, I hate to say that "I told you so":)  IMO, we should remove them from errno.h (psdk_inc/_wsa_errnos.h have such definitions commented out for good reason.)

     
  • rubenvb

    rubenvb - 2011-09-26

    If I'm not mistaken, the "I told you so" refers to Kai's patches to better support libstdc++, among other things. C++11 requires some of these to be found by errno.h.

     
  • Ozkan Sezer

    Ozkan Sezer - 2011-09-26

    Well, such reason doesn't cure the problem, does it?

     
  • rubenvb

    rubenvb - 2011-09-26

    That was not my point, I only mentioned this to not let this fact be forgotten when a fix is looked into.

    How about taking errno constants from Boost? Libc++ took them from there too. They're very, very sure to work.
    http://svn.boost.org/svn/boost/trunk/boost/cerrno.hpp

    Boost is as liberal as it gets, and these error constants are "common knowledge" anyhow…

     
  • Kai Tietz

    Kai Tietz - 2011-09-26

    Well, was replying first not to forum :(

    the point raised here about EOVERFLOW and EFBIG isn't caused by my
    patch at all.  It was present before.  Point here is that all of those
    error-numbers are in general opaque.  Just by the fact that msvcrt's
    runtime never will set them, is not meaning that these defines are
    just evil.  About those socket related error-numbers, we can discuss
    to enable them just optional, but the EOVERFLOW and EFBIG issue is
    something old IIRC.

    If we are choosing here boost's or what ever's defines doesn't make them saner at all.  IMHO it is the sanest way to try to represent those missing errnos by their winerror-numbers.

    Kai

     
  • Andres Colubri

    Andres Colubri - 2011-09-26

    I see, so this is more complex issue.

    As additional information, it only affects two files in glib: giochannel.c and gsocket.c. For the time being, I added the following hack to these files in order to continue with the compilation:

    <giochannel.c>
    #ifdef EOVERFLOW
      #if EOVERFLOW != EFBIG
        case EOVERFLOW:
          return G_IO_CHANNEL_ERROR_OVERFLOW;
      #endif
    #endif

    <gsocket.c>
    #ifdef WSAENOTSOCK
      #if ENOTSOCK != WSAENOTSOCK
    case WSAENOTSOCK:
      #endif
    #endif

    It is quite crude, but it serves me as a temporary workaround.

     
  • Ozkan Sezer

    Ozkan Sezer - 2011-09-26

    For EOVERFLOW, I never said it's Kai's thing. It's Jon's thing.
    Looking at rev.4036 LFS64 commit, none of the *.c additions use EOVERFLOW, they only use EFBIG.  Jon: Is EOVERFLOW -> EFBIG not user's responsibility to define in case it's missing? Should we remove it?

     
  • Ozkan Sezer

    Ozkan Sezer - 2011-09-26

    OK.  EOVERFLOW is removed both from trunk and v2.0 errno.h.

     
  • Andres Colubri

    Andres Colubri - 2011-09-27

    The fix solves the EOVERFLOW/EFBIG conflict.

    Regarding ENOTSOCK and WSAENOTSOCK, should be taken care by the user (adding appropriate define when missing, patching conflicting code, etc)?

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks