------- Additional Comments From ghazi at gcc dot gnu dot org 2005-06-10 12:55 ------- (In reply to comment #25) > Subject: Re: GCC should combine adjacent stdio > calls > On Fri, 10 Jun 2005, ghazi at gcc dot gnu dot org wrote: > > Case (b) involves fmemopen, and I assume you refer to a case where you open > > memory for writing, printf to the resulting FILE*, and pass a pointer to > > the memory area back into printf. This can only lead to disaster as you > > clobber the same memory you are reading from. Since fmemopen is a gnu > > extension, it can do whatever it wants, but I suspect you're entering > > unspecified territory here for C programs. > > > We support programs which use functions other than the standard C ones - > naturally as the compiler for the GNU system we support extensions in the > GNU libraries. The example I gave used %.5s specifically so that it would > only look at bytes with known values (if the programmer knows something > about the possible values of the integer written) and not at bytes being > modified by the printf.
My point about gnu extensions, is that for corner cases like this we don't have a reliable standards document to make judgements from. We're essentially relying on the code as a reference implementation. So "it can do whatever it wants." With regards to "%d" followed by "%.5s", I don't see any difference regardless of the buffering mode between two printfs and one in how soon the "%.5s" will see the results of the "%d". In buffered mode, you probably won't see it regardless unless you happen to hit BUFSIZ just right. In unbuffered mode, a correctly flushed printf will make the "%d" available. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
