https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737
--- Comment #23 from Jonathan Wakely <redi at gcc dot gnu.org> --- I prefer just forcing the use of vsprintf with a larger buffer, it avoids adding more complexity to the code. (In reply to dave.anglin from comment #22) > I prefer the first approach although it might loop if there is an > error. Probably, it needs > to check if the current __cs_size is less than the new __cs_size before > doing a retry. Yes, it needs to avoid looping forever. > Another option would be to just duplicate the code instead of branching > back. Yes, but it's already duplicated and I didn't want to add another one. > It's my understanding that the vsnprintf bug is fixed in 11.31 and some > HP-UX patch sets. > We win with the first approach when the initial buffer is large enough. > > It's possible for vsnprintf on linux to return a negative value if an > output error occurs. > So, there's some justification to check the return on linux. I'm not sure if an output error is ever possible when writing to a buffer (rather than to a file) when we control the format specification. I'll return to this another time.
