From: david.brown@hesbynett.no   
      
   On 08/02/2026 17:50, Waldek Hebisch wrote:   
   > Michael S  wrote:   
   >> On Fri, 6 Feb 2026 13:04:34 +0000   
   >> Bart  wrote:   
   >>   
   >>> On 06/02/2026 12:47, Michael S wrote:   
   >>>> On Fri, 6 Feb 2026 12:39:55 +0000   
   >>>> Bart  wrote:   
   >>>>   
   >>>>> On 06/02/2026 05:10, Keith Thompson wrote:   
   >>>>>> Bart  writes:   
   >>>>>> [...]   
   >>>>>>> /Some/ compilers with /some/ options will /sometimes/ tell you   
   >>>>>>> when you've got it wrong.   
   >>>>>>>   
   >>>>>>> But you first have to make an educated guess, or put in some   
   >>>>>>> dummy format code.   
   >>>>>>>   
   >>>>>>> Eventually, it will compile. Until someone else builds your   
   >>>>>>> program, using a slightly different set of headers where certain   
   >>>>>>> types are defined, and then it might either give compiler   
   >>>>>>> messages that they have to fix, or it show wrong results.   
   >>>>>>   
   >>>>>> That's not how I do it, and I don't think it's how most   
   >>>>>> programmers do it.   
   >>>>>>   
   >>>>>> I know the rules well enough that I can usually write a correct   
   >>>>>> format string in the first place.  If I make a mistake, gcc's   
   >>>>>> warnings are a nice check.   
   >>>>>   
   >>>>> I guess you've never used printf-family functions via the FFI of   
   >>>>> another language!   
   >>>>>   
   >>>>>   
   >>>>   
   >>>> Vararg via FFI? Is it really a good idea?   
   >>>>   
   >>>   
   >>> It's covered by platform ABIs of both Windows and SYS V.   
   >>>   
   >>   
   >> My question was not about technical possibility. I understand that with   
   >> enough of effort everything is possible.   
   >> I asked whether it is a good idea.   
   >> Is not it simpler for you and for your potential users to declare that   
   >> your language can not call external C functions with variable number of   
   >> arguments? To me it does not sound like this ability is either necessary   
   >> or very valuable.   
   >>   
   >> Above I assume that we are talking about your scripting language.   
   >>   
   >> W.r.t. your other language, I have no strong opinion. But my weak   
   >> opinion is that it also does not need it, possibly with exception for   
   >> ability to do few (very few, hopefully) historically idiotically   
   >> defined Unix system calls that can be handled individually as special   
   >> cases.   
   >   
   > Well, some important interfaces depend on varargs functions.  And   
   > while you may handle such cases via user-written wrappers, it is   
   > much nicer if FFI machinery handles varargs.   
   >   
      
   There are only a few standard C functions that are variadic, but they   
   are quite important ones (with the *printf family at the top).  But   
   there is little doubt that C's handling of variadic functions is very   
   unsafe, and implementations are often challenging (the SysV ABI for   
   x86-64 is awkward and complex for variadic functions - the Win64 ABI is   
   easier for variadics at the expense of making many other function calls   
   less efficient).  It is a weak point in the design of C.   
      
   And for other languages trying to access C code via a FFI, variadic   
   functions are going to be inefficient, complicated, and unsafe (unless   
   you are /very/ sure of the calling parameters).  If your alternative   
   language is safer, neater, or easier to write than C (and if it isn't,   
   why bother with it?), you'll want a better way to handle formatted   
   printing than C's printf.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)