Globbing startup code and the global namespace of MinGW programs

The new startup code in the snapshot of MinGW runtime 3.21 uses 'glob'
to expand wildcards in the command-line arguments.  The immediate side
effect of this is that every MinGW program has 'glob' pulled into it.
If a MinGW programs includes a different implementation of 'glob', it
might now be in trouble.

A case in point is the MinGW build of GNU Make.  It brings with it the
GNU implementation of 'glob', and compiles it into make.exe.  The
result is that the MinGW startup code uses the GNU implementation of
'glob', and so make.exe globs its command-line argument in a
non-default fashion (in particular, backslashes are not supported as
directory separators).

One could make a point that a program should probe the runtime and use
the library implementation of 'glob' if it exists.  That might be true
in an ideal world, but is tricky in practice, since MinGW didn't have
'glob' until now, and thus we can expect packages to assume that, and
bring 'glob' from elsewhere.  Specifically for Make, (a) the official
way of building it natively with MinGW is by running a batch file that
doesn't probe the runtime at all, and (b) even if you do run the
configure script, it decides not to use the library implementation,
because (for some reason) it insists on GNU 'glob', and thus requires
in its test program the headers features.h and fnmatch.h which MinGW
doesn't have.

A similar problem happens with 'opendir', 'readdir', etc. that 'glob'
uses.  In fact, the problem here is even more serious, since v3.21
changes the layout of 'struct dirent' in an incompatible fashion.  The
result was that command-line wildcard expansion in Emacs became
broken, because (gasp!) Emacs has its own replacements for these
functions (to support MSVC builds, among other reasons), and the layout
of 'struct dirent' used by the replacements is, of course, identical to
what MinGW used up to now.

So my suggestion would be twofold:

 . Have the implementation of 'glob', 'opendir', etc. reside in
   internal functions named, say, '__glob', '__opendir', etc., or some
   such, and call that internal name in the startup code.  'glob' will
   then call '__glob' as well.  This should allow applications to have
   their own namesakes where they need them, without interfering with
   startup code.

 . Consider again the decision to break binary compatibility in dirent
   functions.  I'm afraid this could cause numerous subtle bugs,
   e.g. when a library or DLL compiled with previous MinGW version is
   linked with a program compiled by the new MinGW headers.  I
   understand the rationale for the changes (having glanced at the
   code) and the improvements they bring, but if I'm right in my
   assessment of the resulting incompatibilities, I'm afraid that the
   damage will be by far more serious than the benefits.  (That's
   assuming that a solution cannot be found that keeps binary
   compatibility with previously compiled libraries; if such a
   solution exists, then it will allow us to have the best of both
   worlds.)

TIA

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@...?subject=unsubscribe