Rainer Weikusat:
> karl@??? writes:
...
> > With pointers, you have to handle the special case of null pointers.
> > I'm assuming you are omitting it here for brevity, but generally
> > change_value() should be something like:
> >
> > void change_value(int* ptr) {
> > if (!ptr) return;
> > *ptr = 20000000;
> > }
>
> It absolutely shouldn't unless NULL is expected to be valid, used
> argument value for some reason. If not, code passing NULL to such a
> function is likely erroneous. Forcing the program to abort, preferably
> with a core dump, via SIGSEGV will often enable fixing the error easily
> and quick. Silently bouncing it out of the function again so that it
> further propagates through the program is a terribly risky practice with
> literally unpredictable consequences.

Ok, I see your point (I'm used to functions that do error logging and
error returns, maybe if(!ptr) abort() would suit you better, but that
would incur non productive overhead, even though it better states
what happens for this special case).

But are you saying that the def. func(int * pp) says that null's are not
allowed unless specifically allowed ?
I somehow regards pp in func(int * pp) to be whatever you can put
into an int*, no exceptions, and func() has to be able to handle the
heat.

For the actual function change_value(), what is the semantics to
changing something that doesn't exist ? It could be abort() but it
could just as well be just a no-op, choose your pick.

You can compare it to the array case

for (ix = 0; ix < arr_max; ix++) { change_value(arr + ix); }

If the array is empty, that would be a big no-op. Or would you choose
an abort() when arr_max == 0 ?

///

But we can agree on that you have to be careful about null pointers.

Regards,
/Karl Hammar

-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57