From: Quasar Newsgroups: comp.os.msdos.djgpp Subject: Re: Alternative to fcvt for older DJGPP? Date: 05 Aug 2003 20:22:36 GMT Organization: Concentric Internet Services Lines: 29 Message-ID: <4rw9rwdkr79y.zcwp8703cfrt.dlg@40tude.net> References: <76uzeozd7s3g.1sgoajp58hmqa$.dlg AT 40tude DOT net> <2_pXa.4525$kP6 DOT 1393 AT newsread2 DOT news DOT atl DOT earthlink DOT net> NNTP-Posting-Host: 66.238.153.147 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit User-Agent: 40tude_Dialog/2.0.3.1 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Mon, 04 Aug 2003 09:48:46 GMT, Martin Ambuhl wrote: > Just use sprintf(); there is no function called "fcvt" in the standard C > libraries, while sprintf is there. Even those of us who are die-hard > gcc fans know to avoid non-portable constructs when there is an > acceptable solution in the standard libraries. That sounds good, but there's several arguments against it, some of which are application specific. 1. Many strings can be replaced via user editing facilities. A hard limit on the number of characters in the resultant string can't be guaranteed, so this would open up a lot of security and usability issues. 2. I can't always be sure how many characters the resultant string will contain to begin with. I'm not sure exactly what the standard says for sprintf's behavior, but I can't accept having buffers being overflowed or not ending up null-terminated. Also, even if a string has not been initialized before use, snprintf will not cause a buffer overflow. I always initialize my own buffers, but this large program has been worked on by many people before, and some of them did not. This caused serious instability, where changes in one distant part of the program would suddenly cause buffer overflows elsewhere. With snprintf, its not a concern any more. 3. There's still the whole issue with buggy implementations in some libc's, even when snprintf is available on the platform. James