Listing the most dangerous parts of C

[Juuso Hukkanen]

I am looking for a wish list of things which should be removed from
the C (C99) - due to feature's bad security track record <OT>or
Multithreading unsafety. I need this list for a project intending to
build another (easiest & most powerful) programming language, which
has a two page definition document stating: "... includes C
programming language (C99), except its famous
"avoid-using-this-functions". </OT>

If you would not want to remove a whole function but only the use of
it with certain arguments / parameters, what would those combinations
be like? (Like scanf with %s or %[ arguments )

Probably there are official not to use recommendation lists.
( million times better than this)
http://tele3d.com/wiki/index.php/Par...ncluded_in_t3d

Please, do not circumvent the question by saying all functions except
gets() are safe if used properly. That would be like teaching that
"the ideology of Soviet Union was right, it was the Soviet peoples
fault that the system didn't work.

Juuso Hukkanen
(to reply by e-mail set addresses month and year to correct)
www.tele3d.com

[Keith Thompson]

Skarmander <in*****@dontma ilme.com> writes:

Andrew Poelstra wrote:

On 2006-05-10, Rod Pemberton <do*********@bi tfoad.cmm> wrote:

If you really want to get crazy with C, do some of these:
1) eliminate pointers in main

Seems like any problems associated with that would be poor
programming practice.

2) make pointers be associated with a variable before use, not with a data
type

Ditto.

3) eliminate malloc, add dynamic allocation and garbage collection

Now you've got a Java-like beast, only to solve programmers who can't keep
track of memory.

Exactly. Garbage collection is for people who are stupid or lazy or
both. Everyone knows that keeping track of memory yourself is better
and cleaner. Keeps the mind in shape and your programs fast.

Or something like that, at least.

Right. Mnemonic identifiers are also a crutch for the weak-minded.
Objects should be identified by serial numbers, preferably in
hexadecimal. I mean, we can't very well trust computers to keep track
of things like this; most of them are prorammed by lazy people.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Dave Vandervies]

In article <bm************ *************** *****@4ax.com>,
Juuso Hukkanen <ju***********@ tele3d.net> wrote:

I am looking for a wish list of things which should be removed from
the C (C99) - due to feature's bad security track record

Side effects.

If you don't allow anything that can have side effects, then nothing
can cause problems.
dave

--
Dave Vandervies dj******@csclub .uwaterloo.ca
If we assume that the programmer is unfamiliar with the language he is
using, then order of evaluation is the least of our worries.
--Joe Marshall in comp.lang.schem e

[Keith Thompson]

Keith Thompson <ks***@mib.or g> writes:
[...]

Right. Mnemonic identifiers are also a crutch for the weak-minded.
Objects should be identified by serial numbers, preferably in
hexadecimal. I mean, we can't very well trust computers to keep track
of things like this; most of them are prorammed by lazy people.

In particular, some of them are "prorammed" by people who are too lazy
to proofread before posting.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[qed]

Ben Pfaff wrote:

qed <us********@azi llionmonkeys.co m> writes:

I would get rid of ungetc just on principle (can't unread at the
beginning of a file, may screw up fgetpos(), only does a single
character -- its just super lame, and throws a monkey wrench into too
many other functions.)

I am unaware of a limitation on calling ungetc() at the beginning
of a file. I scanned the definition of ungetc() in C99 and
didn't see such a limitation--did I miss something?

"For a binary stream, its file position indicator is decremented by each
successful acll to the ungetc function; if its value was zero before a
call, its indeterminate after the call".

Whatever, if you are thinking about it from an implementators point of
view, its obvious what's wrong with this whole idea. Its stupid in
exactly the same way that fgets ignoring '\0' in its input stream is
stupid. Its the only function that behaves like that in a nest of other
functions that want things to behave differently.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[CBFalconer]

qed wrote:

.... snip ...
I am not sure why you want to get rid of srand() or rand(). Its true
they suck as PRNGs, and race conditions mess them up in ways that can be
worse than you think (and RAND_MAX is generally pathetically small), but
I don't think people generally abuse them to that degree of detriment in
the real world. Again, if you had a *substitute*, that would be fine.
The problem is that I am not aware of any good portable PRNGs -- are you
(hence supporting the idea that C is not a portable language)? As for
non-portable ones, there are plenty (such as Mersenne Twister, or any of
the Marsaglia generators.) So as long as we are stuck with *something*
-- they still can serve a role as a quick and dirty PRNG. (The right
answer here is to demand that the standard change how it works --
however a quick perusal of their guiding principles, indicates there is
no mechanism by which you could reasonably do this.)

Why do you consider the MT non-portable? I took one implementation
and removed the portability problems, by and large, except that I
was not sure that it would function correctly when a long was
larger that 32 bits. So my source creates an error for that
situation, leaving it up to someone else to decipher.

You can find my modification of it within the hashlib package,
where it is used to control regression testing.

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

--
Some informative links:
news:news.annou nce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[CBFalconer]

Ben Pfaff wrote:

qed <us********@azi llionmonkeys.co m> writes:

I would get rid of ungetc just on principle (can't unread at the
beginning of a file, may screw up fgetpos(), only does a single
character -- its just super lame, and throws a monkey wrench into
too many other functions.)

I am unaware of a limitation on calling ungetc() at the beginning
of a file. I scanned the definition of ungetc() in C99 and
didn't see such a limitation--did I miss something?

ungetc is absolutely essential to provide one char look ahead
operation. Without it it is impossible to properly connect
divergent parsing modules. The only case known to me where the one
char limitation creates a problem is in parsing floats with an
invalid exponential part.

--
Some informative links:
news:news.annou nce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[Christopher Benson-Manica]

Rod Pemberton <do*********@bi tfoad.cmm> wrote:

1) 15 C functions suffer buffer overflow problems:
gets() cuserid() scanf() fscanf() sscanf() vscanf() vsscanf() vfscanf()
sprintf() strcat() strcpy() streadd() strecpy() vsprintf() strtrns()
However, of those functions that are standard C functions, only one,
gets(), is *intrinsically* vulnerable to buffer overruns. Using the
other functions correctly is part of what separates a programmer from
a monkey banging on a keyboard.
If you really want to get crazy with C, do some of these:
1) eliminate pointers in main
Why not just eliminate pointers altogether? There's a language that
does that for you, it's called Java. Otherwise, eliminating pointers
in some arbitrary function (be it main() or anything else) only
deprives you of a tool C gives you to write good, effective code for
no good reason.
3) eliminate malloc, add dynamic allocation and garbage collection
Again, Java does this for you. Perhaps a different language is
desired?
4) change C to pass by reference
Why, so you can have special tricks for passing by value?
6) give up now, and try Walter Bright's D language...

Or Java :-)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Christopher Benson-Manica]

Richard Heathfield <in*****@invali d.invalid> wrote:

Okay, drop gets(), scanf(), and strncpy() - ironically, this is unsafe
chiefly because people think it's safe and so they feel free to use it in a
rather cavalier way!

Alternatively, strncpy() could just work in the way we expect :-) I
always have to resort to a reference to remind myself that strncpy is,
in fact, a bit of a charlatan.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Ben Hinkle]

> 6) give up now, and try Walter Bright's D language...

D is no silver bullet. It has as many quirks as anything else. I wrote
several libraries for it over the past few years
http://home.comcast.net/~benhinkle/mintl/
http://home.comcast.net/~benhinkle/minwin/
http://home.comcast.net/~benhinkle/gmp-d/
and decided to give a shot at making something closer to C:
http://www.tinycx.org
If you read more than 1 paragraph then thanks in advance! :-)

-Ben

[qed]

Rod Pemberton wrote:

I read a security oriented pdf (sorry, don't know where anymore) which said:

1) 15 C functions suffer buffer overflow problems:
gets() cuserid() scanf() fscanf() sscanf() vscanf() vsscanf() vfscanf()
sprintf() strcat() strcpy() streadd() strecpy() vsprintf() strtrns()

2) 8 C functions suffer from format string vulnerabilities
printf() fprintf() sprintf() snprintf() vprintf() vfprintf() vsprintf()
vsnprintf()

Summary of pdf: Because many C implementations use the same stack for
string data and flow control information (like addresses), the above
functions can modify the flow control information on the stack thereby
allowing authorized code to execute.
That's only one kind of catastrophic failure. Personally, I would be
more focused on the fact that the failures happen in the first place.
If you really want to get crazy with C, do some of these:
1) eliminate pointers in main
Huh? I probably need some elaboration here. Do you literally mean that
you shouldn't have local variables in main that are passed by reference
to other functions? Or ... what *do* you mean?
2) make pointers be associated with a variable before use, not with a data
type
Huh? You mean that building linked lists and similar data structures
should take an additional operation (first assign the new node malloc to
a variable) or do you mean that making such things should be impossible?
3) eliminate malloc, add dynamic allocation and garbage collection
Ok, but then you are no longer programming in C. C is a language that
allows you to understand the *performance* of your application very
clearly. Java is a language allows you to understand what it *does*
very clearly. The two languages are differentiated by this difference
in philosophy. Making C more like Java is just as easily achieved by
throwing it out and starting with Java.

However, I understand the motivation. Why not instead ask for *more*
from the C universe? There are many ways of *extending* the whole
malloc/etc paradigm to make it safer, *faster* and more powerful.
4) change C to pass by reference
Ok, no. Adding refs (the & thingy from C++) I agree with, because
passing pointers tends to more dangerous in general (more likely to pass
in NULL, or garbage/uninitialized pointers) for some cases. However to
be general, you must support *both* semantics, and C does this by
allowing you to pass a pointer in lieu of references. But don't take
away call by value from the language.
5) require separation of string (and other) data and flow control
information
You mean don't throw growable data types into non-growable arrays on a
stack? I agree. Bstrlib makes exactly this distinction (there is no
sane way to put a non-constant bstring on the stack). Perhaps only
allowing bounds protected enforced types into auto variables.
6) give up now, and try Walter Bright's D language...

Because "C++++" would have been too tacky. You could instead look at
languages like Python, Lua, and Java and ask yourself, what would it
take to design a language that was as easy to use as Python/Lua, and
safe and predictable as Java, with the speed of C?

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/