Who has actually used a variadic function for any purpose other than
implementing printf-style format strings?

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 2024-01-19, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> Who has actually used a variadic function for any purpose other than
> implementing printf-style format strings?

1. The fellows that designed some of the exec family syscalls in Unix.

2. Catenation of multiple strings. This type of thing:

cat_str(target, s1, s2, s3, ..., (char *) 0);

3. Similarly, constructing a list of elements:

make_list(e1, e2, ..., NOTVAL);

4. Emulating a fixed, optional argument in certain situations.
Example of this is the open function in POSIX.

int open(const char *pathname, int flags);
int open(const char *pathname, int flags, mode_t mode);

The mode requirement is only required if the flags indicate
creation, and this is implemented as:

int open(const char *, int, ...);

I have done a very similar thing a handful of times.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> Who has actually used a variadic function for any purpose other than
> implementing printf-style format strings?

execl(), execlp(), and execle() (specified by POSIX) are variadic.

The open() system call is variadic, since its mode argument is optional.
So are fcntl() and ioctl().

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Fri, 19 Jan 2024 17:59:18 +0000, Malcolm McLean wrote:

> Who has actually used a variadic function for any purpose other than
> implementing printf-style format strings?

GEGL and BABL <https://gegl.org/> have lots of these. For example, from
/usr/include/gegl-0.4/gegl-apply.h:

/**
* gegl_apply_op:
* @buffer: the #GeglBuffer to apply onto
* @operation_name: name of the operation to apply
* @...: the settings for the operation. Zero or more key/value pairs,
* ended terminated with NULL.
*
* Apply the operation to buffer, overwritting the contents of buffer.
*
*/
void gegl_apply_op (GeglBuffer *buffer,
const gchar *operation_name,
...) G_GNUC_NULL_TERMINATED;

On Fri, 19 Jan 2024 17:59:18 +0000, Malcolm McLean wrote:

> Who has actually used a variadic function for any purpose other than
> implementing printf-style format strings?

I've used the IMSL C library for several programs. Each function in that
library took a fair number of optional argument groups. Each group
started with an integer identifying which group it was. The types of the
arguments varied from one option group to another. The IMSL functions
had to use the option group ID to determine what types to pass to
va_arg() when retrieving the values of those arguments. A special
integer value was reserved to indicate that there were no more optional
arguments.

We had to deliver our code to many different users, some of whom had
licenses for the IMSL library, and others that didn't. I created a
pseudo-IMSL library, whose functions had the same name and interface as
the the actual IMSL library. The actual functions were a very limited
subset of the actual IMSL library, and had seriously constrained
functionality. For instance, we only needed cubic splines, so my
replacement for the IMSL spline routine treated requests for splines of
all other orders as errors. I wrote them based upon publicly available
algorithms and black-box testing to determine how the real IMSL
functions dealt with various error conditions and corner cases. I was
surprised to find that they failed to catch a number of error
conditions, but I wrote bug-compatible substitutes that failed in
exactly the same way. I never looked at the actual IMSL code. The
comments inside those functions clearly credited both IMSL and the
public sources I used for those algorithms.

I informed my superiors of what I was doing, and asked them to check
with the company's lawyers to find out whether I was violating any
intellectual property laws. They never got back to me. We delivered my
minimum IMSL clone library to those of our users who didn't have IMSL
licenses.

On 19.01.2024 18:59, Malcolm McLean wrote:
> Who has actually used a variadic function for any purpose other than
> implementing printf-style format strings?

In "own" projects only rarely. One was for debugging with nested macros
that finally lead to, yes, printf arguments. (That was decades ago, so
memories are faint about other applications.) Later in C++ I used other
code patterns for such purposes.

Janis

On 20/01/2024 10:15, Janis Papanagnou wrote:
> On 19.01.2024 18:59, Malcolm McLean wrote:
>> Who has actually used a variadic function for any purpose other than
>> implementing printf-style format strings?
>
> In "own" projects only rarely. One was for debugging with nested macros
> that finally lead to, yes, printf arguments. (That was decades ago, so
> memories are faint about other applications.) Later in C++ I used other
> code patterns for such purposes.
>
> Janis
>
Yes. It seems there are a few libraries that also use variadic
arguments. I tend not to do that sort of programming and I'm not very
familar with them.
But no-one has yet come up with an occasion where they implemented a
variadic function by choice, for code which they controlled, except for
printf style formatting. Either a hobby project or work code for which
they had ownership.
The obvious candidates are functions like min() or max(), but because of
the way C implements variadic functions, these aren't suitable.
min(2,a,b)is unacceptable because too easily confused with min3(2.0, a, b).

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On Sat, 20 Jan 2024 11:19:57 +0000
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> Yes. It seems there are a few libraries that also use variadic
> arguments. I tend not to do that sort of programming and I'm not very
> familar with them.
> But no-one has yet come up with an occasion where they implemented a
> variadic function by choice, for code which they controlled, except for
> printf style formatting. Either a hobby project or work code for which
> they had ownership.

I asked a similar question on this group many years ago. One example given
was a function for concatenating strings which would accept as arguments a
variable number of strings.

> The obvious candidates are functions like min() or max(), but because of
> the way C implements variadic functions, these aren't suitable.
> min(2,a,b)is unacceptable because too easily confused with min3(2.0, a, b).

On 20/01/2024 16:52, Spiros Bousbouras wrote:
> On Sat, 20 Jan 2024 11:19:57 +0000
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> Yes. It seems there are a few libraries that also use variadic
>> arguments. I tend not to do that sort of programming and I'm not very
>> familar with them.
>> But no-one has yet come up with an occasion where they implemented a
>> variadic function by choice, for code which they controlled, except for
>> printf style formatting. Either a hobby project or work code for which
>> they had ownership.
>
> I asked a similar question on this group many years ago. One example given
> was a function for concatenating strings which would accept as arguments a
> variable number of strings.
>
I've sometimes written a "cat" function. But I always write it to take
two strings. However I don't do much text processing.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 20/01/2024 16:58, Malcolm McLean wrote:
> On 20/01/2024 16:52, Spiros Bousbouras wrote:
>> On Sat, 20 Jan 2024 11:19:57 +0000
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>>> Yes. It seems there are a few libraries that also use variadic
>>> arguments. I tend not to do that sort of programming and I'm not very
>>> familar with them.
>>> But no-one has yet come up with an occasion where they implemented a
>>> variadic function by choice, for code which they controlled, except for
>>> printf style formatting. Either a hobby project or work code for which
>>> they had ownership.
>>
>> I asked a similar question on this group many years ago. One example
>> given
>> was a function for concatenating strings which would accept as
>> arguments a
>> variable number of strings.
>>
> I've sometimes written a "cat" function. But I always write it to take
> two strings. However I don't do much text processing.
>

Did you not see Kaz's reply? This was his 2nd example.

On Sat, 20 Jan 2024 11:19:57 +0000, Malcolm McLean wrote:

> But no-one has yet come up with an occasion where they implemented a
> variadic function by choice, for code which they controlled ...

But the people who created these libraries we mentioned certainly did.

On 20/01/2024 21:37, Lawrence D'Oliveiro wrote:
> On Sat, 20 Jan 2024 11:19:57 +0000, Malcolm McLean wrote:
>
>> But no-one has yet come up with an occasion where they implemented a
>> variadic function by choice, for code which they controlled ...
>
> But the people who created these libraries we mentioned certainly did.
>
I was wrong. As was pointed out eslewhere. Kaz gave some examples. But
his first was of usage.

Of course someone must have taken the decision that the call to evoke an
external process would take a variable list of arguments rather than a
single string. However In find that, of thousands of functions in my
code base, not a single one is variadic except a few interfaces to vsprintf.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On Sat, 20 Jan 2024 22:37:48 +0000, Malcolm McLean wrote:

> Of course someone must have taken the decision that the call to evoke an
> external process would take a variable list of arguments rather than a
> single string.

And it can play merry hell with typesafeness. Though I was able to come up
with typesafe Python wrappers, for example, around the variadic functions
in those libraries I mentioned earlier.

On 20/01/2024 22:37, Malcolm McLean wrote:
> On 20/01/2024 21:37, Lawrence D'Oliveiro wrote:
>> On Sat, 20 Jan 2024 11:19:57 +0000, Malcolm McLean wrote:
>>
>>> But no-one has yet come up with an occasion where they implemented a
>>> variadic function by choice, for code which they controlled ...
>>
>> But the people who created these libraries we mentioned certainly did.
> >
> I was wrong. As was pointed out eslewhere. Kaz gave some examples. But
> his first was of usage.
>
> Of course someone must have taken the decision that the call to evoke an
> external process would take a variable list of arguments rather than a
> single string. However In find that, of thousands of functions in my
> code base, not a single one is variadic except a few interfaces to
> vsprintf.

Variadic functions were likely added to implement *printf functions,
since the language didn't want to make special provision just for those.

Then a number of people decided to make use of the feature, although
less often than you might expect.

But it is not a desirable feature for general use as it is not type-safe.

The other thing is, calling a variadic function is a lot easier than
writing the body of one. That will likely put many off.

I wouldn't be able to do it without looking up some examples.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> Who has actually used a variadic function for any purpose other than
> implementing printf-style format strings?

May I inquire as to why you are motivated to ask the question?

On 20/01/2024 23:02, bart wrote:
> On 20/01/2024 22:37, Malcolm McLean wrote:
>> On 20/01/2024 21:37, Lawrence D'Oliveiro wrote:
>>> On Sat, 20 Jan 2024 11:19:57 +0000, Malcolm McLean wrote:
>>>
>>>> But no-one has yet come up with an occasion where they implemented a
>>>> variadic function by choice, for code which they controlled ...
>>>
>>> But the people who created these libraries we mentioned certainly did.
>>  >
>> I was wrong. As was pointed out eslewhere. Kaz gave some examples. But
>> his first was of usage.
>>
>> Of course someone must have taken the decision that the call to evoke
>> an external process would take a variable list of arguments rather
>> than a single string. However In find that, of thousands of functions
>> in my code base, not a single one is variadic except a few interfaces
>> to vsprintf.
>
>
> Variadic functions were likely added to implement *printf functions,
> since the language didn't want to make special provision just for those.
>
> Then a number of people decided to make use of the feature, although
> less often than you might expect.
>
> But it is not a desirable feature for general use as it is not type-safe.
>
> The other thing is, calling a variadic function is a lot easier than
> writing the body of one. That will likely put many off.
>
> I wouldn't be able to do it without looking up some examples.
>
I have occasionally passed the wrong type to printf. Usually a long
integer to %d. But I can't recall an occasion where the problem wasn't
quickly fixed. Xcode gives a warning for mismatched format string
parameters, but of course it can't do that for roll your own.
The other thing is passing a raw pointer to %p instead of casting to
void *. Technically this is an error, but %p is only really useful for
temporary debug code, so it's just pointless typing to out the cast in.

Variardic functions are implemented with macros and it's a bit hard to
work out what is going on. But it's not that hard. I don't think it's a
good reason for avoiding them. On the other hand, I implemented a C++
variable length template expansion to produce a "simple JSON" which is
in effect a varidaic function with type information. But whilst I
implemented it myself, I can't remember exactly how it is supposed to
work or what the syntax means.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 20/01/2024 21:37, Lawrence D'Oliveiro wrote:
>> On Sat, 20 Jan 2024 11:19:57 +0000, Malcolm McLean wrote:
>>
>>> But no-one has yet come up with an occasion where they implemented a
>>> variadic function by choice, for code which they controlled ...
>> But the people who created these libraries we mentioned certainly
>> did.
>>
> I was wrong. As was pointed out eslewhere. Kaz gave some examples. But
> his first was of usage.

Perhaps because your original post asked about *using* variadic
functions, not implementing them.

> Of course someone must have taken the decision that the call to evoke
> an external process would take a variable list of arguments rather
> than a single string.

The standard system() function takes a single string. As for the
exec*() functions, they correspond to the standard definition of main(),
which takes a sequence of strings.

> However In find that, of thousands of functions
> in my code base, not a single one is variadic except a few interfaces
> to vsprintf.

That's not surprising. <stdarg.h> (and its predecessor <varargs.h>)
were designed to allow *printf, *scanf, and similar functions to be
implemented in more or less portable C. The mechanism is used for
things very similar to printf and scanf, for functions that take an
arbitrarily long sequence of arguments (typically string pointers), and
occasionally for things that might be implemented in other languages
with overloading or default arguments.

For example open() takes an optional third argument. In pre-ANSI C,
function declarations didn't specify parameters, and it just worked. In
many languages, defining an optional argument is straightforward. In
post-ANSI C, the only way to do it is to make open() variadic -- which
means a compiler isn't required to diagnose a call that passes a dozen
arguments.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 21/01/2024 00:30, Tim Rentsch wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> Who has actually used a variadic function for any purpose other than
>> implementing printf-style format strings?
>
> May I inquire as to why you are motivated to ask the question?
>
I had a break from the newsgroup due to the spam and Google groups
discontinuation. Eventually I decided to overcome my reservations about
putting junk on my employer's machine and installed a newsreader.

There weren't any very interesting threads in the first 500 headers, so
I decided to start one. It's pure chattiness and with no serious
purpose, but if you've anything to say on variadic functions then of
course you are more than welcome to join in.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On Sat, 20 Jan 2024 22:37:48 +0000, Malcolm McLean wrote:

> Of course someone must have taken the decision that the call to evoke an
> external process would take a variable list of arguments rather than a
> single string. However In find that, of thousands of functions in my
> code base, not a single one is variadic except a few interfaces to
> vsprintf.

I have the urge to implement one, purely to provide a counterexample. As
an excuse, I will use it to demonstrate a technique for typesafely calling
such a function from Python code via ctypes.

On 2024-01-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sat, 20 Jan 2024 22:37:48 +0000, Malcolm McLean wrote:
>
>> Of course someone must have taken the decision that the call to evoke an
>> external process would take a variable list of arguments rather than a
>> single string. However In find that, of thousands of functions in my
>> code base, not a single one is variadic except a few interfaces to
>> vsprintf.
>
> I have the urge to implement one, purely to provide a counterexample. As
> an excuse, I will use it to demonstrate a technique for typesafely calling
> such a function from Python code via ctypes.

You're going to implement variadic functions in Malcom's code base,
just to create a counterexample?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On Sat, 20 Jan 2024 11:19:57 +0000, Malcolm McLean wrote:

> But no-one has yet come up with an occasion where they implemented a
> variadic function by choice, for code which they controlled ...

OK, I have done one. Just a simple one, to demonstrate how to make
typesafe calls to it via a Python wrapper. It’s part of my “Python Topics
Notebooks” collection <https://gitlab.com/ldo/python_topics_notebooks/>.
The C code (stack_calc.[ch]) is a very basic RPN calculator, which takes a
varargs list of operators (integer) and operands (real), and returns the
final calculated result.

The notebook that makes use of it is called “ctypes Tip Extra -- Calling A
Variadic Function”.

On 21/01/2024 07:48, Lawrence D'Oliveiro wrote:
> On Sat, 20 Jan 2024 11:19:57 +0000, Malcolm McLean wrote:
>
>> But no-one has yet come up with an occasion where they implemented a
>> variadic function by choice, for code which they controlled ...
>
> OK, I have done one. Just a simple one, to demonstrate how to make
> typesafe calls to it via a Python wrapper. It’s part of my “Python Topics
> Notebooks” collection <https://gitlab.com/ldo/python_topics_notebooks/>.
> The C code (stack_calc.[ch]) is a very basic RPN calculator, which takes a
> varargs list of operators (integer) and operands (real), and returns the
> final calculated result.
>
> The notebook that makes use of it is called “ctypes Tip Extra -- Calling A
> Variadic Function”.

"Calling such a variadic function from C itself can be tricky, because
there is very limited type checking that the C compiler can do on such
calls."

This is exactly the problem. In your example, you go through a
verification process before calling the function, which is called
indirectly.

That is, the user-code in Python doesn't directly call 'stack_calc'.
This means that there is no real need for the C function to be variadic.

It could take a single pointer to any arbitrary C data structure that
can represent your sample expression. Or maybe two pointers to parallel
arrays. Or ...

So it still leaves C variadic functions as a solution looking for a
problem, a solution which is hard to make type-safe.

On 21/01/2024 03:44, Malcolm McLean wrote:
> On 20/01/2024 23:02, bart wrote:
>> On 20/01/2024 22:37, Malcolm McLean wrote:
>>> On 20/01/2024 21:37, Lawrence D'Oliveiro wrote:
>>>> On Sat, 20 Jan 2024 11:19:57 +0000, Malcolm McLean wrote:
>>>>
>>>>> But no-one has yet come up with an occasion where they implemented a
>>>>> variadic function by choice, for code which they controlled ...
>>>>
>>>> But the people who created these libraries we mentioned certainly did.
>>>  >
>>> I was wrong. As was pointed out eslewhere. Kaz gave some examples.
>>> But his first was of usage.
>>>
>>> Of course someone must have taken the decision that the call to evoke
>>> an external process would take a variable list of arguments rather
>>> than a single string. However In find that, of thousands of functions
>>> in my code base, not a single one is variadic except a few interfaces
>>> to vsprintf.
>>
>>
>> Variadic functions were likely added to implement *printf functions,
>> since the language didn't want to make special provision just for those.
>>
>> Then a number of people decided to make use of the feature, although
>> less often than you might expect.
>>
>> But it is not a desirable feature for general use as it is not type-safe.
>>
>> The other thing is, calling a variadic function is a lot easier than
>> writing the body of one. That will likely put many off.
>>
>> I wouldn't be able to do it without looking up some examples.
>>
> I have occasionally passed the wrong type to printf. Usually a long
> integer to %d. But I can't recall an occasion where the problem wasn't
> quickly fixed. Xcode gives a warning for mismatched format string
> parameters, but of course it can't do that for roll your own.

Of course you can.

XCode uses clang, IIUIC, and both gcc and clang have extensions
(attributes) for checking printf and scanf style strings and the
variadic parameters. They only work with compile-time known format
strings, understandably enough, but are fine for making your own checked
functions for logging, debug prints, or whatever.

That doesn't help for other types of variadic functions, however, and
you they are never as type-safe as functions with full non-variadic
prototypes.

> The other thing is passing a raw pointer to %p instead of casting to
> void *. Technically this is an error, but %p is only really useful for
> temporary debug code, so it's just pointless typing to out the cast in.
>
> Variardic functions are implemented with macros and it's a bit hard to
> work out what is going on. But it's not that hard. I don't think it's a
> good reason for avoiding them. On the other hand, I implemented a C++
> variable length template expansion to produce a "simple JSON" which is
> in effect a varidaic function with type information. But whilst I
> implemented it myself, I can't remember exactly how it is supposed to
> work or what the syntax means.
>

Variadic templates in C++ are typesafe, which is a big improvement over C.

On Sun, 21 Jan 2024 13:27:30 +0000, bart wrote:

> That is, the user-code in Python doesn't directly call 'stack_calc'.
> This means that there is no real need for the C function to be variadic.
>
> It could take a single pointer to any arbitrary C data structure that
> can represent your sample expression. Or maybe two pointers to parallel
> arrays. Or ...

.... and be just as type-unsafe as the variadic option.

On 21/01/2024 21:29, Lawrence D'Oliveiro wrote:
> On Sun, 21 Jan 2024 13:27:30 +0000, bart wrote:
>
>> That is, the user-code in Python doesn't directly call 'stack_calc'.
>> This means that there is no real need for the C function to be variadic.
>>
>> It could take a single pointer to any arbitrary C data structure that
>> can represent your sample expression. Or maybe two pointers to parallel
>> arrays. Or ...
>
> ... and be just as type-unsafe as the variadic option.

No, it wouldn't.

If you have that single pointer as type T*, then you can't for example
pass, when called from C, an int, or float, or U* pointer, or struct, as
happens with variadic.