On the development of C

[Guest]

On 11 Mar, 23:24, Mark McIntyre <[email protected]>
wrote:

Avoid hyperbole at all costs, its the most destructive argument on the
planet.

</snarf>

 

[Guest]

 >      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.

root and admin are not the only things with elevated privileges.

he said:

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

Not everything in the world runs on a badly configured Windows
machine.

     If you disagree, post your access information here.

I don't disagree that root and admin aren't the only things that need
protection

 

[Guest]

I'm not sure I understand how that applies.

I'm assuming Jacob isn't trying to be offensive because
that is my default assumption about people. Never ascribe to malice
that which can be explained by ignorance.

Are you implying that a
good human being would avoid pointing out a lie, in order to avoid
offending the liar?

No. Though I wouldn't start there.

 Are you advocating the use of euphemisms?
Yes.


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.

teenagers and geeks would tend to agree with you. Most adults wouldn't

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

if you don't know that statements can be offensive regardless of
their
truth then I can't help you.


--
Nick Keighley

Moving parts in rubbing contact require lubrication to avoid excessive
wear.
Honorifics and formal politeness provide lubrication where people rub
together.
Often the very young, the untraveled, the naive, the unsophisticated
deplore
these formalities as "empty," "meaningless," or "dishonest," and scorn
to use
them. No matter how "pure" their motives, they thereby throw san into
machinery
that does not work too well at best.
(Lazerus Long "Time Enough For Love")

 

[James Kuyper]

I'm assuming Jacob isn't trying to be offensive because
that is my default assumption about people. Never ascribe to malice
that which can be explained by ignorance.

I am ascribing it to ignorance and righteous indignation, not malice:
I'm assume that he's expressing entirely sincere righteous indignation
based upon a mistaken belief that a lie was committed. His behavior
would have been fully justified and entirely appropriate, if he had not
been mistaken.

The malicious interpretation would be that he knows it wasn't a lie, and
called it one anyway - I'm not making that interpretation.

....

if you don't know that statements can be offensive regardless of
their
truth then I can't help you.

I know very well that they can be offensive. Where I disagree with you
is about the unacceptability of causing offense. I consider it entirely
appropriate, indeed a moral obligation, to make sure that people KNOWN
to have done something wrong are dealt with in a manner that would be
inappropriately impolite if there were any reasonable doubt about their
guilt: this is one of the key ways in which a society regulates people's
behavior when it is not sufficiently bad to justify taking legal action.

The key point here is whether or not the person's guilt is certain; and
that's where jacob's behavior is at fault.

 

[Chris McDonald]

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!)

Sorry, I don't quite understand this statement.
For any sized input buffer that code passes to gets(),
I can provide input longer than buffer.
So how is it possible to avoid all possible overrun weaknesses?

 

[Eric Sosman]

Sorry, I don't quite understand this statement.
For any sized input buffer that code passes to gets(),
I can provide input longer than buffer.
So how is it possible to avoid all possible overrun weaknesses?

Perhaps by substituting some other problem?

gets(NULL);

gets((char*)gets);

fclose(stdin);
gets(buffer);

 

[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.
> > [...]

>
> Thesis: "root" and "Administrator" are not the only
> accounts that own things worth protecting.
>
> If you disagree, post your access information here.

In what way do you disagree with what I wrote (except that it is not
formulated too well)?

 

[Chris McDonald]

In ISO C:

1. Read some untrusted input safely.
2. Dump the untrusted input into a file, imposing a length restriction.
3. At a later point, associate stdin with that file by calling freopen().
4. Call gets().

So, in summary, you're proposing (obviously with no seriousness) that all
untrusted input should be preprocessed before being read by gets().

It's unclear what such a comment adds to the discussion,
and how anyone hoping to learn anything from it benefits.

Maybe you should ask him.

Ummm, I did.

Yours,

Not mine.

 

[Ben Bacarisse]

In ISO C:

1. Read some untrusted input safely.
2. Dump the untrusted input into a file, imposing a length restriction.
3. At a later point, associate stdin with that file by calling freopen().
4. Call gets().

In the same vein it is wrong to say that scanf("%ld", &n) can't be
used without risking UB, because we can convert the number using
strtol, check that no overflow happens, write the number to a file
file, associate stdin with it and call scanf("%ld", &n).

Some true statements do help in gaining understanding.

 

[Nate Eldredge]

The most straightforward answer is that it's undefined behavior, just
as free(buffer) would be.

It's already entirely possible for an implementation to provide this
kind of thing as an extension. (Do any implementations do so? If
not, why don't they?)

FreeBSD provides a `malloc_usable_size()' function, which returns not
the size originally passed to malloc(), but the amount of space that was
actually allocated (which usually has been rounded up.)

The documentation says, somewhat enigmatically:

The malloc_usable_size() function returns the usable size of the alloca-
tion pointed to by ptr. The return value may be larger than the size
that was requested during allocation. The malloc_usable_size() function
is not a mechanism for in-place realloc(); rather it is provided solely
as a tool for introspection purposes. Any discrepancy between the
requested allocation size and the size reported by malloc_usable_size()
should not be depended on, since such behavior is entirely implementa-
tion-dependent.

It expects to be passed the original pointer returned by malloc(). If
you pass it a pointer to elsewhere within the buffer, then depending on
the method used for that specific allocation (which varies depending on
the size), it may return the total size of the block, return a random
nonsense value, or crash.

 

[Phil Carmody]

Sorry, I don't quite understand this statement.
For any sized input buffer that code passes to gets(),
I can provide input longer than buffer.
So how is it possible to avoid all possible overrun weaknesses?

I'm glad someone spotted that and had a double-take.

I leave it as a just-for-fun challenge to c.l.c to provide
an example (which doesn't have other issues) by mid-weekend
(when I'll spill the beans). 1 kudo to anyone who gets my
answer, 2 kudos to anyone who gets a fundamentally different
answer.

Phil

 

[Richard Bos]

I'm assuming Jacob isn't trying to be offensive because
that is my default assumption about people. Never ascribe to malice
that which can be explained by ignorance.

Do not forget, though:

Ignorance, when insistent or egregious enough, _is_ a form of malice.
-- Richard's objection to Hanlon's Razor

Richard

 

[Richard Bos]

1 kudo

*Thwack*

Kudos is a _single_ noun of Greek extraction.

Richard

 

[Richard Bos]

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.

True. There are also many ways in which I can be killed in traffic,
several of them more dangerous than driving through a red light (at
least, at many lights in this backwater), but I still make it a point
not to.

Richard

 

[Default User]

Thwack

Kudos is a single noun of Greek extraction.

I am experiencing a patho for your suffering.




Brian

 

[jameskuyper]

Richard Bos wrote:
....

Ignorance, when insistent or egregious enough, _is_ a form of malice.

I can't see any way of interpreting that as a true statement.
Ignorance is a lack of knowledge, malice is ill will; I don't see any
way for a lack of knowledge to somehow transmute into ill-will. Lack
of knowledge can cause ill-will, and vice versa, but that doesn't seem
to be what you're saying, and it certainly doesn't fit the context.

 

[Phil Carmody]

*Thwack*

Kudos is a _single_ noun of Greek extraction.

I don't speak Grecian, I speak English, so I don't care
about the entomology.

Phil

 

[Anand Hariharan]

Sorry, I don't quite understand this statement.
For any sized input buffer that code passes to gets(),
I can provide input longer than buffer.
So how is it possible to avoid all possible overrun weaknesses?

I guess it all depends upon how one interprets "... possible to write
code which calls gets ...".

if (false)
gets(NULL);

- Anand

 

[Tim Rentsch]

I don't speak Grecian, I speak English, so I don't care
about the entomology.

Seven kudae. Or is that quatloos? I can never remember.

 

[CBFalconer]

I'm glad someone spotted that and had a double-take.

I leave it as a just-for-fun challenge to c.l.c to provide an
example (which doesn't have other issues) by mid-weekend (when
I'll spill the beans). 1 kudo to anyone who gets my answer, 2
kudos to anyone who gets a fundamentally different answer.

I'll take that on. Let us assume the unlimited input data has been
captured in 'badfile.txt'. We need a means of reading that file
using gets, and where no buffer overrun can ever occur. I am going
to apply my ggets in the preliminary, but not in the final read.
This is valid since ggets is written in purely standard C. You can
get ggets at:

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

I will omit the necessary file openings and closings. Provisions
need to be taken to avoid altering badfile.txt between the first
open and the final close (after reading with gets).

First, we access and open badfile.txt, forming a rewound FILE* in
badf.

char *buf, *lbuf;
size_t blgh, lblgh;

if (0 != fggets(&buf, badf))
abort("No legible data in badfile.txt");
lblgh = strlen(buf);
lbuf = buf;
while (0 == fggets(&buf, badf)) {
blgh = strlen(buf);
if (lblgh < blgh) {
free(lbuf); lbuf = buf;
}
else free(buf);
}
/* Now, barring i/o errors, lbuf contains the longest line */

/* rewind badf, i.e. the file badfile.txt. */

while (gets(lbuf)) {
/* do whatever you wish with lbuf, but don't free it. */
}
/* and you have read that file cleanly with gets */

This needs revisions to ensure that the input file is always
stdin. When that is done we can also replace fggets with ggets
(which is just a macro).