From: Roumen P. <bug...@ro...> - 2008-09-14 21:49:01
|
First link "HOWTO Submit Bug Reports for MinGW Defects" on page http://mingw.sourceforge.net/wiki/HOWTO point to non existing page. Also I can't post to new tracker2 "http://sourceforge.net/tracker2/?group_id=2435&atid=102435". If this is correct link to post bugs I get same message as was reported in the list : "Permission: User Not Found: Only members of this project have permission to view this page (you are not listed as a member of this project).". A link on top of the page in "LogOut". I would like to ask help/report about some issues: 1) Please find attached file "strtod-tests.tgz" with: - test-strtod.c : test C-program; - strtod-gcc.log : linux output; - strtod-mingwex-3.15.log : mingw output, emulated environment, linked with mingwex library from runtime 3.15; - strtod-mingwex.log - previous version(3.14), native output. Function strtod may be is correct now - the number of tested items is too short. The test show that function atof work fine and may be mingwex library has to be replace it too. What about printf output ? Is it correct ? 2) The next issue (sorry that I post in same email) is about definition of mingw runtime version. It is defined in _mingw.h as : "#define __MINGW32_VERSION 3.15". Note the dot in the string. This definition don't allow to use in code #if __MINGW32_VERSION > xxxx. What about to define it as example to 0x030F ? Also I prefer to use common syntax ("#if __MINGW32_VERSION > xxxx") instead that I see in same file for gnu compiler version "#if __MINGW_GNUC_PREREQ (3, 0)" . I wonder where such definition(__MINGW32_VERSION) is used. It can't be a #if statement. If it is a function like prinf the code can be replaced by: "...%d.%d " , ... __MINGW32_MAJOR_VERSION, __MINGW32_MINOR_VERSION ... what is backward compatible. I found one place where the current definition is used - configure script, but the autoconf script is buggy: $ ./configure --help `configure' configures mingw-runtime __MINGW32_VERSION to adapt to many kinds of systems. The macro MINGW_AC_CONFIG_SRCDIR is not enough. I would like to check for working strtod in a configure script. Since I would like to check in cross-compilation environment too I think that check for version is enough. 3) Next issue is same as 2) but is for w32api package. Same issue for the definition from include/w32api.h:"#define __W32API_VERSION 3.11" As example xmlsec project (see file src/mscrypto/xmlsec-mingw.h) contain missing form w32aip definitions and structures . I would like to include in #if statements, but now without to do checks by configure script. Roumen |
From: Roumen P. <bug...@ro...> - 2008-09-14 22:05:02
Attachments:
strtod-tests.tgz
|
Roumen Petrov wrote: [SNIP] > 1) > Please find attached file "strtod-tests.tgz" with: [SNIP] Now attached Roumen |
From: Greg C. <gch...@sb...> - 2008-09-14 22:17:39
|
On 2008-09-14 21:48Z, Roumen Petrov wrote: > > The next issue (sorry that I post in same email) is about definition of > mingw runtime version. > It is defined in _mingw.h as : "#define __MINGW32_VERSION > 3.15". Note the dot in the string. This definition don't allow to use in > code #if __MINGW32_VERSION > xxxx. > What about to define it as example to 0x030F ? Some programs may rely on its present style; changing it now would break backward compatibility. In my own code, I define a macro like this: #define MY_MINGW_VERSION (__MINGW32_MAJOR_VERSION * 100 + __MINGW32_MINOR_VERSION) and then I can write, e.g.: #if 308 <= MY_MINGW_VERSION # define COMPILER_PROVIDES_EXPM1L #endif // 308 <= MY_MINGW_VERSION |
From: Keith M. <kei...@us...> - 2008-09-15 00:49:58
|
On Sunday 14 September 2008 22:48:53 Roumen Petrov wrote: > First link "HOWTO Submit Bug Reports for MinGW Defects" on page > http://mingw.sourceforge.net/wiki/HOWTO point to non existing page. So, that page has not yet been migrated from the old to the new wiki; either follow the advice on the home page, to refer to the old wiki, when you can't find the content on the new, or better still, join in and help with the migration. > Also I can't post to new tracker2 > "http://sourceforge.net/tracker2/?group_id=2435&atid=102435". Where did that link come from? The project page still refers me to https://sourceforge.net/tracker/?group_id=2435&atid=102435 (note *not* tracker2). > If this is correct link to post bugs I get same message as was > reported in the list : "Permission: User Not Found: Only members of > this project have permission to view this page (you are not listed > as a member of this project).". A link on top of the page in > "LogOut". > I would like to ask help/report about some issues: > > 1) > Please find attached file "strtod-tests.tgz" with: > - test-strtod.c : test C-program; > - strtod-gcc.log : linux output; If that's what you see on GNU/Linux, then your glibc has a seriously defective strtod() implementation. > - strtod-mingwex-3.15.log : mingw output, emulated environment, > linked with mingwex library from runtime 3.15; > - strtod-mingwex.log - previous version(3.14), native output. Check the ChangeLog; you should see that strtod() has been made C99 compliant in 3.15, where it wasn't in 3.14; this output looks fine to me. > Function strtod may be is correct now I think so. > - the number of tested items is too short. > The test show that function atof work fine and may be mingwex > library has to be replace it too. Maybe. The standard would suggest that it should return the same as strtod(), with a NULL pointer passed as second argument. > What about printf output ? Is it correct ? Yes, for the MSVCRT implementation. Try compiling your test case with -ansi, and see the difference, (with 3.15). > 2) > The next issue (sorry that I post in same email) is about > definition of mingw runtime version. > It is defined in _mingw.h as : "#define __MINGW32_VERSION > 3.15". Note the dot in the string. This definition don't allow to > use in code #if __MINGW32_VERSION > xxxx. > What about to define it as example to 0x030F ? > > Also I prefer to use common syntax ("#if __MINGW32_VERSION > xxxx") > instead that I see in same file for gnu compiler version "#if > __MINGW_GNUC_PREREQ (3, 0)" . > I wonder where such definition(__MINGW32_VERSION) is used. It can't > be a #if statement. If it is a function like prinf the code can be > replaced by: "...%d.%d " , ... __MINGW32_MAJOR_VERSION, > __MINGW32_MINOR_VERSION ... what is backward compatible. And by the same token, you can just as well test the MAJOR and MINOR versions, perhaps combining them, as Greg suggests. > I found one place where the current definition is used - configure > script, but the autoconf script is buggy: > $ ./configure --help > `configure' configures mingw-runtime __MINGW32_VERSION to adapt to > many kinds of systems. > The macro MINGW_AC_CONFIG_SRCDIR is not enough. Well, *I* wrote that macro, and I resent you glibly calling it buggy, without offering any alternative; it does what it says on the tin, and it is *your* expectations which are buggy. (FWIW, I wrote the macro to use the format the package maintainer had already chosen for the definition of __MINGW32_VERSION; I could have worked with either format, and chose not to demand that the maintainer change it. If there is a bug, it is possible that the PACKAGE_VERSION should not be incorporated into PACKAGE_TARNAME). > I would like to check for working strtod in a configure script. > Since I would like to check in cross-compilation environment too I > think that check for version is enough. Well, such usage really *is* buggy -- you should test for feature support, *not* for versions, (although I accept that in a cross compile environment, a version test may be better than nothing, when you need a run test, to check the feature). Regards, Keith. |
From: Roumen P. <bug...@ro...> - 2008-09-15 14:40:19
|
Also I miss to add w32api to the subject. Please, see my comments in quoted test. Keith Marshall wrote: > On Sunday 14 September 2008 22:48:53 Roumen Petrov wrote: >> First link "HOWTO Submit Bug Reports for MinGW Defects" on page >> http://mingw.sourceforge.net/wiki/HOWTO point to non existing page. > > So, that page has not yet been migrated from the old to the new wiki; > either follow the advice on the home page, to refer to the old wiki, > when you can't find the content on the new, or better still, join in > and help with the migration. > >> Also I can't post to new tracker2 >> "http://sourceforge.net/tracker2/?group_id=2435&atid=102435". > > Where did that link come from? The project page still refers me to > https://sourceforge.net/tracker/?group_id=2435&atid=102435 (note > *not* tracker2). Dunno whats happen. Yesterday I just follow links from old wiki and I get a message that page will be redirected. Today I can't reproduce I will tray later with some other issues. >> If this is correct link to post bugs I get same message as was >> reported in the list : "Permission: User Not Found: Only members of >> this project have permission to view this page (you are not listed >> as a member of this project).". A link on top of the page in >> "LogOut". > >> I would like to ask help/report about some issues: >> >> 1) >> Please find attached file "strtod-tests.tgz" with: >> - test-strtod.c : test C-program; >> - strtod-gcc.log : linux output; > > If that's what you see on GNU/Linux, then your glibc has a seriously > defective strtod() implementation. May be is broken, but it pass all python tests, this include "float", "math" and "cmath"(complex). Also native windows build (version 2.6b3, distributed with msvcr90), pass all tests even in emulated environment! >> - strtod-mingwex-3.15.log : mingw output, emulated environment, >> linked with mingwex library from runtime 3.15; >> - strtod-mingwex.log - previous version(3.14), native output. > > Check the ChangeLog; you should see that strtod() has been made C99 > compliant in 3.15, where it wasn't in 3.14; this output looks fine to > me. I know this. >> Function strtod may be is correct now > > I think so. Today I spend time to test python against mingw runtime 3.15 and win32 api 3.12. The results is much better - "float" test is passed. For the protocol the python patch is posted in issue 3871: http://bugs.python.org/issue3871 . So according the "float" and "math" tests strtod is fine for python if we link with mingwex. A mysterious issue is in "math" test. The python function ldexp(1, 10*10) don't raise exception if is called in the test script. If is called in separate python program it's work fine. Please don't reply to this issue in this mail thread. I will open another one later. >> - the number of tested items is too short. >> The test show that function atof work fine and may be mingwex >> library has to be replace it too. > > Maybe. The standard would suggest that it should return the same as > strtod(), with a NULL pointer passed as second argument. > >> What about printf output ? Is it correct ? > > Yes, for the MSVCRT implementation. Try compiling your test case > with -ansi, and see the difference, (with 3.15). According python tests cases {v}snprintf from mingwex is fine. >> 2) >> The next issue (sorry that I post in same email) is about >> definition of mingw runtime version. >> It is defined in _mingw.h as : "#define __MINGW32_VERSION >> 3.15". Note the dot in the string. This definition don't allow to >> use in code #if __MINGW32_VERSION > xxxx. >> What about to define it as example to 0x030F ? >> >> Also I prefer to use common syntax ("#if __MINGW32_VERSION > xxxx") >> instead that I see in same file for gnu compiler version "#if >> __MINGW_GNUC_PREREQ (3, 0)" . >> I wonder where such definition(__MINGW32_VERSION) is used. It can't >> be a #if statement. If it is a function like prinf the code can be >> replaced by: "...%d.%d " , ... __MINGW32_MAJOR_VERSION, >> __MINGW32_MINOR_VERSION ... what is backward compatible. > > And by the same token, you can just as well test the MAJOR and MINOR > versions, perhaps combining them, as Greg suggests. Multiplication is so fast operation. What about a definition like this one: ((__W32API_MAJOR_VERSION << 8) | __W32API_MINOR_VERSION ) Also similar with __MINGW32_XXX_VERSION. About the name I prefer this definition to replace existing one : __W32API_VERSION and __MINGW32_VERSION. I don't think that new format(hex-format) will impact legacy applications. We can't use old format in #if statement. If the current version format was string may be proposed change will break legacy applications. Since the current version format is numeric I don't expect impacts. As I point (see quoted text above) legacy application (if exist) may use format specifier like this one "...%d.%d.." and to pass __MINGW32_MAJOR_VERSION and __MINGW32_MINOR_VERSION. If the final decision as result of this discussion is don't change existing one and to add a new definition I will accept too. For the name of new definition I would like to propose __W32API_VERSION_HEX and __MINGW32_VERSION_HEX respective. >> I found one place where the current definition is used - configure >> script, but the autoconf script is buggy: >> $ ./configure --help >> `configure' configures mingw-runtime __MINGW32_VERSION to adapt to >> many kinds of systems. >> The macro MINGW_AC_CONFIG_SRCDIR is not enough. > > Well, *I* wrote that macro, and I resent you glibly calling it buggy, > without offering any alternative; it does what it says on the tin, and > it is *your* expectations which are buggy. (FWIW, I wrote the macro > to use the format the package maintainer had already chosen for the > definition of __MINGW32_VERSION; I could have worked with either > format, and chose not to demand that the maintainer change it. If > there is a bug, it is possible that the PACKAGE_VERSION should not be > incorporated into PACKAGE_TARNAME). Ok. The bug is that you try to replace internal autoconf variables, but the second argument of AC_INIT is cached and used later. The command "grep __MINGW32_VERSION configure" show this. You may use m4_define([__MINGW32_VERSION], [...]) but before AC_INIT. >> I would like to check for working strtod in a configure script. >> Since I would like to check in cross-compilation environment too I >> think that check for version is enough. > > Well, such usage really *is* buggy -- you should test for feature > support, *not* for versions, (although I accept that in a cross > compile environment, a version test may be better than nothing, when > you need a run test, to check the feature). Yes the issue is from cross-compilation environment where configure script can't run test program. Also check for feature will overload configure script especially if is related to mingw wincrypt.h header. I will address wincrypt.h header further. For now I would like to get only the name of the macros that we could use in #if statement. > Regards, > Keith. Roumen |
From: Keith M. <kei...@us...> - 2008-09-15 17:53:40
|
On Monday 15 September 2008 22:40:14 Roumen Petrov wrote: > > If that's what you see on GNU/Linux, then your glibc has a > > seriously defective strtod() implementation. > > May be is broken, but it pass all python tests, Really? Then the python tests aren't much cop, if x=%.17g (strtod) is the expected output, in every case, for that's what appears throughout the strtod-gcc.log file you attached. > >> What about printf output ? Is it correct ? > > > > Yes, for the MSVCRT implementation. Try compiling your test case > > with -ansi, and see the difference, (with 3.15). > > According python tests cases {v}snprintf from mingwex is fine. And, for mingwrt-3.15, if you compile with -ansi, or -posix, or any of the defines mentioned in the release notes, this should also extend to {,f,s,v,vf,vs}printf() too. > > And by the same token, you can just as well test the MAJOR and > > MINOR versions, perhaps combining them, as Greg suggests. > > Multiplication is so fast operation. We are talking about a compile time operation, which might be done once or twice in a build cycle, so I would suggest that the overhead wouldn't be worth worrying about. > What about a definition like this one: > ((__W32API_MAJOR_VERSION << 8) | __W32API_MINOR_VERSION ) Well yes, that might have been my choice too; the point was that you can combine these two in a manner which facilitates a convenient check for a minimum version number, *if* you need such a check, (and you really should not be relying on this extensively). > If the final decision as result of this discussion is don't change > existing one and to add a new definition I will accept too. You are free to add whatever extra definitions you wish, in your own code; I see no pressing need for any more than the system headers provide at present. Ultimately, it is down to Chris' discretion, whether he wishes to pander to your whim, or not; IMO, it isn't necessary for him to do anything. > >> ... the autoconf script is buggy: > >> $ ./configure --help > >> `configure' configures mingw-runtime __MINGW32_VERSION to adapt > >> to many kinds of systems. > >> The macro MINGW_AC_CONFIG_SRCDIR is not enough. > > > > Well, *I* wrote that macro, and I resent you glibly calling it > > buggy, without offering any alternative; it does what it says on > > the tin, and it is *your* expectations which are buggy. (FWIW, I > > wrote the macro to use the format the package maintainer had > > already chosen for the definition of __MINGW32_VERSION; I could > > have worked with either format, and chose not to demand that the > > maintainer change it. If there is a bug, it is possible that the > > PACKAGE_VERSION should not be incorporated into PACKAGE_TARNAME). > > Ok. The bug is that you try to replace internal autoconf variables, No, I don't; I replace only public variables... > but the second argument of AC_INIT is cached It isn't, in the strict sense of autoconf caching, but it is used at other places within the configure script, than simply to assign a value to $PACKAGE_VERSION. The effect is benign, but I take your point -- it may not be particularly desirable. I'll discuss this with Chris, and we'll agree how to improve the aesthetics, if at all, possibly for the next release. > For now I would like to get only the name of the macros that we > could use in #if statement. They are __MINGW32_MAJOR_VERSION and __MINGW32_MINOR_VERSION for mingwrt; __W32API_MAJOR_VERSION and __W32API_MINOR_VERSION for w32api. You can depend on nothing else, unless you wish to make your own software depend on some future, unknown versions of these two, which may or may not be released at some time beyond your control. Regards, Keith. |
From: Roumen P. <bug...@ro...> - 2008-09-20 22:01:30
|
Keith Marshall wrote: > On Monday 15 September 2008 22:40:14 Roumen Petrov wrote: >>> If that's what you see on GNU/Linux, then your glibc has a >>> seriously defective strtod() implementation. >> May be is broken, but it pass all python tests, > > Really? Then the python tests aren't much cop, if > > x=%.17g (strtod) > > is the expected output, in every case, for that's what appears > throughout the strtod-gcc.log file you attached. It was a broken file included in archive before to fix bug in code (s/%%.17g/%.17g/). The archive contain correct code, but old output. Anyway I will not post new file. Both functions (strtod and atof) output same. With new mingw runtime(3.15) (if posix is defined) stdout is same. Only atof return 0 for {+/-}{nan|inf|infinity}. >>>> What about printf output ? Is it correct ? >>> Yes, for the MSVCRT implementation. Try compiling your test case >>> with -ansi, and see the difference, (with 3.15). >> According python tests cases {v}snprintf from mingwex is fine. > > And, for mingwrt-3.15, if you compile with -ansi, or -posix, or any of > the defines mentioned in the release notes, this should also extend > to {,f,s,v,vf,vs}printf() too. Yes, python define _GNU_SOURCE, so mingw port will use "ANSI STDIO". >>> And by the same token, you can just as well test the MAJOR and >>> MINOR versions, perhaps combining them, as Greg suggests. >> Multiplication is so fast operation. > > We are talking about a compile time operation, which might be done > once or twice in a build cycle, so I would suggest that the overhead > wouldn't be worth worrying about. > >> What about a definition like this one: >> ((__W32API_MAJOR_VERSION << 8) | __W32API_MINOR_VERSION ) > > Well yes, that might have been my choice too; the point was that you > can combine these two in a manner which facilitates a convenient > check for a minimum version number, *if* you need such a check, (and > you really should not be relying on this extensively). > >> If the final decision as result of this discussion is don't change >> existing one and to add a new definition I will accept too. > > You are free to add whatever extra definitions you wish, in your own > code; I see no pressing need for any more than the system headers > provide at present. Ultimately, it is down to Chris' discretion, > whether he wishes to pander to your whim, or not; IMO, it isn't > necessary for him to do anything. > [SNIP] >> For now I would like to get only the name of the macros that we >> could use in #if statement. > > They are __MINGW32_MAJOR_VERSION and __MINGW32_MINOR_VERSION for > mingwrt; __W32API_MAJOR_VERSION and __W32API_MINOR_VERSION for > w32api. You can depend on nothing else, unless you wish to make your > own software depend on some future, unknown versions of these two, > which may or may not be released at some time beyond your control. > > Regards, > Keith. I think that a simple macro definition is more readable instead expressions. As example: #if (WINVER >= 0x0500) #if (_WIN32_WINNT >= 0x0501) Roumen P.S.: mail resent |
From: Keith M. <kei...@us...> - 2008-09-20 22:37:43
|
On Saturday 20 September 2008 22:14:59 Roumen Petrov wrote: > >> For now I would like to get only the name of the macros that we > >> could use in #if statement. > > > > They are __MINGW32_MAJOR_VERSION and __MINGW32_MINOR_VERSION for > > mingwrt; __W32API_MAJOR_VERSION and __W32API_MINOR_VERSION for > > w32api. You can depend on nothing else, unless you wish to make > > your own software depend on some future, unknown versions of > > these two, which may or may not be released at some time beyond > > your control. > > > > Regards, > > Keith. > > I think that a simple macro definition is more readable instead > expressions. As example: > #if (WINVER >= 0x0500) > #if (_WIN32_WINNT >= 0x0501) <shrug> It doesn't matter what you think; you've got to work with what you've been given. If you want something else, which will work today, then you have to define it yourself. If you wait for the project's package maintainer to give you what you want, you may have to wait indefinitely. Something of a no-brainer, really. Regards, Keith. |
From: Roumen P. <bug...@ro...> - 2008-09-20 22:01:33
Attachments:
bootstrap.sh
bootstrap.sh.gz
|
Hi Keith, Keith Marshall wrote: > On Sunday 14 September 2008 22:48:53 Roumen Petrov wrote: [SNIP] >> 2) >> The next issue (sorry that I post in same email) is about >> definition of mingw runtime version. >> It is defined in _mingw.h as : "#define __MINGW32_VERSION >> 3.15". Note the dot in the string. This definition don't allow to >> use in code #if __MINGW32_VERSION > xxxx. >> What about to define it as example to 0x030F ? >> >> Also I prefer to use common syntax ("#if __MINGW32_VERSION > xxxx") >> instead that I see in same file for gnu compiler version "#if >> __MINGW_GNUC_PREREQ (3, 0)" . >> I wonder where such definition(__MINGW32_VERSION) is used. It can't >> be a #if statement. If it is a function like prinf the code can be >> replaced by: "...%d.%d " , ... __MINGW32_MAJOR_VERSION, >> __MINGW32_MINOR_VERSION ... what is backward compatible. > > And by the same token, you can just as well test the MAJOR and MINOR > versions, perhaps combining them, as Greg suggests. > >> I found one place where the current definition is used - configure >> script, but the autoconf script is buggy: >> $ ./configure --help >> `configure' configures mingw-runtime __MINGW32_VERSION to adapt to >> many kinds of systems. >> The macro MINGW_AC_CONFIG_SRCDIR is not enough. > > Well, *I* wrote that macro, and I resent you glibly calling it buggy, > without offering any alternative; it does what it says on the tin, and > it is *your* expectations which are buggy. (FWIW, I wrote the macro > to use the format the package maintainer had already chosen for the > definition of __MINGW32_VERSION; I could have worked with either > format, and chose not to demand that the maintainer change it. If > there is a bug, it is possible that the PACKAGE_VERSION should not be > incorporated into PACKAGE_TARNAME). [SNIP] Please find attached file bootstrap.sh (also attached bootstrap.sh.gz is if mail client/server broke plain text). As I wrote in a previous email, you may use m4_define. This shell script create and configure an autoconf demo that set version from a source file, name of the package, etc.. Based on demo you may rewrote configure script do not use MINGW_AC_CONFIG_SRCDIR . Roumen P.S.: resent |
From: Keith M. <kei...@us...> - 2008-09-20 22:46:16
|
On Saturday 20 September 2008 22:14:49 Roumen Petrov wrote: > Please find attached file bootstrap.sh (also attached > bootstrap.sh.gz is if mail client/server broke plain text). > > As I wrote in a previous email, you may use m4_define. I know I *can*; that's how I chose to do it, in the catgets library package, but it isn't how I want to do it for mingwrt or w32api. > This shell script create and configure an autoconf demo that set > version from a source file, name of the package, etc.. Based on > demo you may rewrote configure script do not use > MINGW_AC_CONFIG_SRCDIR . I may, but I won't. Actually, managing package versions within autoconf isn't particularly elegant; it requires regenerating configure every time the version is bumped, and since configure is maintained within CVS, that can get messy. Instead, I may simply revert to earlier autoconf syntax, and use: AC_INIT MINGW_AC_CONFIG_SRCDIR([__MINGW32_VERSION], [include/_mingw.h]) ... (I may even extend MINGW_AC_CONFIG_SRCDIR(), to have it also define the package name). Problem solved. Regards, Keith. |