[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mingw-notify
Subject:    MinGW-notify digest, Vol 1 #711 - 1 msg
From:       mingw-notify-request () lists ! sourceforge ! net
Date:       2004-01-16 4:01:49
Message-ID: 200401160407.i0G47uQX019759 () mailer ! progressive-comp ! com
[Download RAW message or body]

Send MinGW-notify mailing list submissions to
	mingw-notify@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/mingw-notify
or, via email, send a message with subject or body 'help' to
	mingw-notify-request@lists.sourceforge.net

You can reach the person managing the list at
	mingw-notify-admin@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of MinGW-notify digest..."


This list is used to send updates of submitted patches, bug reports and file \
releases.  You are discouraged from posting to this list.  If you wish to unsubscribe \
you can do so at https://lists.sourceforge.net/lists/listinfo/mingw-notify.

Today's Topics:

   1. [ mingw-Bugs-877783 ] problem with snprintf and vsnprintf return values \
(SourceForge.net)

--__--__--

Message: 1
To: noreply@sourceforge.net
From: "SourceForge.net" <noreply@sourceforge.net>
Date: Thu, 15 Jan 2004 12:35:55 -0800
Subject: [Mingw-notify] [ mingw-Bugs-877783 ] problem with snprintf and vsnprintf \
return values

Bugs item #877783, was opened at 2004-01-15 20:35
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=877783&group_id=2435

Category: mingw runtime
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Rohrer (jcr13)
Assigned to: Nobody/Anonymous (nobody)
Summary: problem with snprintf and vsnprintf return values

Initial Comment:
There is a bug in the behavior of snprintf when the size of the buffer is exactly the \
same size as the string that needs to be printed into that buffer.

For the sake of discussion, here is the snprintf declaration:
int snprintf(char *str, size_t size, const  char  *format, ...);

General behavior:
MinGW's implementation returns -1 in general if there isn't enough room in the str \
buffer.  Though this is not C99-compliant, it still works according to the older \
snprintf convention (the C99 standard says that snprintf should return the number of \
characters that *would* have been printed if there had been enough room).

The Bug:
If the buffer is exactly the same size as the string to be printed, however, MinGW's \
snprintf returns the number of bytes printed, *as if* there was enough room.  In this \
case, there actually is not enough room for the terminating \0 character, so the str \
buffer is filled with an invalid string.  snprintf should return -1 in this case.

The same problem occurs with vsnprintf.


A similar problem was noted in Cygwin's snprintf function, with relevant discussion \
here: http://sources.redhat.com/ml/newlib/2000/msg00179.html


I have attached a test program that demonstrates this bug.  The program can be \
compiled with either gcc or g++ in MinGW.



On MinGW, the test program produces the following output:

Printed string of length 3 to buffer of size 4 with snprintf.
Return value = 3
Buffer was null-terminated by snprintf

Printed string of length 4 to buffer of size 4 with snprintf.
Return value = 4
Buffer was NOT null-terminated by snprintf

Printed string of length 5 to buffer of size 4 with snprintf.
Return value = -1
Buffer was NOT null-terminated by snprintf


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=877783&group_id=2435



--__--__--

_______________________________________________
MinGW-notify mailing list
MinGW-notify@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-notify


End of MinGW-notify Digest


[prev in list] [next in list] [prev in thread] [next in thread]