Re: C pointer question

[Richard Tobin]

[Followups moved to comp.lang.c.]

In article <AM5Gk.848$P5.6 26@nwrddc02.gni link.net>,
James Kuyper <jameskuyper@ve rizon.netwrote:

> if (head && *head) { /* Corrected code */

>1. Why is the purpose of 'head' in the 'if' condition? Shouldn't
>'*head' suffice?

>No. If head is a null pointer, then every other statement in the program
(including the check of whether *head is null) has undefined behavior.

Obviously head has to be non-null, but the question is why the
function has to check for it, rather than relying on the user to pass
in a good value. Presumably in this case it's specified that the
function can be called with a null pointer.

The reason it uses a pointer-to-pointer is so that you can pass in
a "list" variable, which will be modified. The natural idiom will
be

node *list;
... build a list ...
RemoveHead(&lis t);

If the argument were a plain pointer-to-node, you would have to
instead write

list = RemoveHead(list );

Given that the normal use will be to pass the address of a variable, I
don't see much point in allowing a null argument. Perhaps the idea is
to be able to (say) call RemoveHead() on a two-node list three times
without causing an error, just as (cdr (cdr (cdr '(1 2)))) is nil on
traditional Lisps, but I think that too often hides mistakes.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

[jameskuyper@verizon.net]

Re: C pointer question

Richard Tobin wrote:

[Followups moved to comp.lang.c.]
>
In article <AM5Gk.848$P5.6 26@nwrddc02.gni link.net>,
James Kuyper <jameskuyper@ve rizon.netwrote:
>

if (head && *head) { /* Corrected code */

>

1. Why is the purpose of 'head' in the 'if' condition? Shouldn't
'*head' suffice?

>

No. If head is a null pointer, then every other statement in the program
(including the check of whether *head is null) has undefined behavior.

>
Obviously head has to be non-null, but the question is why the
function has to check for it, rather than relying on the user to pass
in a good value. Presumably in this case it's specified that the
function can be called with a null pointer.

In principle, that's correct; but I would argue that this is not a
matter of arbitrary choice, but rather a matter of good design. The
specification for the function should either say that a null pointer
is allowed, or specify the manner in which the function signals an
error if the pointer is null.

I'd feel differently if the function were declared static, and no
pointer to that function were ever passed outside of the same
translation unit. In that case, all of the actual calls to the
function would have to occur in the same translation unit. It would
therefore be feasible to verify that each of those calls passes a non-
null pointer value.

[Richard Tobin]

Re: C pointer question

In article <2d3a5bf7-a69a-4f78-a55e-eb62e9641338@w7 g2000hsa.google groups.com>,
<jameskuyper@ve rizon.netwrote:

>In principle, that's correct; but I would argue that this is not a
>matter of arbitrary choice, but rather a matter of good design. The
>specificatio n for the function should either say that a null pointer
>is allowed, or specify the manner in which the function signals an
>error if the pointer is null.

This is not, of course, a design choice that is followed by the
standard C library itself.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

[Malcolm McLean]

Re: C pointer question


"Richard Tobin" <richard@cogsci .ed.ac.ukwrote in message

In article
<jameskuyper@ve rizon.netwrote:
>

>>In principle, that's correct; but I would argue that this is not a
>>matter of arbitrary choice, but rather a matter of good design. The
>>specificati on for the function should either say that a null pointer
>>is allowed, or specify the manner in which the function signals an
>>error if the pointer is null.

>
This is not, of course, a design choice that is followed by the
standard C library itself.
>

It's back to defensive programming. It is not acceptable to make a
general-purpose function dependent on stderr. If it signals an error by some
other mechanism this over-complicates the interface, and the likely end
result is to hide bugs if you suppress the error, add bugs due to the
increase line count if caller handles it, and do both if caller
misunderstnads your interface and handles the error condition incorrectly.

--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm

[Flash Gordon]

Re: C pointer question

Malcolm McLean wrote, On 06/10/08 20:50:

>
"Richard Tobin" <richard@cogsci .ed.ac.ukwrote in message

>In article
><jameskuyper@v erizon.netwrote :
>>

>>In principle, that's correct; but I would argue that this is not a
>>matter of arbitrary choice, but rather a matter of good design. The
>>specificati on for the function should either say that a null pointer
>>is allowed, or specify the manner in which the function signals an
>>error if the pointer is null.

>>
>This is not, of course, a design choice that is followed by the
>standard C library itself.
>>

It's back to defensive programming. It is not acceptable to make a
general-purpose function dependent on stderr.

Defensive programming does not require that.

If it signals an error by
some other mechanism this over-complicates the interface,

So you consider fopen to be overly complex?

and the likely
end result is to hide bugs if you suppress the error,

Unless you know what you are doing.

add bugs due to
the increase line count if caller handles it,

If you can't cope with error signalling you need a language other than C.

and do both if caller
misunderstnads your interface and handles the error condition incorrectly.

If your caller miss-understands the interface you will have a bug
whether defensive programming is used or not.
--
Flash Gordon
If spamming me sent it to smap@spam.cause way.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/