From: craigberry@nospam.mac.com   
      
   On 6/24/25 7:38 PM, Arne Vajhøj wrote:   
   > On 6/24/2025 12:25 PM, Arne Vajhøj wrote:   
   >> I don't like the #elif HAVE_VSNPRINTF code in tds_vasprintf.   
   >>   
   >> :-)   
   >>   
   >> 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.   
   >>   
   >> And since it does not use va_copy, then only the first call to   
   >> vsnprintf will work.   
   >   
   > Even if va_copy was called and we ignore the option of   
   > using vsnprintf return value, then +512 is not good   
   > compared to *2. +512 with a 1 GB CLOB value would mean   
   > 2 million calls to vsnprintf.   
   >   
   > (I have not checked if TDS actually allow that long   
   > statements, but +512 is a problem)   
      
   TDS packet length is negotiated but must be between 512 and 32,767 bytes:   
      
   https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms   
   tds/c1cddd03-b448-470a-946a-9b1b908f27a7   
      
   And vasprintf appears to be used in FreeTDS only for query strings and   
   commands, not for data.   
      
   You aren't wrong, but improving the vasprintf implementation isn't my   
   highest priority; feel free to take a crack at it and submit a PR.  To   
   work against current sources, you either need to use autoconf with a git   
   checkout or get a nightly snapshot from .   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)