MinGW runtime 4.x calls the dirent functions, opendir/readdir/closedir, in its startup code. This pollutes the namespace of, and breaks, application programs that have incompatible or entirely unrelated functions by that name, even if the application didn't include the dirent.h header. For example, a program that defines its own readdir will almost surely break the globbing of command-line arguments, and could even crash.
Please make the startup code call __opendir
, __readdir
, etc. instead, as symbols that begin with two underscores are "reserved", and cannot legitimately appear in an application.
Issues: #2106
Issues: #2111
Issues: #2112
Issues: #2113
I think __mingw_opendir, etc would be a better name.
Care to supply a patch against the 4.1-dev branch of mingw-org-wsl repository? If not this may wait until the 5.0 release.
Anything that starts with 2 underscores is OK.
Where can I find instructions for checking out the repository?
https://sourceforge.net/p/mingw/mingw-org-wsl/ci/master/tree/
So, your own project is fundamentally broken, (because you implement your own replacements for standard POSIX functions, and you neglect to sequester them in your own private (pseudo) namespace). This is your bug, yet you expect us to facilitate a kludge for you, by moving our system core implementation of a POSIX compatibility API, into some other arbitrary namespace? Hardly seems like a solid justification, IMO.
That said, I guess the fact that this is Windows, which does not support POSIX features as standard, may provide some minimal justification for your request. With that in mind, perhaps it wouldn't be too difficult to adopt something like (untested, patch attached):
However, that alone would not suffice; we would still need to add stubs to libmingwex.a, based on something like (again, untested):
to ensure that we furnish public symbols, as equivalent entry points, for each of those functions we've now redirected inline.
Last edit: Keith Marshall 2013-10-10
Since MinGW is not a Posix environment, applications do not need to stay away of identifiers that are reserved only by Posix.
Even if MinGW was a Posix environment, it should have supported a compile-time way to turn off Posix, e.g., "gcc -ansi", which defines
__STRICT_ANSI__
. However, if the startup code unconditionally calls Posix functions, users won't be able to turn that off, there's no fire escape such as not including the header which declares the functions etc.So no, I don't agree that this is a bug in my project (which is GNU Emacs, btw). I think that a runtime system should always refrain from pushing non-standard identifiers into an application, except if the programmer explicitly asks for that, e.g., by calling a function or including a header that declares it.
Thanks for the patch. I take it you no longer need me to propose one (I actually thought about something very similar)?
That's why I agreed that there may be some justification for progressing this.
There's no point in getting into an argument about it, but IMO it is a bug in GNU Emacs that you did this. IIRC, when I last used
AC_REPLACE_FUNCS
in one of my own projects, the replacement functions were expected to have a "repl_
" prefix, which kind of suggests that GNU convention recommends this. It's been a while though, and I could be mistaken.I do take on board, however, your point about the conflict of interest with
__STRICT_ANSI__
for example; between us, Earnie and I will progress this, (hopefully in time for 4.1). If you can improve on my proposed patch, please do indicate how; otherwise, we will proceed from this base.The patch looks OK to me, thanks. One question: will that
_CRTALIAS
thing allow to take the address of opendir, readdir, etc.? If not, that could be a problem in some programs. I think we had a thread on the MinGW mailing list about a similar issue (with another function, IIRC).No, it won't. That's why I noted the additional need to generate the (12 in this case) stubs, based on my jmpstub.sx offering.
BTW, my patch isn't entirely okay, as it stands; I found three typos, when I applied it in my own sandbox. Earnie, would you like me to progress this, or do you want an updated patch?
BTW Earnie, whatever happened to "
_CRTALIAS
should become__CRT_ALIAS
"?Just haven't had the round tuit yet. I remember everytime I see it in a header, it will probably be near the end of 4.1-dev before I get to it. The same is true for [BEGIN|END]_C_DECLS.
I'm not Earnie, but... If you mean the double underscore, then that is not required: symbols that begin with an underscore and a capital letter are always reserved for the implementation.
Apologies if you meant something else.
No problem. I did mean something else: a prior discussion where we had agreed that
_CRTALIAS
should become__CRT_ALIAS
-- Earnie's suggestion BTW -- for stylistic consistency with similar names such as__CRT_INLINE
. Of course, changing this one then begs the question: should the likes of_CRTIMP
not also be similarly changed? Maybe a lot of effort, for negligible reward?Last edit: Keith Marshall 2013-10-11
Diff:
Please proceed Keith. 4.1-dev should build as of my last commit and push; I'll try to keep it doing that before pushing again.
It didn't for me, following a pull last night; see [#2100] for explanation.
Related
Issues: #2100
[#2106] should also be addressed, in conjunction with this issue.
Related
Issues: #2106
No, [#2106] will be addressed as a point release of 4.0 while this one will wait for 4.1.
Related
Issues: #2106
As you wish. I've already given you a patch for [#2106], and I also have a working implementation for this. Just one issue with it -- where should I put
jmpstub.sx
? Although I'm currently using it only for this specific case, (which would suggestsrc/libcrt/tchar
), it's actually completely generic. We may well use it to implement physically addressable entry points for any number of other_CRTALIAS
(or__CRT_ALIAS
) functions, in which case a more general location would be better;src
,misc/src
,src/libcrt
, (although it's potentially more general than exclusive to the scope oflibcrt
); somewhere else? Where would you prefer?Related
Issues: #2106
I think src/libcrt/misc is a good fit for that.
I can certainly put it there. Its scope could be broader than just libcrt; do you consider it unlikely that we might use in a broader context?
Let me soak on it a bit. I'll get back to you within the next 12 hours. Maybe creating src/misc is a better fit. The misc/src directory contains code that we're not able to claim as our own.
I'm liking src/misc/ for this code. We can then use it wherever we like.