From: arne@vajhoej.dk   
      
   On 6/26/2025 8:03 PM, Lawrence D'Oliveiro wrote:   
   > On Tue, 24 Jun 2025 12:25:50 -0400, Arne Vajhøj wrote:   
   >> The algorithm is basically to try vsnprintf with buffers increasing in   
   >> size 512, 1024, 1536, ... until there is space.   
   >>   
   >> That is very inefficient compared to just use the return value.   
   >   
   > It’s a good choice in the absence of any other clues as to how much to   
   > allocate. I have used it myself. (Of course having an explicit number   
   > returned is best of all.)   
   >   
   > One may conduct statistical analyses, I suppose to decide on the optimum   
   > multiplication factor. E.g. would going up in powers of 3 better than   
   > powers of 2? I suspect larger factors (too far from e = 2.71828 ...) would   
   > not be worth using.   
      
   The specific factor is not as important as using multiplication instead   
   of addition.   
      
   Starting at 512 going towards a 1 GB CLOB:   
      
   +512 => 2 million   
   *1.5 => 36   
   *2 => 21   
   *3 => 13   
      
   > And don’t forget to do a realloc(3) at the end, to trim the unused part of   
   > the last allocation.   
      
   That seems very natural.   
      
   But for FreeTDS dbfcmd then it has:   
      
   vasprintf call to format buffer   
   test of return value   
   dbcmd call with buffer   
   free call for buffer   
      
   No point in realloc.   
      
   And I suspect that the pattern is common: format, use   
   once and free immediately.   
      
   So I don't know if it makes sense.   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)