From: james.harris.1@nospicedham.gmail.com   
      
   On 01/07/2017 10:45, Rod Pemberton wrote:   
   > On Sat, 1 Jul 2017 07:56:50 +0100   
   > James Harris  wrote:   
   >   
   >> On 01/07/2017 03:18, Rod Pemberton wrote:   
      
   Since we're getting completely on to C (and you don't like comp.lang.c)   
   I've set followups to comp.lang.misc. OK with you?   
      
   >   
   >>> [...]   
   >> As I've said before, I dislike casts for the very reason that they   
   >> disable useful warnings.   
   >   
   > They also allow valid conversions which the type system may prevent.   
   >   
   > E.g., in certain situations, you need the dereferenced pointer type to   
   > be the same type as the original, i.e., address interpreter.   
      
   Can you give an example?   
      
   >   
   > E.g., the %p pointer format for printf() is implementation defined,   
   > i.e., not available, faulty, weird format, etc.  So, I prefer to cast   
   > to unsigned long so that I can emit the address as formatted hex.   
      
   OK.   
      
   >   
   > E.g., you have a pointer to some type, such as a struct, which you   
   > need to treat as an array of chars, e.g., copy, fix endianness,   
   > scramble/encode, translate, zero-fill, etc.   
      
   * Structs might be copyable to/from functions, and assignable.   
      
   * There are usually more portable ways to handle endianness differences,   
   though i accept that C is not well provided with handy routines.   
      
   * Ditto encoding and other operations which need access to the bytes.   
      
   * I am not sure what you mean by translate.   
      
   * Zero fill can be done with memset.   
      
      
   One good reason to use casts is because C's literals can be untyped. For   
   example,   
      
      #define SIZE 400   
      
      printf("%l", SIZE);   
      
   The function call might fail but only on a big endian machine - a nasty   
   gotcha that you could miss in testing.   
      
   You could fix it with   
      
      printf("%l", (long) SIZE);   
      
   Or, maybe better, you could include the type in the definition.   
      
      #define SIZE ((long) 400)   
      
      
   But many, many uses of casts mask problems. And they also prevent   
   compilers issuing useful warnings. C's type system is there to help   
   programmers, not hinder them.   
      
      
   >   
   >>> If I was designing a language like C today, signed integers would   
   >>> not be present.   
   >>   
   >> By that, aren't you undermining the premise of the very algorithm we   
   >> are discussing? It returns the difference between two byte values as   
   >> in   
   >>   
   >>     return s1[i] - s2[i];   
   >>   
   >> Surely the fact that that could be -ve, zero, or +ve is intended to   
   >> be useful. If you ruled out signed numbers then the function could   
   >> not work in the same way.   
   >>   
   >   
   > True.  Maybe, I should allow int to be signed, but then again.   
   >   
   > How many C functions return three conditions?  Is there any use for two   
   > true (non-zero) states?  Won't true and false generally suffice?  The   
   > OP was using qsort(), IIRC.  So, he may have needed 3 values, but   
   > normally, I only need to know if a string compare was a match or not.   
   > ATM, I can't think of any functions with 3 return states where I need   
   > 3-states.   
   >   
   > Isn't the fact that a function uses subtraction to compute a return   
   > value more likely to be the reason for 3-states "-ve, zero, or +ve"   
   > than the fact that 3-states are somehow useful?   
      
   I guess the idea is that the return from strcmp matches the sense of one   
   string being less than, less than or equal to, equal to, not equal to,   
   greater than or equal to, or greater than another. All six tests are   
   possible from a single return value. That's pretty cool!   
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)