Re: Secure coding in C (was Re: Administrivia #4883)

[kmartin () PIONEER-NET COM (K Martin)]

Paul Cardon wrote:
> K Martin wrote:
>
> > > > ]     char *a = something();
> > > > ]     char *b = something_else();
> > > > ]     int len = strlen(a) + strlen(b);
> > > > ]     char *c = malloc(len + 1) || die("malloc");
> > > > ]     (void) strcat(strcpy(c, a), b);
> >
> > I'm partial to strncpy(); strcpy is a known hobgoblin to secure programming.
>
> Too many people blindly accept the idea of "strcpy bad ... strncpy good ...".

Uh yeah. I'm being misunderstood. My fault. Mr. Bennet's original example did
not give me any indication as to the exact nature if something() and
something_else(). They could have allocated heap memory, (in which case they
needed to be checked for bad return values) for all I could tell.

> They are both fine when used correctly and both bad when used incorrectly.  The
> problems are that there are subtleties in the interfaces (design
> inconsistencies) that lead to common unsafe usage and too many coders who do not
> take the time to read and understand the documentation where those gotchas are
> evident  (laziness).  There are also common mistakes in attempts to use strcpy
> and strncpy safely by people who *have* read the documentation.

Sir, that covers alot of ground when you're trying to write _portable_ code,
assuming the documentation exists for every target platform.

When you throw portability into the fray, then you have to hardcode any and all
bounds checking into your code.

There is no way for a programmer to know where his/her code is going to be a few
years down the road. I only write code for systems I have access to. I can only
read documentation I have access to (and that exists). I also have to stay
within POSIX specs.

In itself, fact that I am a human being positively guarantees that something
will go wrong.

--
--------------------------------------------------
Karl Martin --  kmartin () pioneer-net com
"SYNTAX ERROR IN 9000" -- C64
"I'm afraid I can't allow that, Dave." -- Hal9000
--------------------------------------------------