On the development of C

[Bartc]

The gets() implementation which gets a non-NULL value from alloc_size can
then test against the limit (I had in mind the address of the end of the
allocated block), and prevent buffer overflows.

You're kidding, right?

struct foo {
char buffer[100];
void (*method)(void);
};
struct foo *p = malloc(sizeof *p);
if (p != NULL) {
p->method = my_function;
gets(p->buffer);
p->method();
}

Even if gets() discovers that the size allocated to the pointer it
got is 104, say, how will it know to stop at 100?

That's true. Then the safe uses of gets() would be even more restricted.

But it also reduces the usefulness of the entire idea of obtaining size and
block limits of allocated pointers. If someone just allocates a single large
malloc block then suballocates from that, then knowing the limits of that
one block is not too helpful.

Back to the drawing board then.

 

[jameskuyper]

belief in the fundamental goodness of human kind

I'm not sure I understand how that applies. Are you implying that a
good human being would avoid pointing out a lie, in order to avoid
offending the liar? It seems to me that a "good" human being would
feel obliged to point out a lie, in order warn those who are in danger
of being deceived by it. Are you advocating the use of euphemisms? It
seems to me that if a euphemism expresses, with sufficient clarity,
that someone has said something that they know to be false, with the
deliberate intent to deceive, then using the euphemism should be just
as offensive as using the word "lie". On the other hand, if the
euphemism is sufficiently unclear to avoid offending the liar, then
use of the euphemism might also fail to achieve the goal of warning
the potential victims.

Of course, using the word "lie" to describe something that isn't a lie
is wrong; but that's not because the word "lie" is offensive, but
because the word is incorrect.

 

[Keith Thompson]

Of course, using the word "lie" to describe something that isn't a lie
is wrong; but that's not because the word "lie" is offensive, but
because the word is incorrect.

It's wrong for both reasons.

Calling me a C# programmer (I'm not) would be incorrect but not
offensive. Calling me a liar (I'm not) would be both incorrect and
offensive.

 

[jameskuyper]

It's wrong for both reasons.

Calling me a C# programmer (I'm not) would be incorrect but not
offensive. Calling me a liar (I'm not) would be both incorrect and
offensive.

But offending you is wrong only because the accusation is incorrect,
so ultimately all of the wrongness traces back to the fact that it's
incorrect.

 

[Keith Thompson]

Somebody already kept it out of the index of original K&R. Does
it appear un-indexed in the text somewhere?

I don't think so. Chapter 7, "Input and Output" doesn't mention
gets(), though it does mention fgets() and says it's provided by the
standard library.

 

[Keith Thompson]

But offending you is wrong only because the accusation is incorrect,
so ultimately all of the wrongness traces back to the fact that it's
incorrect.

There is a difference. Some incorrect statements are offensive;
others are not. So the offensiveness must come from something other
than the mere fact that it's incorrect.

 

[jameskuyper]

jameskuyper said:


I think he's trying to shave Jacob Navia with Hanlon's Razor. At
least, if you read his reply that way, it does actually make sense.

I thought that was what he might have intended, but if so, he should
have concentrated on the possibility that 'lie' was inaccurate, rather
than the fact that it is offensive.

Nevertheless, it is clear that some people are offended (and rightly
so, in my view) when their honesty is called into question.

That's certainly true. My point is that there's nothing intrinsically
wrong with offending someone by lodging a truthful accusation against
them; if a truthful accusation offends them, it is entirely right and
proper that they should be offended - it is in fact a state of affairs
to be preferred to them being complacent in their misdeeds. However,
there is definitely something wrong with lodging a false accusation.

 

[Dik T. Winter]

> Tell me... have you ever been a sysadmin, or only a programmer? 'cause I
> have, and I assure you, even broken code which is only used internally
> can create real problems for the company when its internal luser has an
> attack of the stupid-cough.

I have been and am both plus numerical mathematician.

Indeed, broken code can be a pain but not only gets is guilty. There are
many ways code can be broken. Like system shell-scripts that work only
in a particular environment (I have seen it, a script using ex, assuming
the environment of the writer...). In many of those cases gets was the
least of my problems.

 

[Keith Thompson]

Just to be clear, I did not say that. I said, in a post sent at 00:00
on 10/03/09
"gcc is close to claiming C99 conformance. MSVC isn't likely to, but
does support much of C99."

[...]

Mark, just to be clear ...

When you wrote that MSVC "does support much of C99", were you
referring to the fact that it supports C90 (which is much of C99), or
were you saying that it supports much of the portion of C99 that isn't
in C90? If the former, it seems like a rather odd way of saying it;
if the latter, I believe it's incorrect (unless you consider long long
and // comments to be "much", or MSVC conforms better than I think it
does).

 

[Dik T. Winter]

> Are you asserting that harm cannot be done without elevated
> privileges? Will you allow me to log into your (presumably
> unprivileged) account and do whatever I feel like?

Without elevated privileges harm can only be done to the user that uses the
faulty program, unless the program has elevated privileges.

On some other remarks made by others:

(1) What if my program gets used by a system program with higher privileges?

A: It is stupid when a program with higher privileges runs a program over
which it has no control with the same privile ges. It should *always*
run that external program with lower privileges, otherwise you open the
possibiity for trojan horses.

(2) About my (potential) program that analyses logs and that uses gets, the
question was: would you run that program when somebody came to me asking
me to run the file on *his* logfile?

A: Of course not. The first question would be where the logfile came from.
The program would be designed to analyse logfiles written by particular
programs, and they go into a single place in the plethora of machines we
have here.A If the other has an own logfile it is certainly not the
kind of logfile for which it is intended.

About my programs using "gets". I have looked, the Rubik's cube solver
uses getchar. The only program in my ftp directory (ftp://ftp.cwi.nl/pub/dik)
that uses gets is "number", found as "number.shar.Z". I even use it on my
website (that due to a race condition does not work as expected on the base
page), but not in a way that anybody has control over its input.

 

[CBFalconer]

.... snip ...

And of course the reverse is also true - from Mark McIntyre's
perspective, Jacob Navia is wrong. These views can never be
reconciled until the two parties agree on a common dictionary.

In what language?

 

[Dik T. Winter]

>
> You skipped a point
>
> 0) break the machine security to obtain access to high-priv programmes.
> Once you've done that, you can do (1a).

And (1a) is not correct. You need to find a high-priv program that calls
the filter with the same privileges. High-priv programs should really
know what privileges the programs they call inherit, and why.

 

[CBFalconer]

That's certainly true. My point is that there's nothing intrinsically
wrong with offending someone by lodging a truthful accusation against
them; if a truthful accusation offends them, it is entirely right and
proper that they should be offended - it is in fact a state of affairs
to be preferred to them being complacent in their misdeeds. However,
there is definitely something wrong with lodging a false accusation.

However it appears as if Jacob has gone off in a snit, and is no
longer noticing this discussion of him and his habits.

 

[CBFalconer]

CBFalconer said:

ITYM "incompatible" - note the recent disabling of %n in printf.

That appears to be exactly what I wrote, so I guess I can agree
with you.

 

[CBFalconer]

Sure. But the value has already been stored and if there are
millions of malloc pointers to be managed, the programmer now
also has the headache of storing the sizes?

You seem to be under the misapprehension that banishing such
storage to the malloc system will make it available without cost.
If you wish, you can simply add a size_t field to each object
malloced, and set it during the malloc operation.

void *newmalloc(size_t sz) {
void *p;
size_t *s;

if (!(p = malloc(sz + sizeof(size_t)) return p;
s = p;
*s = sz;
return ((char *)p + sizeof(size_t));
} /* untested */

and a corresponding newfree. realloc and calloc may need
attention.

 

[CBFalconer]

.... snip ...

The gets() implementation which gets a non-NULL value from
alloc_size can then test against the limit (I had in mind the
address of the end of the allocated block), and prevent buffer
overflows.

I think you will find that the implementation of ggets() is
somewhat simpler. See:

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

 

[Eric Sosman]

Are you asserting that harm cannot be done without elevated
privileges? Will you allow me to log into your (presumably
unprivileged) account and do whatever I feel like?

Without elevated privileges harm can only be done to the user that uses the
faulty program, unless the program has elevated privileges.
[...]

Thesis: "root" and "Administrator" are not the only
accounts that own things worth protecting.

If you disagree, post your access information here.

 

[Ben Bacarisse]

You seem to be under the misapprehension that banishing such
storage to the malloc system will make it available without cost.
If you wish, you can simply add a size_t field to each object
malloced, and set it during the malloc operation.

void *newmalloc(size_t sz) {
void *p;
size_t *s;

if (!(p = malloc(sz + sizeof(size_t)) return p;
s = p;
*s = sz;
return ((char *)p + sizeof(size_t));
} /* untested */

The resulting pointer may not be properly aligned for all types so it
is not a plug-in replacement for malloc and may cause undefined
behaviour if it is used as one.

 

[qarnos]

So that's why this was the only test program I could get working:

    // comment
    long long i;

I hope they get functions, int, char, etc. implemented sometime soon! It
sucks being able to write only programs with C++-style comments and long
long variables...

Well, they also have identifiers

For the record, MSVC does support __declspec(inline) and __declspec
(restrict). It makes you wonder why they don't just get rid of the
__declspec.

 

[Phil Carmody]

Dik T. Winter said:

And (1a) is not correct. You need to find a high-priv program
that calls
the filter with the same privileges.
Acknowledged.

High-priv programs should
really know what privileges the programs they call inherit, and
why.

The vast majority of people (and I specifically exclude you from
this, despite some reservations about your apparent gets() defence)
who use gets() show themselves[1], by that mere fact, to be
sufficiently naive about security not to understand the importance
of getting privileges right.

[1] In my opinion, at least. I suspect that it is an opinion you do
not share.

It's a hasty generalisation. But who cares if, IME, it's a
generalisation that's correct 99% of the time.

Of course, it's perfectly possible to write code which calls gets
without any buffer-overrun weaknesses, even if the input cannot
be trusted. (But don't take that as advocacy for its use, please!)

Phil