Hi Gerry,

GD> RS> Nope, it's still passed by value, since the argument the function
GD> RS> expects to receive is a pointer, in other words, the value of said
GD> RS> pointer. It's semantics, though I like to be able to say,
GD> RS> unequivocally, that C always passes by value. :)

GD>While it's true what you say here, you're leaving out the pointers and
GD>how one can manipulate data via the passed pointers.

GD> GW> If you want to look at it that way, you're welcome. I find it
GD> GW> confusing, so don't expect me to agree with you.

GD>You're gonna have to, George. :)

No I'm not!

GD> GW> As I interpret and describe C data transfer to functions:-

GD> GW> a) If data is passed by value then there is no direct way of changing
GD> GW> the original data from within the function.

GD> GW> b) If data is passed by reference (a pointer to the data) then the
GD> GW> original data can be modified from within the function.

GD>Interpretation correct. :)

GD> GW> As a result as strings are manipulable directly from within the
GD> GW> function I describe than as passed by reference.

GD>Nope. You can manipulate data only via the pointer passed, thus
GD>indirectly. Get out your copy of Kernighan and Ritchie's "The C
GD>Programming Language" and check page 202 (second edittion, almost
GD>at the top), which says:

GD> "In preparation for the call to a function, a copy is made of each
GD> argument; all argument-passing is strictly by value. A function may
GD> change the values of its parameter objects, which are copies of the
GD> argument expressions, but these changes cannot affect the values of
GD> the arguments. However, it is possible to pass a pointer on the
GD> understanding that the function may change the value of the object to
GD> which the pointer points."

GD>Just reading this paragraph by itself may be tough, so I often advise
GD>someone getting into C programming to get a copy of this book and study
GD>it. Available at univ and college bookstores.

It's easy. I have the first edition... Interpretation is the problem.
The paragraph you are referring to is in Appendix A, Section 7.1 in the
first edition.

Near the start of the section it says:

 "An identifier is a primary expression, provided it has been suitably
declared as discussed below. Its type is specified by it's declaration.
if the type of the identifier is "array of ...", however, then the value
of the identifier-expression is a pointer to the first object of the
array, and the type of the expression is "pointer to ...". Moreover, an
array identifier is not an lvalue expression. Likewise, an identifier
which is declared "function returning ...", when used except in the
function name position of a call, is converted to "pointer to function
returning ..."."

and also, a paragraph later:

 "A string is a primary expression. Its type is originally "array of
char"; but following the same rule as given above for identifiers, this
is modified to "pointer to char" and the result is a pointer to the
first character in the string. (There is an exception in certain
initialisers; see 8.6.)"

Now given these rules about conversion applied before the paragraph you
referred to, I can accept that all parameters are strictly by value, but
as the value is by definition a pointer (created by applying the rules
I've quoted) and given that all operations using the pointer affect the
original data and not a copy of the data, I consider arrays and strings
as passed by reference (the pointer passed being the reference to the
actual data) rather than by value (a copy of the string is not created).

This way of looking at things probably reflects the fact that my
original teaching of programming was using Algol 60 and that
subsequently I did a lot of programming using Intel PLM/80 and PLM/51
before I moved to C.

George

 * SLMR 2.1a * Wishing you a Peaceful and Prosperous New Year

--- Maximus/2 3.01