Send MinGW-Notify mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osdn.me/mailman/listinfo/mingw-notify
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MinGW-Notify digest..."
Please do not reply to this notification; the sender address is unable to
accept incoming e-mail. If you wish to unsubscribe you can do so at
https://lists.osdn.me/mailman/listinfo/mingw-notify.
Today's Topics:
1. [mingw] #39750: Syntax Error Issue (MinGW Notification List)
2. [mingw] #39687: wcsrtombs with NULL dest pointer doesn't
ignore len parameter (MinGW Notification List)
3. [mingw] #39715: Two possible C type double division bugs when
compiling with gcc -Ofast (MinGW Notification List)
4. [mingw] #39687: wcsrtombs with NULL dest pointer doesn't
ignore len parameter (MinGW Notification List)
----------------------------------------------------------------------
Message: 1
Date: Tue, 12 Nov 2019 13:05:58 +0900
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #39750: Syntax Error Issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#39750: Syntax Error Issue
Open Date: 2019-11-12 13:05
Last Update: 2019-11-12 13:05
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/39750
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39750
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2019-11-12 13:05 Updated by: c0mod0
* New Ticket "Syntax Error Issue" created
---------------------------------------------------------------------
Ticket Status:
Reporter: c0mod0
Owner: (None)
Type: Issues
Status: Open
Priority: 1 - Lowest
MileStone: (None)
Component: GCC
Severity: 1 - Lowest
Resolution: None
---------------------------------------------------------------------
Ticket details:
Respected Team, I have tested the mingw 8.2.1 win32 on Windows OS and found
that there is an issue after compiling any program. If a syntax error occurs,
the color of cmd prompt becomes white. As this seems to be an issue with your
programs (gcc and g++). Kindly fix it.
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/39750
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39750
------------------------------
Message: 2
Date: Tue, 12 Nov 2019 15:11:51 +0000
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #39687: wcsrtombs with NULL dest
pointer doesn't ignore len parameter
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#39687: wcsrtombs with NULL dest pointer doesn't ignore len parameter
Open Date: 2019-10-19 17:38
Last Update: 2019-11-12 15:11
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/39687
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39687
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2019-11-12 15:11 Updated by: keith
Comment:
The problem is indeed the Microsoft setlocale() limitation, (which, although
Microsoft's documentation doesn't acknowledge it as such, is clearly a bug).
The clue is in the Locale: C output, following the conditional call which
becomes equivalent to setlocale( LC_CTYPE, "English_United Kingdom.65001" );
the failure to change the locale setting, from the initial "C" state, is a
clear indication that the 65001 (UTF-8) codeset specification has been
rejected.
The ideal solution would be to have a correctly working setlocale()
implementation, but Microsoft will never provide that, particularly in the case
of any legacy Windows version, which MinGW still endeavours to support. Next
best would be a MinGW replacement setlocale() implementation, (which could also
address other failings of the Microsoft implementation), but this would require
significant development effort, and must, therefore, be considered only as a
longer term development objective. In the shorter term, I propose to adapt the
MinGW replacements for wcrtomb() and wcsrtombs(), such that they will initially
identify a potential codeset identity from the string returned by setlocale(
LC_CTYPE, NULL ), (as they do currently), but then override that by inspection
of getenv( "LC_ALL" ), getenv( "LC_CTYPE" ), or getenv( "LANG" ), in that
order, and taking the first non-NULL, if any, and then if, and only if, the
string returned by setlocale( LC_CTYPE, NULL ) is a verbatim match for that
returned by setlocale( LC_CTYPE, "" ), and any overriding codeset, so
identified, is confirmed as having a non-zero encoding length, by GetCPInfo(
codeset, &info ).
---------------------------------------------------------------------
Ticket Status:
Reporter: gallickgunner
Owner: keith
Type: Issues
Status: Open [Owner assigned]
Priority: 5 - Medium
MileStone: (None)
Component: WSL
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
I'm using MinGW-gcc-6.3.0. The wcsrtombs() function as mentioned in the docs on
cppreference should return the number of bytes that would have been written to
src. However it doesn't do so on my end. It seems the implementation doesn't
ignore the length parameter when dest is passed as NULL? A similar issue was
reported and presumably fixed for the Mingw-w64 on the sourceforge site
Currently working around by passing INT_MAX as the length parameter, so it
finishes within the limit and returns the size.
I apologize in advance if this is just an issue from my end or if any other
info is missing. First time submitting a ticket :)
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/39687
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39687
------------------------------
Message: 3
Date: Tue, 12 Nov 2019 21:41:14 +0000
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #39715: Two possible C type double
division bugs when compiling with gcc -Ofast
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#39715: Two possible C type double division bugs when compiling with gcc -Ofast
Open Date: 2019-11-02 14:49
Last Update: 2019-11-12 21:41
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/39715
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39715
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2019-11-12 21:41 Updated by: keith
Comment:
I'm not convinced that this is a bug, or that it merits further attention.
I know essentially nothing about what the "-Ofast" option does ...
Perhaps you should research it; the GCC documentation covers it in excruciating
detial, with a recurring theme being that it sacrifices accuracy and precision,
for faster execution.
By its very nature, floating point is imprecise, and in your case the floor()
function truncates an already imprecise result toward negative infinity,
throwing away possibly as much as one integer unit, if the imprecision is as
little as one least significant floating point bit below the correctly rounded
result. When the expected precision in the result is no better than plus or
minus one integer unit, I don't think a variation of one integer unit
constitutes a reportable bug.
---------------------------------------------------------------------
Ticket Status:
Reporter: colin13on
Owner: (None)
Type: Issues
Status: Open
Priority: 5 - Medium
MileStone: (None)
Component: (None)
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
Using: MinGW GCC compiler: gcc (MinGW.org GCC-8.2.0-5) 8.2.0; Microsoft Windows
7 Professional 64 bit operating system; Lenovo Thinkpad T420 laptop 64 bit
computer.
Also tried on: GNU GCC compiler: gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0; Lubuntu
32 bit operating system; Samsung N220 netbook 32 bit computer.
Compiling with gcc: -O0, -O1, -O2, O3, -Os, -Og; the attached code works as
intended.
But compiling with gcc -Ofast, it sometimes calculates the wrong "a" or "x".
This behaviour seems consistent and reproducible on both the above setups,
although the wrong behaviour is slightly different on each setup.
I know essentially nothing about what the "-Ofast" option does, and don't know
whether using the "-Ofast" option might be expected to change the way type
double division sometimes works, or whether this is something that merits
further investigation.
I hope the attached comments and code are reasonably clear, but I am happy to
answer questions.
Colin Bartlett
P.S. I intend to attach a file with the C program code, examples of the wrong
output, and more information. If I can't manage to attach that file then please
let me know of another way of sending it. The file has just under 300 lines, of
which 60 lines are the actual code and C preprocessor directives.
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/39715
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39715
------------------------------
Message: 4
Date: Tue, 12 Nov 2019 23:38:20 +0000
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #39687: wcsrtombs with NULL dest
pointer doesn't ignore len parameter
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#39687: wcsrtombs with NULL dest pointer doesn't ignore len parameter
Open Date: 2019-10-19 17:38
Last Update: 2019-11-12 23:38
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/39687
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39687
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2019-11-12 23:38 Updated by: keith
Comment:
I've updated my original patch, to implement the stratagem I outlined earlier.
With this applied, and also with the following addition to my original test
case:
1. --- a/tc39687.cc 2019-11-12 23:06:48.688108980 +0000
2. +++ b/tc39687.cc 2019-11-11 22:55:10.816277321 +0000
3. @@ -19,12 +19,14 @@
4. { std::cerr << "Verified input length: " << len << "; "
5. << std::strerror(errno) << '\n';
6. }
7. }
8.
9. int main()
10. -{ const char *lang = std::getenv("LC_CTYPE");
11. +{
12. + std::setlocale(LC_ALL, "" );
13. + const char *lang = std::getenv("LC_CTYPE");
14. std::setlocale(LC_CTYPE, (lang == nullptr) ? "" : lang );
15. std::cout << "Locale: " << std::setlocale(LC_CTYPE, NULL) << '\n';
16. const wchar_t* wstr = L"A wstring-\u00df\u6c34\U0001d10b"; // or L"A
wstring-ß水𝄋"
17. print_wide(wstr);
18. }
With these changes, I can successfully run the test case on my Win7 VM, where I
now see:
$ LC_CTYPE="English_United Kingdom.65001" /e/tc39687.exe
Locale: English_United Kingdom.1252
Multibyte string: A wstring-ÃYæ°´ð?"<
Length, including '\0': 20
Note that the output of the converted string data is garbled, (because the
console is actually incapable of rendering UTF-8 encoded data), but the length
determination is now correct.
I propose incorporating this modification into mingwrt-5.3.
---------------------------------------------------------------------
Ticket Status:
Reporter: gallickgunner
Owner: keith
Type: Issues
Status: Open [Owner assigned]
Priority: 5 - Medium
MileStone: (None)
Component: WSL
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
I'm using MinGW-gcc-6.3.0. The wcsrtombs() function as mentioned in the docs on
cppreference should return the number of bytes that would have been written to
src. However it doesn't do so on my end. It seems the implementation doesn't
ignore the length parameter when dest is passed as NULL? A similar issue was
reported and presumably fixed for the Mingw-w64 on the sourceforge site
Currently working around by passing INT_MAX as the length parameter, so it
finishes within the limit and returns the size.
I apologize in advance if this is just an issue from my end or if any other
info is missing. First time submitting a ticket :)
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/39687
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39687
------------------------------
Subject: Digest Footer
_______________________________________________
MinGW-Notify mailing list
[email protected]
https://lists.osdn.me/mailman/listinfo/mingw-notify
------------------------------
End of MinGW-Notify Digest, Vol 26, Issue 5
*******************************************
