From: antispam@fricas.org   
      
   David Brown  wrote:   
   > 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.   
      
   For me 'printf' is mainly a debugging helper.  Example of "important   
   interface" is X11.  Part of that interface is variadic and there is   
   no way around this.  Concerning safety, when using FFI there is   
   always problem of "passing" type information across the interface.   
   Smaller or bigger part of type information is provide by hand,   
   which in inherently unsafe.  The point is to minimize and   
   encapsulate this part so users can assume that it just works.   
   Variadic functions decrease safety, but IMO this is just modest   
   decrease compared to "normal" troubls with FFI.   
      
   Concerning "inefficient", in cases interesting to me FFI is   
   inefficient and variadic functions do not change this much.  Simply,   
   foreign calls are for serious, relatively expensive tasks.   
      
   And to make things clear: I do not advocate writing variadic   
   functions.  But there are already libraries exporting variadic   
   and FFI should allow using them.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)