Re: writing library functions and pointers?

"Morris Keesan" <keesan@xxxxxxxxxxx> writes:

On Thu, 09 Jul 2009 08:17:47 -0400, Ben Bacarisse
<ben.usenet@xxxxxxxxx> wrote:

"Morris Keesan" <keesan@xxxxxxxxxxx> writes:

On Mon, 06 Jul 2009 09:47:26 -0400, lovecreatesbeauty@xxxxxxxxx
<lovecreatesbeauty@xxxxxxxxx> wrote:

k&r errata #142:
On the other hand, pre-ANSI, the cast was
necessary [from malloc return to other pointer types]

I've seen this claim many times, but I've never used any compiler for
which the cast was necessary, nor seen any definition of the language
in which it was necessary, including, among others, the language
definition as published in K&R 1, or the (almost identical) C Language
documentation in the version 6 or 7 Unix documentation.

You've had some references, but there are also real examples. I
worked on one machine that was (16-bit) word-addressed. To represent
character pointers, the pointer to the containing word was shifted
left by 1 and the bottom bit was used to pick which byte was being
addressed.

When compiling:

int i;
char *ip = (char *)&i;
double *dp = (double *)malloc(sizeof *dp);

the casts generated code (a shift left and a shift right). You might
wonder why the compiler could not just generate this code without the
cast but remember this is K&R C where there are no function
prototypes.

This has nothing to do with function prototypes. If malloc were
properly declared as returning a (char *), then the
conversion-by-assignment which would be generated by

double *dp = malloc(sizeof *dp);

should be the same conversion generated by the cast, i.e. conversion
of (char *) to (double *). If malloc were not declared, the conversion
would have been the (incorrect) (int) to (double *). Are you saying
that on this word-addressed machine, assigning a (char *) to a (double *)
without a cast did not generate the code to do a type conversion?

It did not and the legalistic reason may have been because that is
what is mandated by K&R (I think Keith has posted the reference
elsewhere in this thread) but I suspect the reason compiler writer
were happy to go along with this is that is gives pointers a simple
interface with the old un-prototyped functions: initialisation,
assignment and parameter passing are all conversion free copy
operations.

I also worked on a word-addressed machine (a Honeywell Level 6), where
(char *) was twice as large as all other pointers, because the C compiler
implemented (char *) as an (int *) plus an extra word indicating high or
low byte. As you say below, some code was a "challenge to port", since
so many people wrote code which assumed that all pointers had identical
representations. But even on that machine, assigning a (char *) to
any other data-pointer type caused the correct conversion to occur
(assuming that the (char *) were properly aligned), just as if the
conversion were done by a cast before the assignment.

Faced with:

use_pointer(malloc(16));

the compiler has no idea what type of pointer the function expects.
Some of the Unix utilities were a challenge to port.

Yes, and in this case, the result of malloc would have to be
converted to the correct pointer type by an explicit cast, but this
is totally different from the case of an assignment, where the
left-hand side of the assignment operator imposes a type which must
be converted to (except in the cases cited by Keith Thompson, for
which thanks, Keith).

Yes, it is a separate case, but I was trying to flesh out the logic
behind K&R's view that assignment does no conversion. My feeling is
that this is done to give pointers a simple model -- all conversions
must be explicit and all duplication operations (assignment,
initialastion and argument passing) are plain copies.

There is (was?) another way open: assignment and initialisation could
convert (along with the other know-type case: function return) and a
promotion be added to convert all pointer arguments to the widest and
most general pointer type. Of course, in many cases this would
perform unnecessary operations. Anything between these two seems to
me to be an unsatisfactory mixed bag.

In the other case where the right type is known, function return, K&R
give explicit advice: use a cast as this "represents the safest course
for the future" (sec 6.5 p 134).

--
Ben.
.

Relevant Pages