From: news@cct-net.co.uk   
      
   On 15/08/2025 18:33, Simon Clubley wrote:   
   > On 2025-08-15, Dan Cross  wrote:   
   >> In article <107n93n$13rjm$1@dont-email.me>,   
   >> Simon Clubley   wrote:   
   >>> On 2025-08-12, Arne Vajhøj  wrote:   
   >>>> Code:   
   >>>>   
   >>>> #include    
   >>>>   
   >>>> #include    
   >>>>   
   >>>> my_bool demo_init(UDF_INIT *initid, UDF_ARGS *args, char *message)   
   >>>> {   
   >>>>       if(args->arg_count == 2 && args->arg_type[0] == STRING_RESULT &&   
   >>>> args->arg_type[1] == INT_RESULT)   
   >>>   
   >>> Is it guaranteed that arg_type[] will always have at least elements ?   
   >>> If not, that's dangerous unless the compiler you are using does   
   >>> expression short-circuiting.   
   >>   
   >> C is well-defined in this regard.  Boolean expressions in C,   
   >> created by combining logical subexpressions with the `&&` and   
   >> `||` operators, are documented to use short-circuiting behavior.   
   >>   
   >   
   > Thank you.   
   >   
   > Unless it's explicit in the language syntax itself, and given that   
   > I write code in multiple languages, I have long written code that   
   > assumes implicit[*] short-circuiting is not available.   
   >   
   > As such, whether implicit short-circuiting is available or not is   
   > not really that important to me, but I will admit I didn't realise   
   > C had it.   
   >   
   > [*] By implicit short-circuiting I mean something that's only defined   
   > in the language standard or implemented in a compiler, instead of some   
   > explicit syntax in the language itself to state short-circuiting is   
   > available.   
   >   
   >>   
   >> However, I must disagree strongly with the advice to use   
   >> `strncpy`, which is poorly understood and has strange semantics:   
   >> it will write as much of the source string to the destination as   
   >> it can, with or without the NUL terminating byte.  If the source   
   >> is smaller than the destination buffer, then the remainder of   
   >> the buffer will be filled with 0s.  If the source is exactly as   
   >> long as, or longer, than the destination, then the destination   
   >> will not be NUL-terminated.  Since it just returns the   
   >> destination pointer, there is no way to detect truncation other   
   >> than to test the last byte in the destination to see whether it   
   >> is zero or not.  So it is inefficent in the common case, and   
   >> dangerous and awkward in the exceptional case.  Moreover, its   
   >> behavior is orthogonal to that of `strncat`, which does _not_   
   >> have the "write 0s to all bytes in the destination past the end   
   >> of the what we copied from the source string", and is also   
   >> awkward in how it treats it's length argument: whereas for   
   >> `strncpy` the length argument is the size of the entire   
   >> destination buffer, for `strncat` it is not: `strncat` will   
   >> write up to n+1 bytes into the destination.   
   >>   
   >   
   > strncpy() makes more sense when you realise that its original purpose   
   > was to fill fixed-size fields in a record with data and to clear the   
   > rest of the field if the source data was smaller than the field size.   
   >   
   > BTW, after using strncpy(), my code always unconditionally places   
   > a 0x00 in the final byte of the buffer "just in case :-)".   
   >   
   > Simon.   
   >   
      
   That wouldn't be good if you are filling part of a record!   
      
   --   
   Chris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)