Safety and Interface design

[jacob navia]

> Charlie Gordon said:
>
>
> Absolutely right. Same applies to motor vehicles, kitchen knives, and
> indeed any other potentially dangerous tool that can be misused by humans.
> So what do you want people to do - go back to the Stone Age? Or maybe
> just maybe - they can learn how to use tools properly?
>

Yes, let's follow H's logic:

Driving cars is a dangerous activity that needs good concentration.
The idea of introducing a safety belt is flawed since good drivers
do not make accidents. Only bad drivers do.
THEN
If we introduce this safety belt it will make that bad drivers
could survive their accidents, provoking new accidents. This is
bad.
THEN
We should keep on with our cars like they are now. No safety
belts, and brakes that will fail if the driver drives
beyond the legal speed limit. This will make all bad drivers
have an accident sooner, they will die sooner, and only good
drivers will survive.

THEN

We will have no more accidents!!

------------------------------------------------------------------

What is obviously missing here is the fact that most drivers are good
drivers most of the time, but NOT ALWAYS!

The safety belt allows drivers that make an occasional mistake to
avoid the consequences of a driving mistake. A good designed interface
makes errors harder to do requiring less concetration from the part
of the programmer.

Any reasoning can be distorted obviously. The alternative is not to
strip C of pointers because pointers can be misused. It is creating
good designed interfaces that are less error prone.

strncpy can produce non zero terminated strings, what in C is an
accident waiting to happen. Yes, you should always REMEMBER
to zero terminate the string yourself, but...

WHY should we require from the programmer this tedious stuff
that can be done automatically by a better designed interface???

No reason but the rigid conservative attitude that has led to C being
still in the 70s.

>
>

Note that by its name, this function misleads the programmer into
believing that. The "n" variants of functions take a limit. This
is a nowhere stated rule but many programmers will believe that.

Of course you should know that it doesn't zero terminate, and
if you do not know that you are "a stupid" programmer by definition.

This is the justification by stupid people that fail to see
that when a tool is persistently "misused" the *design* of the tool
is wrong!

Programmers are always the ones that get blamed for everything by the
higher ups. In this case the people that know better and could
have included a correct function for limited string copy in their
interface AGES ago.

OF COURSE anyone can write a better function, but many people will
have a tendency of facility and use strncpy *because is there*
already and its use is "free".

> This is very, very simple to understand, and programming is a highly
> complex activity requiring considerable intelligence to do properly.

Designing interfaces too.

> Anyone not capable of understanding that strncpy is not supposed to be
> used as a "safe string copy" has no business being a programmer. If you
> find such people in your place of work, fire them. They'd be far happier
> in marketing, anyway.
>

This "elitist" attitude is at the heart of bad software engineering.
No, the tools are correct. That most people make a mistake when using
them is only THEIR FAULT.

THEY are stupid. Not the ones that persist
in an interface that is provably error prone! Of course not. Those
aren't stupid.

The central point I want to make:
Good programmers are good most of the time. NOT ALWAYS!

Good designed interfaces make errors harder to do.

 

[Richard Heathfield]

jacob navia said:

Yes, let's follow H's logic:

Driving cars is a dangerous activity that needs good concentration.
The idea of introducing a safety belt is flawed since good drivers
do not make accidents. Only bad drivers do.

Or you could just take out the engine. That would make it safe too, because
now you'd have to push it.

Any reasoning can be distorted obviously. The alternative is not to
strip C of pointers because pointers can be misused. It is creating
good designed interfaces that are less error prone.

strncpy can produce non zero terminated strings, what in C is an
accident waiting to happen. Yes, you should always REMEMBER
to zero terminate the string yourself, but...

NO! That is not what strncpy is *for*! The whole point of strncpy is to
copy a *substring* from one place to another. It has nothing to do with
strings, and the only broken thing about it is the name.

WHY should we require from the programmer this tedious stuff
that can be done automatically by a better designed interface???

It isn't the interface that's the problem. It's the misconception about
what strncpy is for that is the problem.

Note that by its name, this function misleads the programmer into
believing that.

Yes, it's a lousy name. Nobody is disputing that.

Of course you should know that it doesn't zero terminate, and
if you do not know that you are "a stupid" programmer by definition.

No, if you don't know, that doesn't make you stupid - merely ignorant. But
if you are using a function without first finding out what it does, then
yes, stupid is the right word.

 

[CBFalconer]

jacob navia said:
.... snip ...

NO! That is not what strncpy is *for*! The whole point of strncpy
is to copy a *substring* from one place to another. It has nothing
to do with strings, and the only broken thing about it is the name.


It isn't the interface that's the problem. It's the misconception
about what strncpy is for that is the problem.


Yes, it's a lousy name. Nobody is disputing that.


No, if you don't know, that doesn't make you stupid - merely ignorant.
But if you are using a function without first finding out what it
does, then yes, stupid is the right word.

However:

#define SIZE ...
char arr[SIZE + 1];
...
arr[SIZE] = '\0';
...
strncpy(arr, "whatever", SIZE);

is always going to leave a null terminated string in arr. Safe
enough for me. However I think that the (non-standard) strlcpy is
much more generally useful. For a version see:

<http://cbfalconer.home.att.net/download/>

 

[Richard Heathfield]

CBFalconer said:

jacob navia said:
... snip ...

NO! That is not what strncpy is *for*! The whole point of strncpy
is to copy a *substring* from one place to another. It has nothing
to do with strings, and the only broken thing about it is the name.


It isn't the interface that's the problem. It's the misconception
about what strncpy is for that is the problem.


Yes, it's a lousy name. Nobody is disputing that.


No, if you don't know, that doesn't make you stupid - merely ignorant.
But if you are using a function without first finding out what it
does, then yes, stupid is the right word.

However:

#define SIZE ...
char arr[SIZE + 1];
...
arr[SIZE] = '\0';
...
strncpy(arr, "whatever", SIZE);

is always going to leave a null terminated string in arr.

Sure. Er, so what? That's a side-effect of the way in which you've chosen
to set up your array, and has nothing to do with the suitability or
otherwise of strncpy for the purpose you require.

Safe enough for me.

If you want 100% safe and correct copying of data, strncpy is the wrong way
to do it. In the above example, the string that results from your copy
depends on the definition of SIZE. If it's 1, you get "w". If it's 2, you
get "wh". And so on. Only if it is 8 or more do you get the full
"whatever".

If we are allowed arbitrarily to discard data, why bother to read it in the
first place?

However I think that the (non-standard) strlcpy is
much more generally useful.

Since it's non-standard, we can't know what it does. It may have different
meanings in different libraries. In any case, it has nothing to do with
whether strncpy is or is not a safe function to use, since it doesn't
(necessarily) do the same job that strncpy does. Of course, it /could/ do
the same job that strncpy does, on some implementations, in which case it
is unlikely to have any advantages over strncpy.

 

[CBFalconer]

CBFalconer said:
.... snip ...


Since it's non-standard, we can't know what it does. It may have
different meanings in different libraries. In any case, it has
nothing to do with whether strncpy is or is not a safe function
to use, since it doesn't (necessarily) do the same job that
strncpy does. Of course, it /could/ do the same job that strncpy
does, on some implementations, in which case it is unlikely to
have any advantages over strncpy.

Your complaint would make a lot more sense if I had not included a
link to source code and description of strlcpy(), which you rapidly
snipped before replying.

 

[Richard Heathfield]

CBFalconer said:

Your complaint would make a lot more sense if I had not included a
link to source code and description of strlcpy(), which you rapidly
snipped before replying.

I'm sorry, Chuck, but the fact that you have implemented a function named
strlcpy does not mean that nobody else has. Can you *guarantee* the
behaviour of all strlcpy implementations, even the ones you didn't write?

Incidentally, my snipping of your link was not an attempt at subterfuge or
wilful ignorance - I accept that you have implemented a function with that
name, and, to show that I'm not trying to pull a whitewash, I'll reproduce
the URL for the benefit of those not reading by thread:

<http://cbfalconer.home.att.net/download/>

But the fact remains that it is not the only strlcpy in town.

 

[CBFalconer]

CBFalconer said:



I'm sorry, Chuck, but the fact that you have implemented a function named
strlcpy does not mean that nobody else has. Can you *guarantee* the
behaviour of all strlcpy implementations, even the ones you didn't write?

Incidentally, my snipping of your link was not an attempt at subterfuge or
wilful ignorance - I accept that you have implemented a function with that
name, and, to show that I'm not trying to pull a whitewash, I'll reproduce
the URL for the benefit of those not reading by thread:

<http://cbfalconer.home.att.net/download/>

But the fact remains that it is not the only strlcpy in town.

Of course not - that goes with being 'non-standard'. However the
link includes description of the functions(s) and their genesis
(not mine), together with standard C source, not to mention a
testing routine. They are also deliberately written to not need
the standard library, thus making use on small embedded systems
easy.