http://permalink.gmane.org/gmane.comp.gnu.mingw.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39310 <pre> I've now posted a new snapshot, at the same http://tinyurl.com/cgkckca address as previously; it addresses this issue, and also your issue #2, which was effectively just another symptom of the same problem. Please test. The solution I've adopted for #1 and #2 also suggested a solution for this; the new implementation also preserves the dirname separator style of the original pattern, (as best it practically can). A further change, which I've made in this snapshot, is that the glob(3) implementation now matches case-insensitively by default, (except in the case of pattern characters within bracketed groups, which I think should always be matched case-sensitively). To support more POSIX-like case-sensitive globbing, I've introduced a (custom) GLOB_CASEMATCH option, to switch off the case-insensitive matching feature; this may be activated for the command line parse, by the boolean addition of 0x40 to _CRT_glob, although I suspect that the case-insensitive default mode will create fewer surprises for user</pre> Keith Marshall 2012-05-16T21:50:32 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39309 <pre>All, here is a summary of work that Pierre Martin and I did to establish a working prototype that will allow multiple instantiations of a class exported from a DLL. Some portion of this was visible on the list, and some was not. The fundamental factory function method for accessing the class is maintained. Pierre established that this still needs to be accompanied by dllexport/dllimport qualifications for the abstract interface class, the main class to be exported, and the factory functions themselves. My fixed-up demo, cut even more to the bare bones than my original post, is included in the message text below so as to have the final result archived in a convenient place. I apologize for the length of the message caused by this. Pierre's original fixed-up version at pastebin.com may remain for some time and it works just as well. We have tested this strategy with MinGW 4.4.0 as well as another recent development version. The code can be used essentially unchanged in VC++6 as well (and thus probably</pre> Hans-Jochen Trost 2012-05-16T20:18:40 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39308 <pre> Did that now and didn't find any problems. Both \\server\share and //server/share are supported, as I'd expect. ------------------------------------------------------------------------------ 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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org 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</pre> Eli Zaretskii 2012-05-16T15:11:43 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39307 <pre>Quite possibly, but at the cost of one extra wild card, making the line in question match the others, it and and other crazy names, can be supported in the ./configure file though. On 16/05/12 15:54, Teemu Nätkinniemi wrote: ------------------------------------------------------------------------------ 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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org 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</pre> Joe Burmeister 2012-05-16T15:06:59 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39306 <pre> Whoever is releasing Ubuntu's cross-compiler should really migrate away from i586-mingw32msvc naming. I haven't seen that in years and it really should be deprecated. ------------------------------------------------------------------------------ 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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org 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://li</pre> Teemu Nätkinniemi 2012-05-16T14:54:15 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39305 <pre> Hi guys, Anyone else noticed this very minor build bug with make's configure: https://sourceforge.net/tracker/?func=detail&amp;atid=202435&amp;aid=3523436&amp;group_id=2435 &lt;https://sourceforge.net/tracker/?func=detail&amp;atid=202435&amp;aid=3523436&amp;group_id=2435&gt; I don't agree with the response: This is a user error in specifying the host for which the package is to be residing for. You should specify --host=mingw32 to resolve this issue. There is no such system as mingw32msvc. This doesn't fit with what I'm seeing, see below. Even if you use "--host=mingw32" you see the same problem as with "--host=i586-mingw32" below. Only "--host=i586-mingw32msvc" builds and only if you do that one character fix to make the offending line match the wild cards of other parts that also refer to mingw32. The name must match what the mingw executables are called, and for me at least, that's "i586-mingw32msvc". Joe -------- Original Message -------- Subject: Re: make bug 3523436 Date: Wed, 16 May 2012 07:16:56</pre> Joe Burmeister 2012-05-16T14:40:52 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39304 <pre> I don't think fmifs.dll implements tolower(), and, from new test results below, I don't think we switch to a different version of the C runtime library. But that was a good guess, and it gave me some more insight as to what might be happening. As per [1], we know that fmifs's DllMain() is going to be called on LoadLibrary(), and it seems to do something else that messes up the locale, which causes tolower() to behave differently. For instance, if it sets the locale to a codepage, such as cp850 where 0xE9 is capital U acute ('Ú'), tolower() will try to convert it to lowercase U acute ('ú'), and this is in effect what we seem to be observing on en_IE systems, as this is 0xA3 in cp850. On the other hand, it seems that, for en_US, cp437 is being used, with 0xE9 being the capital greek letter theta ('Θ') but since no lowercase theta ('θ') seems to be available in cp437, tolower() appears to fall back to '?' (which I would say is a bug of tolower() as the manpage says it should not translate the</pre> Pete Batard 2012-05-16T10:09:08 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39303 <pre>[...last quoted line doesn't always print 0xe9 as it should...] Might that dll use a different version of the C runtime library, or even implement its own tolower()? Just wild guesses... ------------------------------------------------------------------------------ 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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org 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 </pre> Greg Chicares 2012-05-16T00:13:43 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39302 <pre> Interesting. I just tested a 4th machine with XP installed and an "English (Ireland)" locale, and still observed the same results as with 7 (second output = 0xa3). And in the virtual XP mode of Windows 7, when running the same program, I got 0x3f. Thus I would think the problem will also manifest itself with XP, as long as a western locale is in use. What I suspect, that would explain your results, is that the second tolower() call is dependent on the system locale/codepage for lowercase conversion, and AFAIK (correct me if I'm wrong) there's no lowercase conversion for Chinese characters. So that might explain why an 0xe9, in a Chinese codepage would still be left unchanged. Regards, /Pete ------------------------------------------------------------------------------ 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</pre> Pete Batard 2012-05-16T00:07:54 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39301 <pre> Under my English Windows XP SP3 with Chinese Locale (Language for Non-Unicode Program set to Chinese). 1) Build with MinGW gcc 4.6.2 mcuee&lt; at &gt;dellxp /c/work/mingw/test $ ./test1_mingw32.exe tolower(0xe9) = 0xe9 tolower(0xe9) = 0xe9 2) Build with TDM64 (MinGW-w64 4.6.1), adding "-m32" to build 32bit binary mcuee&lt; at &gt;dellxp /c/work/mingw/test $ ./test1_tdm64_win32.exe tolower(0xe9) = 0xe9 tolower(0xe9) = 0xe9 </pre> Xiaofan Chen 2012-05-15T23:29:43 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39300 <pre>Hi, I'm experiencing what I can only qualify as a very weird issue with MinGW32 (gcc 4.6.2) and MinGW-w64 (gcc 4.6.1/tdm64-1), when running the simple program below: ----------------------------------------------------------------------- #include &lt;windows.h&gt; #include &lt;stdio.h&gt; #include &lt;ctype.h&gt; int main(int argc, char** argv) { int c = 0xe9; HMODULE h; printf("tolower(0x%02x) = 0x%02x\n", c, tolower(c)); h = LoadLibraryA("fmifs.dll"); printf("tolower(0x%02x) = 0x%02x\n", c, tolower(c)); return 0; } ----------------------------------------------------------------------- The output from this program is as follows: o On Windows 7 x64 with an English/Ireland locale, and when compiled with either MinGW32 or MinGW-w64: tolower(0xe9) = 0xe9 tolower(0xe9) = 0xa3 o On Windows 7 x86 with an English/US locale, when compiled with MinGW32: tolower(0xe9) = 0xe9 tolower(0xe9) = 0x3f Obviously, the expectation is for tolower() to produce the same output regardless of the call to </pre> Pete Batard 2012-05-15T23:15:03 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39299 <pre> Good catch. Thanks for testing. Hmm. Actually no, it doesn't... It should have matched 3, 4, (and I guess 9, which isn't a match at present, because I've neglected to compare case-insensitively); none of the others should match. I'll need to investigate further, but I suspect I've overlooked an anomaly in the way dirname(3) reports the directory when it resolves to exactly the root of an absolute path; in this case alone, it doesn't drop the slash, but I've blindly tacked one on anyway, overwriting the first character of the basename in the process, and so losing the first character of the globbing pattern to that extra slash. That's the result of recursively extracting dirname(3) results, until no globbing tokens remain in the prefix, then adding back the globbed basename, with / as separator, as each level of recursion is unwound. It's easy to choose either / or \ unconditionally, at this point; more difficult, (although maybe only slightly so, and certainly not impossible), to preserve the orig</pre> Keith Marshall 2012-05-15T23:08:42 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39298 <pre> No. ------------------------------------------------------------------------------ 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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org 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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org?subject=unsubscribe </pre> Eli Zaretskii 2012-05-15T17:18:56 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39297 <pre>Eli Zaretskii schreef, Op 15-5-2012 17:47: Did you test network drive paths like "\\server\share\pr*" ? </pre> Erwin Waterlander 2012-05-15T17:13:50 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39296 <pre> Gave this a test ride on Windows 7, and here's my report: Summary: looks very good; encountered a couple of minor issues. Details: In general, the new start-up globbing performs very well, producing expected results. I used a simple program that displays the original command line and its expansion in argv[] (its source is shown in the thread that led to bug 3482704). Here are a few "issues" I found, in the order of decreasing importance: 1. There seem to be problems in expanding wildcards in the root directory. For example, this works: d:\usr\eli&gt;showargs C:/P*s cmd: `showargs C:/P*s' 0: `showargs 1: `C://Docs' 2: `C://Documents and Settings' 3: `C://PerfLogs' 4: `C://Program Files' 5: `C://Users' 6: `C://Windows' 7: `C://hiberfil.sys' 8: `C://mvfslogs' 9: `C://pagefile.sys' but these don't: d:\usr\eli&gt;showargs C:/Pr*s cmd: `showargs C:/Pr*s' 0: `showargs' 1: `C:/Pr*s' d:\usr\eli&gt;showargs C:/*s cmd: </pre> Eli Zaretskii 2012-05-15T15:47:21 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39295 <pre>Dear Hans, Please see the following code and comments. TestInterface.h: http://pastebin.com/bUy9GLiV - There was no declspec specifiers. i added them, see line #5 to #9. - Notice the import / export preprocessor definitions. When compiling the library, you will have to define TestLibOpt, so the variable DECLSPEC will be set to the right value. But when compiling the executable which will load it, you have to *not* have the TestLibOpt defined. - i also added a constructor to your TestInterface. TestInterface.cpp: http://pastebin.com/7WZTg5hG - i have simplified the logging function. - Now, also notice the DECLSPEC preceding your Test class declaration (Line 24). - Also, you have to not forget initializing the TestInterface parent object in Test's constructor (See line #38). main.cpp: http://pastebin.com/05eeCnF3 - Nothing much here excepted the zeromems and the while(1) / breaks instead of the gotos. Tell me if it works for you now. Pierre. ------------------------------------------------------------</pre> MARTIN Pierre 2012-05-14T21:22:47 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39294 <pre> Exactly. OTOH, there's no rush ;-) My report about testing the new startup code comes up shortly... Thanks. ------------------------------------------------------------------------------ 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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org 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:m</pre> Eli Zaretskii 2012-05-15T02:54:14 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39293 <pre> That seems a reasonable idea, but will GLOB_NOESCAPE alone suffice? In a purely POSIX context, GLOB_NOESCAPE instructs glob(3) to read \ as a literal, rather than as an escape, and my initial thought was that we would need a separate (custom) flag to turn on its dirsep property for the windows context. On further reflection, that may be over-thinking the issue, since what else could a literal \ mean, other than a dirsep, in a context where a windows path name pattern is expected? That aside, making this change will require some reworking of my current glob(3) implementation:-- * Cannot use our existing dirname(3) implementation, which interprets / and \ interchangeably as dirseps; I'll need to add an alternative static implementation, which can discriminate their intent, based on the state of GLOB_NOESCAPE. * Other internal checks for dirseps will need to similarly discriminate the intent of / and \, based on a runtime decision regarding \. </pre> Keith Marshall 2012-05-14T22:11:34 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39292 <pre>Pierre, thanks for your willingness to help and for the feedback. I have to plead guolty onthis one. Somehow my colleague and I (we're a two-part-timer software development department at our company) have developed the habit of not attaching the &lt; at &gt;&lt;n&gt; to the name in the module definition file (testdll.def). Linking inside Eclipse bails us out here by picking up the right names. I have been doing this sprintf(s, "Got bb=%s, ii=%d.", bb ? "true" : "false", ii) ; without problems for ages. BC++5, BCB4, BCB5, BCB2007, VC++6, MinGW under Eclipse are all playing along with it. However, this would be an unimportant side item if it is a separate problem. This may depend on the history of the memory before the program starts. Inside Eclipse, I usually run with the debugger. Without it, I get a slightly different result from with it. With what you see you do indeed have the clear symptom of the problem I am asking about. Part of the purpose of writing bb and ii to the log file is to catch such </pre> Hans-Jochen Trost 2012-05-14T21:31:05 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39291 <pre>Dear Hans, dear list readers, i noticed that your library-exported class uses __stdcall for all it's methods. i'm not sure, and i would like confirmation from people here, but it requires at least __thiscall. i have removed all the __stdcall from class methods, and have recompiled the library. Also, i have remodeled a bit the code because i wasn't able to read it. Now everything works, i would like to upload it somewhere but i have no idea where... So please tell me if you would like me to send it to you as private message so you can then post it somewhere as an archive. Pierre. ------------------------------------------------------------------------------ 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/ __________________________________</pre> MARTIN Pierre 2012-05-14T20:39:31 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/39290 <pre>Dear Hans, dear users, i began re-writing part of your code, and i just figured something out. When iterating thru the main loop, numinstance sometimes changes. For instance, i just entered 10 as numinstances, and the loop exits after only two, meaning that something modified numinstance from outside the loop. A step-by-step debugging confirmed that, it changed from 10 to 1 after the 2nd iteration. This only happenned after i rewrote part of the code, and what has mainly changed is the order i declared the variables (So numinstances now gets modified from outside instead of something else which was previously on the stack). This is typical of some kind of unexpected memory boundaries access and should be checked within each function / method from the DLL that receives references / pointers. i'll continue a little bit later. Pierre. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security</pre> MARTIN Pierre 2012-05-14T20:24:20 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.gnu.mingw.user