From: clubley@remove_me.eisner.decus.org-Earth.UFP   
      
   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.   
      
   --   
   Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP   
   Walking destinations on a map are further away than they appear.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)