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] #39532: package download failure (MinGW Notification List)
2. [mingw] #39512: v/snprintf don't null-terminate when
truncating (MinGW Notification List)
3. [mingw] #39512: v/snprintf don't null-terminate when
truncating (MinGW Notification List)
----------------------------------------------------------------------
Message: 1
Date: Thu, 05 Sep 2019 13:53:56 +0100
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #39532: package download failure
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#39532: package download failure
Open Date: 2019-09-03 13:02
Last Update: 2019-09-05 13:53
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/39532
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39532
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2019-09-05 13:53 Updated by: keith
* Status Update from Open to Closed
* Resolution Update from None to Works For Me
* Details Updated
Comment:
Well, your screen grab refers to a different file; assuming that your reference
to make-3.82.9-2-mingw32-cvs-20120902-bin.tar is a typo, I've made the
appropriate correction.
I do note that the screen grab indicates an HTTP status 500 error. This is a
non-specific server error, which, more often than not, results from a temporary
condition. I no longer use Microsoft Windows — Windows-10 is just so utterly
and disgustingly user hostile as to defy description — but direct specification
of the apparently offending download URL, as a wget target, is working just
fine for me. Beyond suggesting that you try it again, there isn't much else I
can suggest.
---------------------------------------------------------------------
Ticket Status:
Reporter: smaouim
Owner: (None)
Type: Issues
Status: Closed
Priority: 5 - Medium
MileStone: (None)
Component: INSTALLER
Severity: 5 - Medium
Resolution: Works For Me
---------------------------------------------------------------------
Ticket details:
mingw-get failed to download the package
make-3.82.90-2-mingw32-cvs-20120902-bin.tar
--
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/39532
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39532
------------------------------
Message: 2
Date: Thu, 05 Sep 2019 15:09:44 +0100
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #39512: v/snprintf don't
null-terminate when truncating
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#39512: v/snprintf don't null-terminate when truncating
Open Date: 2019-08-26 20:45
Last Update: 2019-09-05 15:09
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/39512
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39512
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2019-09-05 15:09 Updated by: keith
* Status Update from Open to Closed
* Resolution Update from None to Invalid
Comment:
Reply To lazybumhorse
Using MSYS2 on Windows 7, snprintf and vsnprintf are not C99+ standard
compliant because they do not null-terminate when truncating.
Who cares? MSYS2 is not a product of this project; we do not support it.
errno is ERANGE and this seems to indicate it is using _vsnprintf (from
msvcrt.dll?), at least it is similar in behavior to _vsnprintf_s, minus the
null-termination: https://docs.microsoft.com/en-us/cpp/c-runtime-library/
reference/snprintf-s-snprintf-s-l-snwprintf-s-snwprintf-s-l
Be that as it may, genuine MinGW implementations of snprintf() and vsnprintf()
exhibit correct C99 behaviour; if that's what your source calls out, that's
what you will get. If you want the weird Microsoft behaviour, then you must
explicitly use their functions.
If __USE_MINGW_ANSI_STDIO is defined as 1 before the stdio.h include, this
example does null-terminate, but I neither know what else that does entail,
nor does it help the case of non-conformity.
Well, that's misuse of an internally reserved symbolic constant name, but it's
irrelevant in the case of genuine MinGW snprintf() and vsnprintf() anyway; if
you call out the C99 functions, you get C99 behaviour. However, if you aren't
using genuine MinGW products, it's anybody's guess what might happen.
---------------------------------------------------------------------
Ticket Status:
Reporter: lazybumhorse
Owner: (None)
Type: Issues
Status: Closed
Priority: 5 - Medium
MileStone: (None)
Component: WSL
Severity: 5 - Medium
Resolution: Invalid
---------------------------------------------------------------------
Ticket details:
Using MSYS2 on Windows 7, snprintf and vsnprintf are not C99+ standard
compliant because they do not null-terminate when truncating.
Relevant excerpt from the C99 standard:
The snprintf function is equivalent to fprintf, except that the output is
written into an array (specified by argument s) rather than to a stream. If
n is zero, nothing is written, and s may be a null pointer. Otherwise,
output characters beyond the n-1st are discarded rather than being written
to the array, and a null character is written at the end of the characters
actually written into the array.
The vsnprintf function is equivalent to snprintf, with the variable
argument list replaced by arg
The output of the following code:
1. #include <stdio.h>
2. #include <errno.h>
3.
4. int main(void)
5. {
6. char buffer[3] = {0};
7. int ret = snprintf(buffer, sizeof(buffer), "%s", "abcd");
8.
9. for (int i = 0; i < 3; i++)
10. printf("%c", buffer[i]); /* should print "ab", does print "abc" */
11. printf("ret = %d, errno = %d\n", ret, errno);
12.
13. return 0;
14. }
is
abc
ret = -1, errno = 34
This was independently confirmed on another Windows 7 machine.
errno is ERANGE and this seems to indicate it is using _vsnprintf (from
msvcrt.dll?), at least it is similar in behavior to _vsnprintf_s, minus the
null-termination: https://docs.microsoft.com/en-us/cpp/c-runtime-library/
reference/snprintf-s-snprintf-s-l-snwprintf-s-snwprintf-s-l
If __USE_MINGW_ANSI_STDIO is defined as 1 before the stdio.h include, this
example does null-terminate, but I neither know what else that does entail, nor
does it help the case of non-conformity.
Out of curiosity, I installed an old mingw32 version from Sourceforge (which
seems to be from 2013?) and it did not have this issue.
A very simple but also very exhausting workaround is to always do:
1. int ret = snprintf(buffer, sizeof(buffer), "%s", "abcd");
2. if (ret < 0)
3. buffer[sizeof(buffer)-1] = '\0';
--
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/39512
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39512
------------------------------
Message: 3
Date: Thu, 05 Sep 2019 21:57:17 +0000
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #39512: v/snprintf don't
null-terminate when truncating
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#39512: v/snprintf don't null-terminate when truncating
Open Date: 2019-08-26 19:45
Last Update: 2019-09-05 21:57
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/39512
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39512
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2019-09-05 21:57 Updated by: lazybumhorse
Comment:
Reply To keith
Who cares? MSYS2 is not a product of this project; we do not support it.
Oh! This (and some more research) finally cleared my confusion!
I was under the impression MSYS2 had genuine MinGW packages, but the packages
are actually of MinGW-w64, which is a fork of this project and that is using
the MSVC printf family by default for whatever reason.
---------------------------------------------------------------------
Ticket Status:
Reporter: lazybumhorse
Owner: (None)
Type: Issues
Status: Closed
Priority: 5 - Medium
MileStone: (None)
Component: WSL
Severity: 5 - Medium
Resolution: Invalid
---------------------------------------------------------------------
Ticket details:
Using MSYS2 on Windows 7, snprintf and vsnprintf are not C99+ standard
compliant because they do not null-terminate when truncating.
Relevant excerpt from the C99 standard:
The snprintf function is equivalent to fprintf, except that the output is
written into an array (specified by argument s) rather than to a stream. If
n is zero, nothing is written, and s may be a null pointer. Otherwise,
output characters beyond the n-1st are discarded rather than being written
to the array, and a null character is written at the end of the characters
actually written into the array.
The vsnprintf function is equivalent to snprintf, with the variable
argument list replaced by arg
The output of the following code:
1. #include <stdio.h>
2. #include <errno.h>
3.
4. int main(void)
5. {
6. char buffer[3] = {0};
7. int ret = snprintf(buffer, sizeof(buffer), "%s", "abcd");
8.
9. for (int i = 0; i < 3; i++)
10. printf("%c", buffer[i]); /* should print "ab", does print "abc" */
11. printf("ret = %d, errno = %d\n", ret, errno);
12.
13. return 0;
14. }
is
abc
ret = -1, errno = 34
This was independently confirmed on another Windows 7 machine.
errno is ERANGE and this seems to indicate it is using _vsnprintf (from
msvcrt.dll?), at least it is similar in behavior to _vsnprintf_s, minus the
null-termination: https://docs.microsoft.com/en-us/cpp/c-runtime-library/
reference/snprintf-s-snprintf-s-l-snwprintf-s-snwprintf-s-l
If __USE_MINGW_ANSI_STDIO is defined as 1 before the stdio.h include, this
example does null-terminate, but I neither know what else that does entail, nor
does it help the case of non-conformity.
Out of curiosity, I installed an old mingw32 version from Sourceforge (which
seems to be from 2013?) and it did not have this issue.
A very simple but also very exhausting workaround is to always do:
1. int ret = snprintf(buffer, sizeof(buffer), "%s", "abcd");
2. if (ret < 0)
3. buffer[sizeof(buffer)-1] = '\0';
--
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/39512
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=39512
------------------------------
Subject: Digest Footer
_______________________________________________
MinGW-Notify mailing list
[email protected]
https://lists.osdn.me/mailman/listinfo/mingw-notify
------------------------------
End of MinGW-Notify Digest, Vol 24, Issue 2
*******************************************
