Greg Chicares | 1 Feb 2005 07:03
Picon

snprintf defects [Was: Wrong endptr in strtold()]

On 2005-01-31 17:01 PM, Egon Andersen wrote:
> 
> Just for the fun, try to snprintf a double with 2 decimals e.g. ".2f" 
> and let the value be infinity.
> I get as result something like "1.#J"
> I think it is time to make a proper implementation of snprintf() not 
> based on M$

Other snprintf problems:

     char buf[100] = "zzzzzzzzz";
     std::cout << snprintf(buf, 0, "%4d", 1234) << '\n'; // Should equal 4.
     std::cout << snprintf(buf, 3, "%4d", 1234) << '\n'; // Should equal 4.
     std::cout << std::string(buf, 9) << '\n'; // Should be "12\0zzzzzz\0".
     snprintf(buf, 4, "%4d", 1234);
     std::cout << std::string(buf, 9) << '\n'; // Should be "123\0zzzzz\0".

With the latest release, I get

-1
-1
123zzzzzz
1234zzzzz

I think it's always been that way.

MinGW's sprintf() calls _vsnprintf(), which is known to be defective:
   http://www.gotw.ca/publications/mill19.htm
   "In particular, under one major implementation, if the output fills
   or would overflow the buffer then the buffer is not zero-terminated."
(Continue reading)

Wu Yongwei | 1 Feb 2005 09:02

Re: snprintf defects [Was: Wrong endptr in strtold()]

Whether they should be "fixed" to be standard-conformant depends on the 
user group:

* How many MinGW users have migrated from MSVC and share code base with 
it?

vs.

* How many MinGW users have migrated from Linux GCC (or other more 
conformant systems) and share code base with it?

I think the MSVC behaviour is in some ways the de facto standard on 
Windows. But are there many MinGW users that are used to the MSVC way? I 
am inclined to think the latter group is bigger than the former, but 
AFAIK, developers are never good at guessing others' requirements.

Best regards,

Yongwei

Greg Chicares <chicares@...>
From:  mingw-users-admin@...

 
        To:     mingw-users@...
        CC: 
        Subject:        [Mingw-users] snprintf defects [Was: Wrong endptr in strtold()]

On 2005-01-31 17:01 PM, Egon Andersen wrote:
> 
(Continue reading)

Egon Andersen | 1 Feb 2005 10:43
Picon

Re: snprintf defects [Was: Wrong endptr in strtold()]

Wu Yongwei wrote:
> Whether they should be "fixed" to be standard-conformant depends on the 
> user group:
> 
> * How many MinGW users have migrated from MSVC and share code base with 
> it?
> 
> vs.
> 
> * How many MinGW users have migrated from Linux GCC (or other more 
> conformant systems) and share code base with it?
> 
> I think the MSVC behaviour is in some ways the de facto standard on 
> Windows. But are there many MinGW users that are used to the MSVC way? I 
> am inclined to think the latter group is bigger than the former, but 
> AFAIK, developers are never good at guessing others' requirements.
> 

Well, when the --std=c99 is used during compilation, I expect ISO-C99 to 
be the standard - at least the direction is towards ISO-C99.
There are lot of stuff in MinGW that is not supported by native MSVC anyway.

I not asking for Linux GCC behaviour, I'm asking for International 
Standard, at least when I use compilation flags for that.
(I know that the flags are not really related to the snprintf(), as it 
is a function in the msvcrt library, but it would be reasonable to work 
for standard conforming implementations/library replacement.)

And I think that the second group is bigger than the former too.
Probably because if you already have MSVC you would probably continue to 
(Continue reading)

Leif W | 1 Feb 2005 14:00
Picon

Re: Which files do I need to download?

> Foster, Gareth; 2005 January 31 Monday 08:59
>
> agree entirely with the comments made about the state of it. That 
> said, I
> don't want to bitch, I'm sure all is well once you have gotten as far 
> as
> installing the thing.

These are of course the GNU tools which I know and love/hate from Linux. 
;-)  But since I have no access to Linux right now, it raises the whole 
desire for portable tools and applications.  So if I write code in 
Windows, I'd like to be able to port it to Linux in the future with 
minimal difficulty.  I have no doubt of it's usefulness once I get 
everything the way I want it.

Well, it's a natural tendency to gripe.  :p  I hope I wasn't too bad at 
it.  I'm not just dropping an inflamatory comment and running away.  I'd 
like to help, but practical contributions will be limited to text-only, 
non-network stuff, like scripts to parse data and HTML output, or using 
a network library or external program so I fetch data from a URL, and no 
GUI stuff (unless I strike extreme enlightment in a short time).  As I 
have no idea how the data is actually retrieved or what script parses 
and formats that data for presentation, I used JavaScript as a 
concept-modelling language and have worked out some logic to streamline 
to entire look of the table.

1) Flat table, with rowspans, no nested tables.
2) border=1, cellpadding=1, cellspacing=0
3) combined date and time to 2005-02-01 <at> 06:50 format, 2->1 columns.
4) Page size from 88 kb to 58 kb.
(Continue reading)

Leif W | 1 Feb 2005 14:10
Picon

Re: Which files do I need to download?

> John Gaughan; 2005 January 31 Monday 13:13
>
> Leif W wrote:
>
> I think it would make more sense to separate out RCs, old versions, 
> and current. Put current at the top, since this is what newbies need. 
> Put the rest on a different page or clearly separated, not in the same 
> table. Then separate the source out, so a user could see the first few 
> packages at the top and think "hey, that's what I need."

Again, this is an intriguing idea.  And again, I would expand upon it, 
to have a configurable listing, and store settings in a cookie.  It can 
be handy to see the bin & src all next to each other, so you can quickly 
spot if one is missing, or get everything in one place without looking 
all over.  This might be the "Advanced" layout, one monolithic table. 
Maybe an Intermediate would have everything grouped into categories, 
with each category in a separate table, and preceeded with a brief 
description of the meaning of the category.  I'd put RC first and 
Current second, or maybe Current first and RC second.  Or make the order 
configurable.  Configurable if sources should be in a separate table or 
integrated in the same table alongside the bins.  And the "Beginner" 
configuration would have only the "Current", and binary in the first 
table, sources in a second table, and an option to integrate.

> a little extra time to find the relevant versions. Of course with the 
> network installer this won't be as much of an issue, but it might be 
> worth doing.
>
> BTW, Earnie, I am back from my job training and can start work on the 
> network installer. I will download the installer package tonight and 
(Continue reading)

Leif W | 1 Feb 2005 14:34
Picon

Re: Which files do I need to download?

> Earnie Boyd; 2005 January 31 Monday 16:51
>
> The layout for the www.mingw.org/download.shtml#hdr2 is created with 
> the
> mkRelease.tcl script as found in CVS in the scripts module.  Place 
> your
> patches at https://sourceforge.net/tracker/?group_id=2435&atid=302435

I'm not too familiar with TCL but it seems pretty straightforward.  But 
what I wonder, is at what point is the script called?  Briefly looking, 
I guess it generates only the table, which is included in the 
download.shtml page, which should be enough to test locally with some 
path changes.  Is this correct?

Leif

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
MinGW-users mailing list
MinGW-users@...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

Foster, Gareth | 1 Feb 2005 14:40
Picon

RE: Which files do I need to download?

I have the following,

gtk-win32-devel-2.4-rc26.exe
gtkmm-devel-2.4.8-2.exe

I think they would work fine if I had a working minGW install.

Gaz

-----Original Message-----
From: mingw-users-admin@...
[mailto:mingw-users-admin@...] On Behalf Of Leif W
Sent: 01 February 2005 13:01
To: mingw-users@...
Subject: Re: [Mingw-users] Which files do I need to download?

> Foster, Gareth; 2005 January 31 Monday 08:59
>
> agree entirely with the comments made about the state of it. That 
> said, I
> don't want to bitch, I'm sure all is well once you have gotten as far 
> as
> installing the thing.

These are of course the GNU tools which I know and love/hate from Linux. 
;-)  But since I have no access to Linux right now, it raises the whole 
desire for portable tools and applications.  So if I write code in 
Windows, I'd like to be able to port it to Linux in the future with 
minimal difficulty.  I have no doubt of it's usefulness once I get 
everything the way I want it.
(Continue reading)

Greg Chicares | 1 Feb 2005 14:49
Picon

Re: snprintf defects [Was: Wrong endptr in strtold()]

On 2005-02-01 03:02 AM, Wu Yongwei wrote:

> Whether they should be "fixed" to be standard-conformant depends on the 
> user group:
> 
> * How many MinGW users have migrated from MSVC and share code base with 
> it?
> 
> vs.
> 
> * How many MinGW users have migrated from Linux GCC (or other more 
> conformant systems) and share code base with it?

I don't know. I think a more important question is how many people
consider MinGW standard-conforming behavior to be a problem when it
deviates from whatever another compiler has done.

> I think the MSVC behaviour is in some ways the de facto standard on 
> Windows. But are there many MinGW users that are used to the MSVC way? I 
> am inclined to think the latter group is bigger than the former, but 
> AFAIK, developers are never good at guessing others' requirements.

Do people who also use the ms compiler actually expect behavior
that contradicts section 7.19.6.6 of the C99 standard? This
google search:
   snprintf site:microsoft.com
returns only two matches, but this one:
   _snprintf site:microsoft.com
returns 95. So I'd guess that anyone who follows the ms way
would use '_snprintf'. I don't mind if such a function is
(Continue reading)

Jeremy Bettis | 1 Feb 2005 16:41

Re: snprintf defects [Was: Wrong endptr in strtold()]

I know from my perspective, it is more important for me to be able to ship 
binaries which have no dll dependancies other than MSVCRT.dll and friends.

If there were a libfunctionsthatarebrokeninmsvcrtandneedreplaced.lib so that 
a user could choose to link with it or not, that would be ideal.  I don't 
even care if it is used by default, just so I could shut it off as 
necessary.

----- Original Message ----- 
From: "Egon Andersen" <post@...>
To: <mingw-users@...>
Sent: Tuesday, February 01, 2005 3:43 AM
Subject: Re: [Mingw-users] snprintf defects [Was: Wrong endptr in strtold()]

> Wu Yongwei wrote:
>> Whether they should be "fixed" to be standard-conformant depends on the 
>> user group:
>>
>> * How many MinGW users have migrated from MSVC and share code base with 
>> it?
>>
>> vs.
>>
>> * How many MinGW users have migrated from Linux GCC (or other more 
>> conformant systems) and share code base with it?
>>
>> I think the MSVC behaviour is in some ways the de facto standard on 
>> Windows. But are there many MinGW users that are used to the MSVC way? I 
>> am inclined to think the latter group is bigger than the former, but 
>> AFAIK, developers are never good at guessing others' requirements.
(Continue reading)

Michael Gerdau | 1 Feb 2005 17:21
Picon
Favicon

Re: snprintf defects [Was: Wrong endptr in strtold()]

> Whether they should be "fixed" to be standard-conformant depends on the 
> user group:

I don't think so.

IMO if the standard asks for a certain behavior MinGW should stick
with the standard.

In fact there already are quite a few areas where gcc toolchain
(and thus MinGW) differs from MSVC. To that end my code contains
quite a few #ifdefs.

Most notably this is true for the broken NaN-Handling in MSVC 6.0.
In MSVC 7 and later this is mostly corrected (finally).

Just because MSVC is broken is no reason for MinGW to be broken too.

Maintaining backwards compatibility with known bugs IMO should not
be on the agenda of MinGW unless there is a strong reason for it
(like otherwise most other code would break).

Functions like snprintf that probably aren't used that often anyway
IMO do not qualify for being "a strong reason".

Last not least as someone (Danny?) already pointed out:
with C99 compliance enabled we need it anyway.

Best,
Michael
--

-- 
(Continue reading)


Gmane