From: SourceForge.net <no...@so...> - 2008-10-11 22:45:33
|
Bugs item #2160227, was opened at 2008-10-11 22:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mingw runtime Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Keith Marshall (keithmarshall) Assigned to: Nobody/Anonymous (nobody) Summary: math.h: scalb(): type conflict in function declaration Initial Comment: Having followed Danny's advice, and run the test suite for the mingwrt headers, I see: mingw/runtime/include/math.h:262: warning: conflicting types for built-in function 'scalb' According to POSIX, the obsolescent scalb() function should be prototyped as: double scalb(double x, double n); and I guess GCC has this prototype built in. However, MSDN has the prototype: double _scalb(double x, long exp); (which is better matched by the POSIX scalbln() function). The conflict arises because we have an oldname alias declared for scalb(), matching the MSDN underscore decorated variant; I wonder if we should remove this, both from math.h, and from all libmoldname.a variants. Any thoughts? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 |
From: SourceForge.net <no...@so...> - 2008-10-12 15:13:45
|
Bugs item #2160227, was opened at 2008-10-11 18:45 Message generated for change (Comment added) made by earnie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mingw runtime Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Keith Marshall (keithmarshall) Assigned to: Nobody/Anonymous (nobody) Summary: math.h: scalb(): type conflict in function declaration Initial Comment: Having followed Danny's advice, and run the test suite for the mingwrt headers, I see: mingw/runtime/include/math.h:262: warning: conflicting types for built-in function 'scalb' According to POSIX, the obsolescent scalb() function should be prototyped as: double scalb(double x, double n); and I guess GCC has this prototype built in. However, MSDN has the prototype: double _scalb(double x, long exp); (which is better matched by the POSIX scalbln() function). The conflict arises because we have an oldname alias declared for scalb(), matching the MSDN underscore decorated variant; I wonder if we should remove this, both from math.h, and from all libmoldname.a variants. Any thoughts? ---------------------------------------------------------------------- >Comment By: Earnie Boyd (earnie) Date: 2008-10-12 11:13 Message: Maybe better to provide both the POSIX and MSDN versions based on macro definition. But then as you say it is obsoleted so why not just remove it? What kind of affect would it have to other FOSS that might use the function? I don't remember any noise on the user list about the misdefined function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 |
From: SourceForge.net <no...@so...> - 2008-10-13 12:33:22
|
Bugs item #2160227, was opened at 2008-10-11 22:45 Message generated for change (Comment added) made by keithmarshall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mingw runtime Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Keith Marshall (keithmarshall) Assigned to: Nobody/Anonymous (nobody) Summary: math.h: scalb(): type conflict in function declaration Initial Comment: Having followed Danny's advice, and run the test suite for the mingwrt headers, I see: mingw/runtime/include/math.h:262: warning: conflicting types for built-in function 'scalb' According to POSIX, the obsolescent scalb() function should be prototyped as: double scalb(double x, double n); and I guess GCC has this prototype built in. However, MSDN has the prototype: double _scalb(double x, long exp); (which is better matched by the POSIX scalbln() function). The conflict arises because we have an oldname alias declared for scalb(), matching the MSDN underscore decorated variant; I wonder if we should remove this, both from math.h, and from all libmoldname.a variants. Any thoughts? ---------------------------------------------------------------------- >Comment By: Keith Marshall (keithmarshall) Date: 2008-10-13 12:33 Message: What macro(s) would be used, to support dual declaration? GCC provides scalb() as a built-in function; I'm guessing that it conforms to the POSIX prototype. As I read the info file, it seems that the built-in is not exposed in strict ANSI modes, (but neither are the prototypes for either scalb() or _scalb(), in MinGW's math.h); in other modes, including the default, the built-in may or may not be deployed, depending on the optimisation level in effect. Providing a library implementation which conforms to a different prototype from the built-in, seems to me like a recipe for mysterious unexpected behaviour. I've no idea what the impact of removal of the libmoldname.a stub would be; my guess is that the function isn't much used, and where it is, the POSIX behaviour will be expected. Unless they've actually been bitten by the potential incompatibility, I doubt if users would have ever noticed the problem -- the warning message is only exposed when compiling with `-Wsystem-headers', and I doubt if many users do that. The more I think about it, the more strongly I'm inclined to favour removal. In the case of snprintf(), where the semantics of the MSVCRT _snprintf() are incompatible with the POSIX/ANSI implementation, we require explicit use of _snprintf() for cases where the MSVCRT semantics are desired. While scalb() isn't an ANSI function, it is in POSIX, and its POSIX semantics differ from MSVCRT's _scalb(); it seems sanest to me, that we adopt a similar approach in this case, to that already adopted for snprintf() vs. _snprintf(). ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-10-12 15:13 Message: Maybe better to provide both the POSIX and MSDN versions based on macro definition. But then as you say it is obsoleted so why not just remove it? What kind of affect would it have to other FOSS that might use the function? I don't remember any noise on the user list about the misdefined function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 |
From: SourceForge.net <no...@so...> - 2008-10-13 12:48:47
|
Bugs item #2160227, was opened at 2008-10-11 18:45 Message generated for change (Comment added) made by earnie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mingw runtime Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Keith Marshall (keithmarshall) Assigned to: Nobody/Anonymous (nobody) Summary: math.h: scalb(): type conflict in function declaration Initial Comment: Having followed Danny's advice, and run the test suite for the mingwrt headers, I see: mingw/runtime/include/math.h:262: warning: conflicting types for built-in function 'scalb' According to POSIX, the obsolescent scalb() function should be prototyped as: double scalb(double x, double n); and I guess GCC has this prototype built in. However, MSDN has the prototype: double _scalb(double x, long exp); (which is better matched by the POSIX scalbln() function). The conflict arises because we have an oldname alias declared for scalb(), matching the MSDN underscore decorated variant; I wonder if we should remove this, both from math.h, and from all libmoldname.a variants. Any thoughts? ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-10-13 08:48 Message: I agree. Remove it. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-10-13 08:33 Message: What macro(s) would be used, to support dual declaration? GCC provides scalb() as a built-in function; I'm guessing that it conforms to the POSIX prototype. As I read the info file, it seems that the built-in is not exposed in strict ANSI modes, (but neither are the prototypes for either scalb() or _scalb(), in MinGW's math.h); in other modes, including the default, the built-in may or may not be deployed, depending on the optimisation level in effect. Providing a library implementation which conforms to a different prototype from the built-in, seems to me like a recipe for mysterious unexpected behaviour. I've no idea what the impact of removal of the libmoldname.a stub would be; my guess is that the function isn't much used, and where it is, the POSIX behaviour will be expected. Unless they've actually been bitten by the potential incompatibility, I doubt if users would have ever noticed the problem -- the warning message is only exposed when compiling with `-Wsystem-headers', and I doubt if many users do that. The more I think about it, the more strongly I'm inclined to favour removal. In the case of snprintf(), where the semantics of the MSVCRT _snprintf() are incompatible with the POSIX/ANSI implementation, we require explicit use of _snprintf() for cases where the MSVCRT semantics are desired. While scalb() isn't an ANSI function, it is in POSIX, and its POSIX semantics differ from MSVCRT's _scalb(); it seems sanest to me, that we adopt a similar approach in this case, to that already adopted for snprintf() vs. _snprintf(). ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-10-12 11:13 Message: Maybe better to provide both the POSIX and MSDN versions based on macro definition. But then as you say it is obsoleted so why not just remove it? What kind of affect would it have to other FOSS that might use the function? I don't remember any noise on the user list about the misdefined function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 |
From: SourceForge.net <no...@so...> - 2008-10-13 22:51:54
|
Bugs item #2160227, was opened at 2008-10-11 22:45 Message generated for change (Comment added) made by keithmarshall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mingw runtime >Group: IINR - Include In Next Release >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Keith Marshall (keithmarshall) >Assigned to: Keith Marshall (keithmarshall) Summary: math.h: scalb(): type conflict in function declaration Initial Comment: Having followed Danny's advice, and run the test suite for the mingwrt headers, I see: mingw/runtime/include/math.h:262: warning: conflicting types for built-in function 'scalb' According to POSIX, the obsolescent scalb() function should be prototyped as: double scalb(double x, double n); and I guess GCC has this prototype built in. However, MSDN has the prototype: double _scalb(double x, long exp); (which is better matched by the POSIX scalbln() function). The conflict arises because we have an oldname alias declared for scalb(), matching the MSDN underscore decorated variant; I wonder if we should remove this, both from math.h, and from all libmoldname.a variants. Any thoughts? ---------------------------------------------------------------------- >Comment By: Keith Marshall (keithmarshall) Date: 2008-10-13 22:51 Message: Done. Committed per ChangeLog entry: Eliminate conflicting declarations and implementations of scalb(). * moldname.def.in (scalb): Comment out of EXPORTS list. * include/math.h (scalb): Comment out OLDNAMES prototype; it conflicts with GCC's built-in declaration. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-10-13 12:48 Message: I agree. Remove it. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-10-13 12:33 Message: What macro(s) would be used, to support dual declaration? GCC provides scalb() as a built-in function; I'm guessing that it conforms to the POSIX prototype. As I read the info file, it seems that the built-in is not exposed in strict ANSI modes, (but neither are the prototypes for either scalb() or _scalb(), in MinGW's math.h); in other modes, including the default, the built-in may or may not be deployed, depending on the optimisation level in effect. Providing a library implementation which conforms to a different prototype from the built-in, seems to me like a recipe for mysterious unexpected behaviour. I've no idea what the impact of removal of the libmoldname.a stub would be; my guess is that the function isn't much used, and where it is, the POSIX behaviour will be expected. Unless they've actually been bitten by the potential incompatibility, I doubt if users would have ever noticed the problem -- the warning message is only exposed when compiling with `-Wsystem-headers', and I doubt if many users do that. The more I think about it, the more strongly I'm inclined to favour removal. In the case of snprintf(), where the semantics of the MSVCRT _snprintf() are incompatible with the POSIX/ANSI implementation, we require explicit use of _snprintf() for cases where the MSVCRT semantics are desired. While scalb() isn't an ANSI function, it is in POSIX, and its POSIX semantics differ from MSVCRT's _scalb(); it seems sanest to me, that we adopt a similar approach in this case, to that already adopted for snprintf() vs. _snprintf(). ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-10-12 15:13 Message: Maybe better to provide both the POSIX and MSDN versions based on macro definition. But then as you say it is obsoleted so why not just remove it? What kind of affect would it have to other FOSS that might use the function? I don't remember any noise on the user list about the misdefined function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 |
From: SourceForge.net <no...@so...> - 2008-10-14 02:01:51
|
Bugs item #2160227, was opened at 2008-10-12 11:45 Message generated for change (Comment added) made by dannysmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mingw runtime Group: IINR - Include In Next Release Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Keith Marshall (keithmarshall) Assigned to: Keith Marshall (keithmarshall) Summary: math.h: scalb(): type conflict in function declaration Initial Comment: Having followed Danny's advice, and run the test suite for the mingwrt headers, I see: mingw/runtime/include/math.h:262: warning: conflicting types for built-in function 'scalb' According to POSIX, the obsolescent scalb() function should be prototyped as: double scalb(double x, double n); and I guess GCC has this prototype built in. However, MSDN has the prototype: double _scalb(double x, long exp); (which is better matched by the POSIX scalbln() function). The conflict arises because we have an oldname alias declared for scalb(), matching the MSDN underscore decorated variant; I wonder if we should remove this, both from math.h, and from all libmoldname.a variants. Any thoughts? ---------------------------------------------------------------------- >Comment By: Danny Smith (dannysmith) Date: 2008-10-14 15:01 Message: This was discussed on gcc list here: http://gcc.gnu.org/ml/gcc-bugs/2003-09/msg01837.html Note: The builtin is disabled when math.h is included and gcc notices the conflicting prototype. -std=c89 or -std=c99 disables non-ansi builtins. Danny ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-10-14 11:51 Message: Done. Committed per ChangeLog entry: Eliminate conflicting declarations and implementations of scalb(). * moldname.def.in (scalb): Comment out of EXPORTS list. * include/math.h (scalb): Comment out OLDNAMES prototype; it conflicts with GCC's built-in declaration. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-10-14 01:48 Message: I agree. Remove it. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-10-14 01:33 Message: What macro(s) would be used, to support dual declaration? GCC provides scalb() as a built-in function; I'm guessing that it conforms to the POSIX prototype. As I read the info file, it seems that the built-in is not exposed in strict ANSI modes, (but neither are the prototypes for either scalb() or _scalb(), in MinGW's math.h); in other modes, including the default, the built-in may or may not be deployed, depending on the optimisation level in effect. Providing a library implementation which conforms to a different prototype from the built-in, seems to me like a recipe for mysterious unexpected behaviour. I've no idea what the impact of removal of the libmoldname.a stub would be; my guess is that the function isn't much used, and where it is, the POSIX behaviour will be expected. Unless they've actually been bitten by the potential incompatibility, I doubt if users would have ever noticed the problem -- the warning message is only exposed when compiling with `-Wsystem-headers', and I doubt if many users do that. The more I think about it, the more strongly I'm inclined to favour removal. In the case of snprintf(), where the semantics of the MSVCRT _snprintf() are incompatible with the POSIX/ANSI implementation, we require explicit use of _snprintf() for cases where the MSVCRT semantics are desired. While scalb() isn't an ANSI function, it is in POSIX, and its POSIX semantics differ from MSVCRT's _scalb(); it seems sanest to me, that we adopt a similar approach in this case, to that already adopted for snprintf() vs. _snprintf(). ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-10-13 04:13 Message: Maybe better to provide both the POSIX and MSDN versions based on macro definition. But then as you say it is obsoleted so why not just remove it? What kind of affect would it have to other FOSS that might use the function? I don't remember any noise on the user list about the misdefined function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 |
From: SourceForge.net <no...@so...> - 2008-10-14 11:54:03
|
Bugs item #2160227, was opened at 2008-10-11 22:45 Message generated for change (Comment added) made by keithmarshall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mingw runtime Group: IINR - Include In Next Release Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Keith Marshall (keithmarshall) Assigned to: Keith Marshall (keithmarshall) Summary: math.h: scalb(): type conflict in function declaration Initial Comment: Having followed Danny's advice, and run the test suite for the mingwrt headers, I see: mingw/runtime/include/math.h:262: warning: conflicting types for built-in function 'scalb' According to POSIX, the obsolescent scalb() function should be prototyped as: double scalb(double x, double n); and I guess GCC has this prototype built in. However, MSDN has the prototype: double _scalb(double x, long exp); (which is better matched by the POSIX scalbln() function). The conflict arises because we have an oldname alias declared for scalb(), matching the MSDN underscore decorated variant; I wonder if we should remove this, both from math.h, and from all libmoldname.a variants. Any thoughts? ---------------------------------------------------------------------- >Comment By: Keith Marshall (keithmarshall) Date: 2008-10-14 11:53 Message: Thanks for the link, Danny. It isn't clear whether or not you expect any further follow-up; I still believe that removal of scalb(), (but not _scalb()), is the right thing to do... * As Kaveh correctly noted, scalb() isn't an ISO-C function; I'll qualify that further: it isn't a current MSVC function either, (not documented as such on MSDN). * scalb() became a POSIX function in issue 4 of IEEE-1003.1, when it was qualified as an XSI extension, (i.e. XOPEN), but it was promoted to BASE in issue 5, and subsequently deprecated (marked obsolescent) in issue 6; the MinGW prototype in math.h conflicts with POSIX. POSIX now says applications should not use scalb(). Removal of a MinGW specific, incompatible implementation will... * possibly have no impact at all; * cause applications to fall back to the POSIX conforming GCC built-in implementation, or ... * alert users to their dependence on an ambiguously specified function, giving them the opportunity to choose a more appropriate and predictable (i.e. more robust) alternative. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2008-10-14 02:01 Message: This was discussed on gcc list here: http://gcc.gnu.org/ml/gcc-bugs/2003-09/msg01837.html Note: The builtin is disabled when math.h is included and gcc notices the conflicting prototype. -std=c89 or -std=c99 disables non-ansi builtins. Danny ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-10-13 22:51 Message: Done. Committed per ChangeLog entry: Eliminate conflicting declarations and implementations of scalb(). * moldname.def.in (scalb): Comment out of EXPORTS list. * include/math.h (scalb): Comment out OLDNAMES prototype; it conflicts with GCC's built-in declaration. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-10-13 12:48 Message: I agree. Remove it. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-10-13 12:33 Message: What macro(s) would be used, to support dual declaration? GCC provides scalb() as a built-in function; I'm guessing that it conforms to the POSIX prototype. As I read the info file, it seems that the built-in is not exposed in strict ANSI modes, (but neither are the prototypes for either scalb() or _scalb(), in MinGW's math.h); in other modes, including the default, the built-in may or may not be deployed, depending on the optimisation level in effect. Providing a library implementation which conforms to a different prototype from the built-in, seems to me like a recipe for mysterious unexpected behaviour. I've no idea what the impact of removal of the libmoldname.a stub would be; my guess is that the function isn't much used, and where it is, the POSIX behaviour will be expected. Unless they've actually been bitten by the potential incompatibility, I doubt if users would have ever noticed the problem -- the warning message is only exposed when compiling with `-Wsystem-headers', and I doubt if many users do that. The more I think about it, the more strongly I'm inclined to favour removal. In the case of snprintf(), where the semantics of the MSVCRT _snprintf() are incompatible with the POSIX/ANSI implementation, we require explicit use of _snprintf() for cases where the MSVCRT semantics are desired. While scalb() isn't an ANSI function, it is in POSIX, and its POSIX semantics differ from MSVCRT's _scalb(); it seems sanest to me, that we adopt a similar approach in this case, to that already adopted for snprintf() vs. _snprintf(). ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-10-12 15:13 Message: Maybe better to provide both the POSIX and MSDN versions based on macro definition. But then as you say it is obsoleted so why not just remove it? What kind of affect would it have to other FOSS that might use the function? I don't remember any noise on the user list about the misdefined function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 |
From: SourceForge.net <no...@so...> - 2008-10-15 01:50:54
|
Bugs item #2160227, was opened at 2008-10-12 11:45 Message generated for change (Comment added) made by dannysmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mingw runtime Group: IINR - Include In Next Release Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Keith Marshall (keithmarshall) Assigned to: Keith Marshall (keithmarshall) Summary: math.h: scalb(): type conflict in function declaration Initial Comment: Having followed Danny's advice, and run the test suite for the mingwrt headers, I see: mingw/runtime/include/math.h:262: warning: conflicting types for built-in function 'scalb' According to POSIX, the obsolescent scalb() function should be prototyped as: double scalb(double x, double n); and I guess GCC has this prototype built in. However, MSDN has the prototype: double _scalb(double x, long exp); (which is better matched by the POSIX scalbln() function). The conflict arises because we have an oldname alias declared for scalb(), matching the MSDN underscore decorated variant; I wonder if we should remove this, both from math.h, and from all libmoldname.a variants. Any thoughts? ---------------------------------------------------------------------- >Comment By: Danny Smith (dannysmith) Date: 2008-10-15 14:50 Message: No I do not expect any further action Qualifying this statement a bit more: "it isn't a current MSVC function either, (not documented as such on MSDN)" None of the POSIX "oldnames" are documented by MSDN except perhaps to say they are deprecated. eg http://msdn.microsoft.com/en-us/library/ms235383(VS.80).aspx Perhaps we should remove them all and see what we break. Danny ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-10-15 00:53 Message: Thanks for the link, Danny. It isn't clear whether or not you expect any further follow-up; I still believe that removal of scalb(), (but not _scalb()), is the right thing to do... * As Kaveh correctly noted, scalb() isn't an ISO-C function; I'll qualify that further: it isn't a current MSVC function either, (not documented as such on MSDN). * scalb() became a POSIX function in issue 4 of IEEE-1003.1, when it was qualified as an XSI extension, (i.e. XOPEN), but it was promoted to BASE in issue 5, and subsequently deprecated (marked obsolescent) in issue 6; the MinGW prototype in math.h conflicts with POSIX. POSIX now says applications should not use scalb(). Removal of a MinGW specific, incompatible implementation will... * possibly have no impact at all; * cause applications to fall back to the POSIX conforming GCC built-in implementation, or ... * alert users to their dependence on an ambiguously specified function, giving them the opportunity to choose a more appropriate and predictable (i.e. more robust) alternative. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2008-10-14 15:01 Message: This was discussed on gcc list here: http://gcc.gnu.org/ml/gcc-bugs/2003-09/msg01837.html Note: The builtin is disabled when math.h is included and gcc notices the conflicting prototype. -std=c89 or -std=c99 disables non-ansi builtins. Danny ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-10-14 11:51 Message: Done. Committed per ChangeLog entry: Eliminate conflicting declarations and implementations of scalb(). * moldname.def.in (scalb): Comment out of EXPORTS list. * include/math.h (scalb): Comment out OLDNAMES prototype; it conflicts with GCC's built-in declaration. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-10-14 01:48 Message: I agree. Remove it. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-10-14 01:33 Message: What macro(s) would be used, to support dual declaration? GCC provides scalb() as a built-in function; I'm guessing that it conforms to the POSIX prototype. As I read the info file, it seems that the built-in is not exposed in strict ANSI modes, (but neither are the prototypes for either scalb() or _scalb(), in MinGW's math.h); in other modes, including the default, the built-in may or may not be deployed, depending on the optimisation level in effect. Providing a library implementation which conforms to a different prototype from the built-in, seems to me like a recipe for mysterious unexpected behaviour. I've no idea what the impact of removal of the libmoldname.a stub would be; my guess is that the function isn't much used, and where it is, the POSIX behaviour will be expected. Unless they've actually been bitten by the potential incompatibility, I doubt if users would have ever noticed the problem -- the warning message is only exposed when compiling with `-Wsystem-headers', and I doubt if many users do that. The more I think about it, the more strongly I'm inclined to favour removal. In the case of snprintf(), where the semantics of the MSVCRT _snprintf() are incompatible with the POSIX/ANSI implementation, we require explicit use of _snprintf() for cases where the MSVCRT semantics are desired. While scalb() isn't an ANSI function, it is in POSIX, and its POSIX semantics differ from MSVCRT's _scalb(); it seems sanest to me, that we adopt a similar approach in this case, to that already adopted for snprintf() vs. _snprintf(). ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-10-13 04:13 Message: Maybe better to provide both the POSIX and MSDN versions based on macro definition. But then as you say it is obsoleted so why not just remove it? What kind of affect would it have to other FOSS that might use the function? I don't remember any noise on the user list about the misdefined function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 |
From: SourceForge.net <no...@so...> - 2008-10-15 10:22:34
|
Bugs item #2160227, was opened at 2008-10-11 22:45 Message generated for change (Comment added) made by keithmarshall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mingw runtime Group: IINR - Include In Next Release Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Keith Marshall (keithmarshall) Assigned to: Keith Marshall (keithmarshall) Summary: math.h: scalb(): type conflict in function declaration Initial Comment: Having followed Danny's advice, and run the test suite for the mingwrt headers, I see: mingw/runtime/include/math.h:262: warning: conflicting types for built-in function 'scalb' According to POSIX, the obsolescent scalb() function should be prototyped as: double scalb(double x, double n); and I guess GCC has this prototype built in. However, MSDN has the prototype: double _scalb(double x, long exp); (which is better matched by the POSIX scalbln() function). The conflict arises because we have an oldname alias declared for scalb(), matching the MSDN underscore decorated variant; I wonder if we should remove this, both from math.h, and from all libmoldname.a variants. Any thoughts? ---------------------------------------------------------------------- >Comment By: Keith Marshall (keithmarshall) Date: 2008-10-15 10:22 Message: Oh, very droll, Danny :-) Quoting from your example reference: |spawnv |This POSIX function is deprecated... I wonder what the POSIX standards committee might have to say about this; spawnv() is not, (and never has been, AFAIK), a POSIX function. Maybe we could consider removing the oldname functions which actually are not POSIX, or even those which are, but the libmoldname.a stubs are directed to nonconforming implementations, (e.g. mkdir()), but is it worth the effort? Removing those which are POSIX, and which exhibit reasonably conforming implementations, would be needlessly destructive, IMO. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2008-10-15 01:50 Message: No I do not expect any further action Qualifying this statement a bit more: "it isn't a current MSVC function either, (not documented as such on MSDN)" None of the POSIX "oldnames" are documented by MSDN except perhaps to say they are deprecated. eg http://msdn.microsoft.com/en-us/library/ms235383(VS.80).aspx Perhaps we should remove them all and see what we break. Danny ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-10-14 11:53 Message: Thanks for the link, Danny. It isn't clear whether or not you expect any further follow-up; I still believe that removal of scalb(), (but not _scalb()), is the right thing to do... * As Kaveh correctly noted, scalb() isn't an ISO-C function; I'll qualify that further: it isn't a current MSVC function either, (not documented as such on MSDN). * scalb() became a POSIX function in issue 4 of IEEE-1003.1, when it was qualified as an XSI extension, (i.e. XOPEN), but it was promoted to BASE in issue 5, and subsequently deprecated (marked obsolescent) in issue 6; the MinGW prototype in math.h conflicts with POSIX. POSIX now says applications should not use scalb(). Removal of a MinGW specific, incompatible implementation will... * possibly have no impact at all; * cause applications to fall back to the POSIX conforming GCC built-in implementation, or ... * alert users to their dependence on an ambiguously specified function, giving them the opportunity to choose a more appropriate and predictable (i.e. more robust) alternative. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2008-10-14 02:01 Message: This was discussed on gcc list here: http://gcc.gnu.org/ml/gcc-bugs/2003-09/msg01837.html Note: The builtin is disabled when math.h is included and gcc notices the conflicting prototype. -std=c89 or -std=c99 disables non-ansi builtins. Danny ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-10-13 22:51 Message: Done. Committed per ChangeLog entry: Eliminate conflicting declarations and implementations of scalb(). * moldname.def.in (scalb): Comment out of EXPORTS list. * include/math.h (scalb): Comment out OLDNAMES prototype; it conflicts with GCC's built-in declaration. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-10-13 12:48 Message: I agree. Remove it. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-10-13 12:33 Message: What macro(s) would be used, to support dual declaration? GCC provides scalb() as a built-in function; I'm guessing that it conforms to the POSIX prototype. As I read the info file, it seems that the built-in is not exposed in strict ANSI modes, (but neither are the prototypes for either scalb() or _scalb(), in MinGW's math.h); in other modes, including the default, the built-in may or may not be deployed, depending on the optimisation level in effect. Providing a library implementation which conforms to a different prototype from the built-in, seems to me like a recipe for mysterious unexpected behaviour. I've no idea what the impact of removal of the libmoldname.a stub would be; my guess is that the function isn't much used, and where it is, the POSIX behaviour will be expected. Unless they've actually been bitten by the potential incompatibility, I doubt if users would have ever noticed the problem -- the warning message is only exposed when compiling with `-Wsystem-headers', and I doubt if many users do that. The more I think about it, the more strongly I'm inclined to favour removal. In the case of snprintf(), where the semantics of the MSVCRT _snprintf() are incompatible with the POSIX/ANSI implementation, we require explicit use of _snprintf() for cases where the MSVCRT semantics are desired. While scalb() isn't an ANSI function, it is in POSIX, and its POSIX semantics differ from MSVCRT's _scalb(); it seems sanest to me, that we adopt a similar approach in this case, to that already adopted for snprintf() vs. _snprintf(). ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-10-12 15:13 Message: Maybe better to provide both the POSIX and MSDN versions based on macro definition. But then as you say it is obsoleted so why not just remove it? What kind of affect would it have to other FOSS that might use the function? I don't remember any noise on the user list about the misdefined function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 |
From: SourceForge.net <no...@so...> - 2008-10-15 11:31:28
|
Bugs item #2160227, was opened at 2008-10-11 18:45 Message generated for change (Comment added) made by earnie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mingw runtime Group: IINR - Include In Next Release Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Keith Marshall (keithmarshall) Assigned to: Keith Marshall (keithmarshall) Summary: math.h: scalb(): type conflict in function declaration Initial Comment: Having followed Danny's advice, and run the test suite for the mingwrt headers, I see: mingw/runtime/include/math.h:262: warning: conflicting types for built-in function 'scalb' According to POSIX, the obsolescent scalb() function should be prototyped as: double scalb(double x, double n); and I guess GCC has this prototype built in. However, MSDN has the prototype: double _scalb(double x, long exp); (which is better matched by the POSIX scalbln() function). The conflict arises because we have an oldname alias declared for scalb(), matching the MSDN underscore decorated variant; I wonder if we should remove this, both from math.h, and from all libmoldname.a variants. Any thoughts? ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-10-15 07:31 Message: We could just make the default value for the macro set so they're not defined unless specified. Well, I suppose that means reworking _NO_OLDNAMES to something like _MINGW_OLDNAMES or _MINGW_DEPRECATED. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-10-15 06:22 Message: Oh, very droll, Danny :-) Quoting from your example reference: |spawnv |This POSIX function is deprecated... I wonder what the POSIX standards committee might have to say about this; spawnv() is not, (and never has been, AFAIK), a POSIX function. Maybe we could consider removing the oldname functions which actually are not POSIX, or even those which are, but the libmoldname.a stubs are directed to nonconforming implementations, (e.g. mkdir()), but is it worth the effort? Removing those which are POSIX, and which exhibit reasonably conforming implementations, would be needlessly destructive, IMO. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2008-10-14 21:50 Message: No I do not expect any further action Qualifying this statement a bit more: "it isn't a current MSVC function either, (not documented as such on MSDN)" None of the POSIX "oldnames" are documented by MSDN except perhaps to say they are deprecated. eg http://msdn.microsoft.com/en-us/library/ms235383(VS.80).aspx Perhaps we should remove them all and see what we break. Danny ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-10-14 07:53 Message: Thanks for the link, Danny. It isn't clear whether or not you expect any further follow-up; I still believe that removal of scalb(), (but not _scalb()), is the right thing to do... * As Kaveh correctly noted, scalb() isn't an ISO-C function; I'll qualify that further: it isn't a current MSVC function either, (not documented as such on MSDN). * scalb() became a POSIX function in issue 4 of IEEE-1003.1, when it was qualified as an XSI extension, (i.e. XOPEN), but it was promoted to BASE in issue 5, and subsequently deprecated (marked obsolescent) in issue 6; the MinGW prototype in math.h conflicts with POSIX. POSIX now says applications should not use scalb(). Removal of a MinGW specific, incompatible implementation will... * possibly have no impact at all; * cause applications to fall back to the POSIX conforming GCC built-in implementation, or ... * alert users to their dependence on an ambiguously specified function, giving them the opportunity to choose a more appropriate and predictable (i.e. more robust) alternative. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2008-10-13 22:01 Message: This was discussed on gcc list here: http://gcc.gnu.org/ml/gcc-bugs/2003-09/msg01837.html Note: The builtin is disabled when math.h is included and gcc notices the conflicting prototype. -std=c89 or -std=c99 disables non-ansi builtins. Danny ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-10-13 18:51 Message: Done. Committed per ChangeLog entry: Eliminate conflicting declarations and implementations of scalb(). * moldname.def.in (scalb): Comment out of EXPORTS list. * include/math.h (scalb): Comment out OLDNAMES prototype; it conflicts with GCC's built-in declaration. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-10-13 08:48 Message: I agree. Remove it. ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-10-13 08:33 Message: What macro(s) would be used, to support dual declaration? GCC provides scalb() as a built-in function; I'm guessing that it conforms to the POSIX prototype. As I read the info file, it seems that the built-in is not exposed in strict ANSI modes, (but neither are the prototypes for either scalb() or _scalb(), in MinGW's math.h); in other modes, including the default, the built-in may or may not be deployed, depending on the optimisation level in effect. Providing a library implementation which conforms to a different prototype from the built-in, seems to me like a recipe for mysterious unexpected behaviour. I've no idea what the impact of removal of the libmoldname.a stub would be; my guess is that the function isn't much used, and where it is, the POSIX behaviour will be expected. Unless they've actually been bitten by the potential incompatibility, I doubt if users would have ever noticed the problem -- the warning message is only exposed when compiling with `-Wsystem-headers', and I doubt if many users do that. The more I think about it, the more strongly I'm inclined to favour removal. In the case of snprintf(), where the semantics of the MSVCRT _snprintf() are incompatible with the POSIX/ANSI implementation, we require explicit use of _snprintf() for cases where the MSVCRT semantics are desired. While scalb() isn't an ANSI function, it is in POSIX, and its POSIX semantics differ from MSVCRT's _scalb(); it seems sanest to me, that we adopt a similar approach in this case, to that already adopted for snprintf() vs. _snprintf(). ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-10-12 11:13 Message: Maybe better to provide both the POSIX and MSDN versions based on macro definition. But then as you say it is obsoleted so why not just remove it? What kind of affect would it have to other FOSS that might use the function? I don't remember any noise on the user list about the misdefined function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2160227&group_id=2435 |