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] #39639: no iconv implementation (MinGW Notification List)
2. [mingw] #39658: mingwrt 5.2.2 does not expose function
rand_s? (MinGW Notification List)
----------------------------------------------------------------------
Message: 1
Date: Fri, 11 Oct 2019 13:49:02 +0100
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #39639: no iconv implementation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#39639: no iconv implementation
Open Date: 2019-10-05 18:58
Last Update: 2019-10-11 13:49
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/39639
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39639
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2019-10-11 13:49 Updated by: keith
Comment:
Reply To zhangboyang
I downloaded serveral versions of cc1.exe, from gcc 5 to gcc 8. I found
5.3.0-2 and 6.3.0-1 had iconv compiled in, but 5.3.0-3, 7.3.0-1, 8.2.0-4
had no iconv complied in.
Strictly, none have it compiled in, but all are supposed to link dynamically to
libiconv-2.dll; of course, it is a justifiable claim that, at the very least,
the shared object references should be compiled in.
I googled the error message 'no iconv implementation', and I found many
similar issues, some even dated back to 2009, but there is no clear
solution or explaination.
The explanation lies in this sixteen year old GCC bug report; first reported
against GCC-3.4.0, in 2003, it seems to be generic to GCC core, afflicting all
versions since, likely affecting all platforms, and remaining unresolved to
this day. I was previously unaware of it; thanks for bringing it to my
attention.
I think there might be a problem in your build script, such as some kind of
race condition, which will lead to configuration script not find iconv
library.
Nope. My build scripts are correct, save for the problem that they take GCC
documentation at face value, and rely on --with-libiconv-prefix behaving as
documented, (which it doesn't); that some of my previous GCC builds did exhibit
iconv functionality is no more than a lucky accident.
Now that I'm aware of the GCC bug, I can work around it, but maybe the GCC crew
need to be nagged into putting their house in order — sixteen years of doing
absolutely nothing about a well defined bug seems kind of ridiculous; they
should either fix the bug, or fix the documentation.
---------------------------------------------------------------------
Ticket Status:
Reporter: zhangboyang
Owner: (None)
Type: Issues
Status: Open
Priority: 5 - Medium
MileStone: (None)
Component: OTHER
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
I have been used mingw-gcc for a long time. However, I found the
'-finput-charset=' option not always works correctly across versions. For
example, with the latest mingw-gcc version 8.2.0-4, runing 'gcc -finput-charset
=GB18030 helloworld.c' will throw out error, which says 'no iconv
implementation'.
My further investigation shows the iconv support wasn't compile into mingw-gcc
8.2.0-4. The error message 'no iconv implementation' (which is located in gcc's
charset.c) will only be compiled into cc1.exe when HAVE_ICONV is false.
I downloaded serveral versions of cc1.exe, from gcc 5 to gcc 8. I found 5.3.0-2
and 6.3.0-1 had iconv compiled in, but 5.3.0-3, 7.3.0-1, 8.2.0-4 had no iconv
complied in.
I googled the error message 'no iconv implementation', and I found many similar
issues, some even dated back to 2009, but there is no clear solution or
explaination. I think there might be a problem in your build script, such as
some kind of race condition, which will lead to configuration script not find
iconv library.
--
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/39639
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39639
------------------------------
Message: 2
Date: Sat, 12 Oct 2019 00:15:18 +0200
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #39658: mingwrt 5.2.2 does not expose
function rand_s?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#39658: mingwrt 5.2.2 does not expose function rand_s?
Open Date: 2019-10-06 14:50
Last Update: 2019-10-12 00:15
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/39658
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39658
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2019-10-12 00:15 Updated by: sping
Comment:
Reply To keith
{{{ code c #if MINGW32_VERSION >= 5003000L }}}
Okay cool — thank you! I have opened a pull request to add a guard like that to
Expat at https://github.com/libexpat/libexpat/pull/359 .
PS: Do you have links / sources about why rand_s and RtlGenRandom are
not more secure than rand despite not being devoid of entropy, as you
mention in the patch comment and above?
In what way do you think rand() is insecure? In what respect would rand_s()
be considered more secure? (Security implies user authentication — an
operation which neither of these functions performs).
To give an example where I would expect rand_s to be more secure than rand is
protection against hash flooding where the entropy keeps an attacker from
crafting a large number of strings that all hash to the same value and hence
significantly degrade performance of the hash table in the processing
application.
---------------------------------------------------------------------
Ticket Status:
Reporter: sping
Owner: (None)
Type: Issues
Status: Open
Priority: 5 - Medium
MileStone: (None)
Component: WSL
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
Hi!
Windows introduced function rand_s some time and while I find mention of it in
MinGW's msvcrt-xref.pdf I cannot find a signature for it in mingwrt 5.2.2
headers. Are there plans to add a prototype to MinGW? We're about to define a
prototype in https://github.com/libexpat/libexpat/pull/356/files for MinGW in
Expat ourselves now but it seems like the real fix would be to have it in MinGW
for everyone — what do you think?
On a side note, msvcrt-xref.pdf says that rand_s is not contained in Windows XP
but contained in Windows Vista an after. The way I read the MS docs they imply
availability in Windows XP but it might be wishful thinking — if you know for
sure, I'd be interested in more details.
Thanks and best, Sebastian
--
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/39658
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39658
------------------------------
Subject: Digest Footer
_______________________________________________
MinGW-Notify mailing list
[email protected]
https://lists.osdn.me/mailman/listinfo/mingw-notify
------------------------------
End of MinGW-Notify Digest, Vol 25, Issue 5
*******************************************
