Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?]

[seebs@solutions.solon.com (Peter Seebach)]

In article <50650h$rek@goanna.cs.rmit.edu.au>,
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:
> - a program that conforms to the C standard (we were talking about
>   standard C, no?) may not legally set any variable external to the
>   handler if that variable is not of type sig_atomic_t.  Now on _this_
>   system, sig_atomic_t is int, so a *legal* signal handler, however
>   malicious, may not change a char buffer.  (This obviously won't
>   apply to systems in which sig_atomic_t is char, but it _does_
>   apply to this system, and the compiler is entitled to rely on it.)

>Let's take an example which _doesn't_ involve function-local buffers.
>Consider

>	char *dupcat(char const *a, char const *b) {
>	    char *result = malloc(strlen(a) + strlen(b) + 1);
>	    assert(result != 0);
>	    memcpy(result, a, strlen(a));
>	    memcpy(result + strlen(a), b, strlen(b));
>	    memcpy(result + strlen(a) + strlen(b), "", 1);
>	    return result;
>	}

>I repeat, this is NOT the way I would normally write it.
>I contend that it is _inefficient_ but not "stupid".

Maybe.

There's a possible weakness.  Assume sig_atomic_t is an int.  Assume we
have an array of sig_atomic_t somewhere.  Assume we decide to, as we
are permitted by the standard, treat it as an array of characters.  The
first sig_atomic_t in the array may be overwritten by a signal handler
we have installed.  We make sure the 2nd s_a_t in the array contains at least
one null byte, so strlen((char *) sat_array) will be zero, and pass
the array to dupcat as both a and b.  (Suitably cast to (char *).)

It is entirely possible that, even though a and b are the same pointer,
that a signal handler will change the NTBS they point to between a
strlen(a) and a strlen(b) in the above, or between statements.

The problem is unique to (char *), which may point to things other than
arrays of characters, because you may treat any object as an array of
characters.

I still don't think it's stupid, merely (probably) inefficient.

On the other hand, using strlen() on objects which were not intended to be
strings is legitimately stupid.

On the other hand, using assert() for the return from malloc is, IMHO, stupid.
assert() should catch programming errors, not resource limitations.

>The point I am concerned to defend is solely this:
>the function dupcat() may be inefficient,
>but it clearly and correctly expresses the programmer's intent,
>and is therefore not "stupid".

This, I would agree with.

>Surely nobody but an assembly hacker would dispute the point
>that there are times when it is RATIONAL to write suboptimal
>code (in order to devote your resources to activities with a
>higher payoff)?

Assembly hackers spend most of their time and effort writing suboptimal code;
it ports horribly, so it's clearly not *optimal*.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.