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?
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.)
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.
Well, such reason doesn't cure the problem, does it?
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.
Boost is as liberal as it gets, and these error constants are "common knowledge" anyhow…
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.
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:
#if EOVERFLOW != EFBIG
#if ENOTSOCK != WSAENOTSOCK
It is quite crude, but it serves me as a temporary workaround.
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?
I thought it was in use somewhere else according to POSIX docs, but apparently not. Go ahead and remove it from errno.h.
Seems like its OK to use EINVAL as well according to <http://pubs.opengroup.org/onlinepubs/007908799/xsh/ftruncate.html>.
OK. EOVERFLOW is removed both from trunk and v2.0 errno.h.
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.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.