From: david.brown@hesbynett.no   
      
   On 05/02/2026 18:42, Bart wrote:   
   > On 05/02/2026 11:41, David Brown wrote:   
   >> On 04/02/2026 21:42, Bart wrote:   
   >   
   >> Usually when you have a type T in your code, you know some things   
   >> about it - you typically know if it is arithmetic, integer, floating   
   >> point, you know something about its range.   
   >   
   > How about time_t, clock_t, off_t?   
      
   What about them?  You know a lot about these types, and what they can be   
   used for.  You know if they are suitable for printf'ing directly, or   
   not, and how to either convert them to a suitable type directly or to   
   extract information from them.   
      
   >   
   >>   How much you know will vary, but a type you know absolutely nothing   
   >> about is unlikely to be of any use in code.   
   >   
   > The problem is that that format code is tied to the type of the   
   > expression. That means that as your program evolves and the types   
   > change, or the expression changes (so another term's type becomes   
   > dominant), then you have to check all such format codes.   
   >   
      
   If only there were a convenient way to handle this...  oh, wait, there   
   is.  Do as any competent programmer does when they have a complex   
   expression - assign the result to a local variable (/you/ pick the   
   type), rather than having too much in one huge printf.   
      
   >>>   
   >>>>> Yes maybe that particular strategy might work (you know it is an   
   >>>>> integer and that it is unsigned).   
   >>>>   
   >>>> What did you think an "uint32_t" was, if not a type of unsigned   
   >>>> integer?   And there is no "maybe" about it - the strategies work.   
   >>>   
   >>> See above.   
   >>>   
   >>>   
   >>>> If you have other arithmetic types, then you need to adapt the   
   >>>> strategy to fit - you need something that covers the ranges of the   
   >>>> data you are dealing with.   
   >>>>   
   >>>>>   
   >>>>> But it doesn't solve the general problem: even if there is a single   
   >>>>> type involved, it might be conditional or opaque (or its type is   
   >>>>> changed required all format codes to be revised.   
   >>>>>   
   >>>>> Or there is an expression of mixed types.   
   >>>>>   
   >>>>   
   >>>> There is no such thing as an "expression of mixed types".  There are   
   >>>> expressions formed with operators applied to subexpressions of   
   >>>> different types - the rules of C state very clearly how those   
   >>>> subexpressions are converted.  (For most binary operators, these are   
   >>>> the "usual arithmetic conversions".)  You know this too.   
   >>>   
   >>> An expression of mixed types means one that involves a number of   
   >>> different types amongst its types.   
   >   
   > (Here I meant 'amongst its terms'.)   
   >   
   >>   
   >> Okay, that's what /you/ mean by that phrase.  It is not an accurate   
   >> description - in any statically typed language, an expression will   
   >> have a single type.  Subexpressions can be different types.  But while   
   >> I do not approve of your terms here, I do understand what you are   
   >> talking about.   
   >>   
   >>> Sure, the rules will tell you what the result will be, but you have   
   >>> to work it out, and to do that, you have to know what each of those   
   >>> types are (again, see above).   
   >>   
   >> No, the /compiler/ has to work it out.  Whether /you/ need to work it   
   >> out or not, depends on what you are doing with the result.   
   >   
   > The compiler will not tell you the format codes to use!   
   >   
   >> If you have "T x;", and you write "(unsigned long) x" (as Keith   
   >> suggested), then you know the type of that expression - without   
   >> knowing the type of T.  You need to know that "T" is a type that can   
   >> be converted to "unsigned long" (any arithmetic or pointer type will   
   >> do), and you need to know that the value of "x" is suitable for the   
   >> conversion to be defined (so if "x" is floating point, it needs to be   
   >> in range).  If you don't know at least that much about "x", you   
   >> probably should not be writing code with it.   
   >   
   > I tried this program:   
   >   
   >    #include    
   >    #include "t.h"            // defines T   
   >   
   >    T F();   
   >   
   >    int main() {   
   >       T x;   
   >       x=F();   
   >       printf("%lu\n", (unsigned long)x);   
   >   }   
   >   
   > T happens to be 'int', and F() returns -1. This program however prints   
   > 4294967295.   
      
   Converting -1 to unsigned long gives you that result, yes.   
      
   Conversions do not absolve you from having to know what your code does,   
   and the obligation to write sensible code.  The conversion here means   
   your code does not have C undefined behaviour - it means the compiler   
   and run-time will do what you asked it to do.  It cannot stop you from   
   asking it to do something silly, or something you did not mean.  Again,   
   you /know/ this - it is fundamental to /all/ programming.  It is nothing   
   to do with C.   
      
   >   
   > If I change it so that T is 'long long int' and F returns 5000000000,   
   > then it shows 705032704. Not really ideal.   
   >   
   > Here a better bet for an unknown type is %f, which gives the right   
   > values, but it appear as -1.00000 etc.   
   >   
   > Better still is to use exactly the right format, but that has the issues   
   > I mentioned.   
   >   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)