From: david.brown@hesbynett.no   
      
   On 05/02/2026 20:22, Keith Thompson wrote:   
   > David Brown  writes:   
   >> On 05/02/2026 00:52, Bart wrote:   
   >>> On 04/02/2026 23:39, Keith Thompson wrote:   
   >>>> Bart  writes:   
   >>>> [...]   
   >>>>> The problem is that C expects an exact format-code when trying to use   
   >>>>> *printf functions, and for that you need to know the exact types of   
   >>>>> the expressions being passed. For example:   
   >>>>>   
   >>>>>     uintptr_t x;                    // from above   
   examples   
   >>>>>     double y;                       //   
   >>>>>     printf("x * y is %?", x * y);   // What's '?'   
   >>>>   
   >>>> Since you asked...   
   >>>>   
   >>>> '?' is 'f' (or 'g' or 'e', or 'a', or any of those in upper case).   
   >>>> `x * y` is of type double.   
   >>>   
   >>> The 'from above examples' applies to both x and y. That means that   
   >>> 'double' /may/ have been redefined like this (from my post):   
   >>>   
   >>>     #ifdef SQLITE_OMIT_FLOATING_POINT   
   >>>     # define double sqlite3_int64   
   >>>     #endif   
   >>>   
   >>> I don't know what 'sqlite3_int64' is, but it sounds like a signed   
   >>> integer.  I was asked to give examples of conditional types, and   
   >>> thought it best to do so from actual programs.   
   >>   
   >> What you have found is an idiocy in SQLITE, not a problem in the C   
   >> language or printf.  If the macro "SQLITE_OMIT_FLOATING_POINT" is   
   >> defined, then the type named "sqlite3_int64" is not an integer type,   
   >> nor can it hold arbitrary 64-bit integers (as Michael S pointed out,   
   >> and I assume accurately, it can hold 53 bit integers).  I do not know   
   >> what this type is used for in the code, but something like   
   >> "sqlite3_bignum" would be a far better choice of name.  And if it is   
   >> intended that people print out these values directly, defining   
   >> "PRsqlite3_bignum" to "%g" or "%llu" as appropriate would be helpful.   
   >> (Yes, the resulting printf statements would be ugly - better ugly and   
   >> correct than wrong).   
   >   
   > The macro doesn't define "sqlite3_int64", which as far as I can tell is   
   > always an integer type.  It redefines "double".   
      
   You are right - I was reading it as a typedef.   
      
   Redefining "double" with a macro expanding to an integer type (if that   
   is what "sqlite3_int64" is) is an even worse idea than my misinterpretation!   
      
   >   
   > That macro in isolation does seem deeply silly, but I haven't worked on   
   > sqlite3's source code.  Apparently the authors found it convenient.   
   > Presumably anyone working on the source code has to keep in mind that   
   > the word "double" doesn't necessarily mean what it normally means.  It's   
   > not the way I would have written it.  I probably would have defined a   
   > type name that can be either "double" or "sqlite3_int64", depending on   
   > the setting of SQLITE_OMIT_FLOATING_POINT.  But I don't know enough   
   > about the sqlite3 source code to be able to meaningfully criticize it.   
   >   
      
   I think we all know enough about C to criticise this.  Defining a macro   
   with the name of a keyword is UB - even if we assume that all people   
   reading the sqlite code understand what is going on.   
      
   > In almost all contexts, it's perfectly reasonable to assume that the   
   > word "double" in C code refers to the predefined floating-point type.   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)