From: david.brown@hesbynett.no   
      
   On 08/02/2026 20:54, Bart wrote:   
   > On 08/02/2026 17:55, 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 about the last 30 years I've used the C library to do i/o, as it was   
   > simpler than Win32 calls. (I didn't even know it was supposed to be for   
   > C; it just look like an easier library with shorter function names, that   
   > also shipped with Windows.)   
   >   
   > So while I do do most of my own conversion and formating, actual i/o,   
   > and a few cases such as floating point which are fiddly, uses calls like   
   > this:   
   >   
   >      sprintf(s, "%f", x)   
   >      sscanf(str, "%lf%n", &x, &numlength)   
   >      printf("%.*s", length, s)   
   >      fprintf(f, "%.*s", length, s)   
   >   
   > The last two are generally called when I have a buffer-full of output.   
   >   
   > The sscanf call is the only I ever time use *scanf functions.   
   >   
   > In the prior 15 years of course, I did have to do everything.   
   >   
      
   Doing your print's by building up a C string in your own   
   language/runtime and then calling C's "printf("%s", p")" is safe and   
   should be simple enough to implement.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)