Sujet : Re: Named arguments in C
De : ldo (at) *nospam* nz.invalid (Lawrence D'Oliveiro)
Groupes : comp.lang.cDate : 03. Jul 2024, 01:17:49
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v625bd$1rh22$2@dont-email.me>
References : 1 2 3 4 5
User-Agent : Pan/0.158 (Avdiivka; )
On Tue, 2 Jul 2024 21:53:48 +0500, Ivan Farlenkov wrote:
You can sort of already do it in C by using designated initializers and
macros
There is simply no good way of doing it without having it as a
built-in language feature.
When I was first learning about C (back in the 1980s), it was apparent
that it was a poor fit for my favourite OS of the time, DEC’s VMS.
Consider the ominibus non-file-structured I/O function call, SYS$QIO
<
https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c04623201>
(page 282 onwards). The C prototype looks like this:
int sys$qio
(
unsigned int efn,
unsigned short int chan,
unsigned int func,
struct _iosb *iosb,
void (*astadr)(__unknown_params),
__int64 astprm,
void *p1,
__int64 p2,
__int64 p3,
__int64 p4,
__int64 p5,
__int64 p6
);
“func” is, or used to be, 10 bits of function code (e.g. read, write)
plus 6 bits of function modifier (e.g. do read with timeout). The
generic arguments p1-p6 have function-dependent meanings, though p1 is
usually a buffer address.
This call is asynchronous, and offers 3 different ways of notifying
I/O completion: by setting an “event flag” (the number of which is
specified in the “efn” arg), by filling in an “I/O status block” (the
address of which can be passed in the “iosb” arg), and by invoking an
“AST” (“Asynchronous System Trap”) completion routine, the address of
which can be passed in the “astadr” arg (plus an extra arg for caller
use in “astprm” that could be used, for example, to identify the
context of the I/O request in question).
The only function I can remember that used all 6 function-specific
arguments was the “read-with-prompt” function of the terminal driver,
with the timeout option. In this call, we had
p1 -- the buffer in which to return the user input
p2 -- the length of the input buffer
p3 -- the read timeout in seconds
p4 -- the read termination character mask
p5 -- the address of the prompt string to display
p6 -- the length of the prompt string
What was good about read-with-prompt, versus doing your own output of
the prompt string followed by a simple read? It could automatically
redisplay your prompt string in any situation where the screen got
messed up and needed refreshing (e.g. after a system broadcast message
was displayed).