From: bc@freeuk.com
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.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
