Re: In-Out Parameters for functions (was: Re: Certified C compilers for safety-critical embedded systems
From: Dave Thompson (david.thompson1_at_worldnet.att.net)
Date: Fri, 23 Jan 2004 06:57:31 GMT
On Fri, 09 Jan 2004 13:35:17 GMT, Marin David Condic
> Yeah, but as far as I can tell C always had "in only" parameters and
> everything was a function returning a result. The only way you could get
> "in out" mode was passing addresses (indistinguishable to the garden
C has always had only pass-by-value (explicitly) which means that a
(formal) parameter is locally initialized/copied from the caller's
(actual) argument. Unless you declare it const (from C89 onward) you
can within the function assign to the *local copy* of the parameter,
with no effect on the argument; this is only sort of like "in".
With the important caveat that there are no array values as such at
all in C; with minor exceptions not relevant here any use of an array
actually uses a pointer (to its first element); subscripting *such a
pointer* accesses the array; and declaring a parameter as an array
actually makes it a pointer (unlike a local or global variable, where
declaring an array produces an array). So arrays (only) are
effectively by-reference, and from C89 can be distinguished as "in" or
"in out" (but visibly shared in both cases) by use of const.
For any other (non-array) type yes you must explicitly pass and use a
pointer to get "in out" and/or visible sharing.
Yes everything is a function, but from C89 a function can be declared
as returning nothing using the special (pseudo?)type "void".
> variety programmer from a 'Access) and of course dealing with all the
> errors that resulted from no checking that a parameter actually was an
> address. Such a setup didn't seem to hurt C with respect to popularity
> or getting Fortran programmers to understand it.
>From C89 you can (and should!) declare functions using "prototype"
form which gives the parameter types -- and optionally names, which
contribute nothing to the declaration except allow it to be textually
identical to the header in the definition/body, which in turn allows
cut&paste, manipulation by simple tools like awk, preprocessor tricks,
and such. Arguments to a *prototyped* function (from C) are (required
to be) checked that they agree (well enough) in type. This doesn't
particularly help for interfacing from Fortran, but see below.
> Robert A Duff wrote:
> > As far as I can remember, this idea was considered, and was generally
> > thought to be ugly. I mean, suppose you're trying to convince a Fortran
> > programmer to use Ada for numerics stuff. If you start babbling about
> > aliased and 'Access when there is no inherent need for pointers,
> > they're going to laugh, and rightly so.
C's quirks have certainly confused quite a lot of people and the
array/pointer relationship constitutes I would estimate at least an
eighth of comp.lang.c all by itself. Certainly they have not *blocked*
C's wide use, but whether it would have spread more/quicker without is
a question no one can answer. And issues about correct pointers or
addresses for C interfacing are quite common in comp.lang.fortran,
although the now-pending revision (still called F2003 but not official
yet last I checked) adds C-interop features that should (if and when
implemented and used) make this more robust.
- David.Thompson1 at worldnet.att.net