Christoph Terasa wrote:> Since MS refuses to support C99, the common practice is to use either > > sprintf_s: > http://msdn.microsoft.com/en-us/library/ce3zzk1k(v=VS.80).aspx > _snprintf_s: > http://msdn.microsoft.com/de-de/library/f30dzcf6(v=VS.80).aspx > > The former can be used as a drop-in replacement of snprintf via a > define, the latter takes an additional argument count which can limit > the bytes written to the buffer additionally.Hmm, the first can be used as a drop-in replacement for many but not all uses of ISO C99 snprintf. For the uses in FLAC, it should be sufficient, we just have to be careful not to rely on the return value.> DO NOT use > _snprintf: > http://msdn.microsoft.com/de-de/library/2ts7cx93(v=vs.80).aspx > > since this does not NULL terminate if the length of the buffer is equal > to the given buffer size (or larger than), and this differs from the std > behaviour as stated at e.g. http://linux.die.net/man/3/snprintfYes, now I remember, that one is horribly broken. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
Microsoft provides a surprisingly good (but proprietary) API inside strsafe.h. StringCchPrintfA can be substituted for snprintf but the return value is different. A small wrapper function around StringCchPrintfExA could get you enough information to emulate snprintf well. But sprintf_s might be good enough for the limited uses inside flac, as you said. Sent from my iPhone On Mar 14, 2013, at 9:09 PM, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote:> Christoph Terasa wrote: > >> Since MS refuses to support C99, the common practice is to use either >> >> sprintf_s: >> http://msdn.microsoft.com/en-us/library/ce3zzk1k(v=VS.80).aspx >> _snprintf_s: >> http://msdn.microsoft.com/de-de/library/f30dzcf6(v=VS.80).aspx >> >> The former can be used as a drop-in replacement of snprintf via a >> define, the latter takes an additional argument count which can limit >> the bytes written to the buffer additionally. > > Hmm, the first can be used as a drop-in replacement for many but > not all uses of ISO C99 snprintf. For the uses in FLAC, it should > be sufficient, we just have to be careful not to rely on the return > value. > >> DO NOT use >> _snprintf: >> http://msdn.microsoft.com/de-de/library/2ts7cx93(v=vs.80).aspx >> >> since this does not NULL terminate if the length of the buffer is equal >> to the given buffer size (or larger than), and this differs from the std >> behaviour as stated at e.g. http://linux.die.net/man/3/snprintf > > Yes, now I remember, that one is horribly broken. > > Erik > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > _______________________________________________ > flac-dev mailing list > flac-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev
Ben Allison wrote:> Microsoft provides a surprisingly good (but proprietary) API inside > strsafe.h.All of which are completely useless from cross platform code. I remember looking at that stuff at some time and thinking that their API design was somewhat lacking in clarity or vision (to be gentle).> StringCchPrintfA can be substituted for snprintf but the return value > is different.Thats a big enough difference to make its use highly inconvenient.> A small wrapper function around > StringCchPrintfExA could get you enough information to emulate snprintf > well.Sigh, but why not just support the ISO C99 standard snprintf?> But sprintf_s might be good enough for the limited uses inside flac, as you said.It is for current usage. I am concerned that all future usage of snprintf needs be aware of the differences between the ISO C99 version and the Microsoft version. I suspect the best way to avoid this is wrap both inside a flac specific API and only use the flac specific version. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/