(e-mail address removed) wrote
(in article
C gives you access to a sequence of opcodes in ways that other
languages do not? What exactly are you saying here? I don't
understand.
asm( character-string-literal ); springs to mind. I do not
believe all languages have such abilities. Having that kind of
capability alone, nevermind pointers and all of the subtle and
no so subtle tricks you can do with them in C makes it capable
of low-level work, like OS internals. There are lots of
landmines there, as you are probably already aware.
Yes of course! When people learn a new language they learn what it
*CAN* do before they learn what it should not do. It means anyone that
learns C first learns to use gets() before they learn not to use
gets().
Strange, it has been years since I have picked up a book on C
that uses gets(), even in the first few chapters. I have seen a
few that mention it, snidely, and warn against it though.
The man page for gets() on this system has the following to say:
SECURITY CONSIDERATIONS
The gets() function cannot be used securely. Because of its
lack of bounds checking, and the inability for the calling
program to reliably determine the length of the next incoming
line, the use of this function enables malicious users to
arbitrarily change a running program's functionality through a
buffer overflow attack. It is strongly suggested that the
fgets() function be used in all cases.
[end of man page]
I don't know about you, but I suspect the phrase "cannot be used
securely" might slow quite a few people down. It would be even
better if they showed an example of proper use of fgets(), but I
think all man pages for programming interfaces would be improved
by doing that.
You are suggesting that making C safer is equivalent to removing
buffer overflows from assembly. The two have nothing to do with each other.
Not equivalent, but difficult. Both languages are very powerful
in terms of what they will 'allow' the programmer to attempt.
There is little or no hand-holding. If you step off the edge,
you get your head chopped off. It's not like you can make some
simple little tweak and take that property away, without
removing a lot of the capabilities overall. Yes, taking gets()
completely out of libc (and its equivalents) would be a good
start, but it wouldn't put a dent in the ability of programmers
to make many more mistakes, also of a serious nature with the
language.
Just as I can appreciate the differences between a squirt gun
and a Robar SR-90, I can appreciate the differences between
Python and C, or any other 'safer' language and assembler.
Terse, HLA, Rosasm, LuxAsm -- this is all for *one* assembly language.
I was referring to your use of 'many people', which is, unless I
am mistaken, the only use of 'many' above.
Oh by the way there is a new version! It incoroporates a new secure
non data-leaking input function!
You mean it wasn't secure from day one? tsk, tsk. That C stuff
sure is tricky.
Soon to reach 5000 downloads and
80000 webpage hits! Come join the string library revolution and visit:
http://bstring.sf.net/ to see all the tastey goodness!
LOL.
You mean it closes the most obvious and well trodden thousand doors out
of a million doors.
Both work out to .001. Hmmm.
Assembly is not a real application development language no matter how
you slice it.
I hope the HLA people don't hear you saying that. They might
get riotous.
So I'm would be loath to make any point about whether or
not you should expect application to become safer because they are
writing them in assembly language using Bstrlib-like philosophies. But
maybe those guys would beg to differ -- who knows.
Yes.
As I recall this was just a point about low level languages adopting
safer interfaces. Tough in this case, the performance improvements
probably drives their interest in it.
Exactly. C has performance benefits that drive interest in it
as well. If there was a language that would generate faster
code (without resorting to hand-tuned assembly), people would be
using it for OS internals.
I don't think it should have been used for some things, like
taking what should be a simple shell script and making a binary
out of it (for copyright/copy protection purposes) like is done
so often. Many of the tiny binaries from a C compiler on a lot
of systems could be replaced with simple scripts with little or
no loss of performance. But, somebody wanted to hide their
work, or charge for it, and don't like scripting languages for
that reason. People even sell tools to mangle interpreted
languages to help with this. That is not the fault of the C
standard body (as you originally implied, and lest we forget
what led me down this path with you), but the use of C for
things that it really isn't best suited. For many simple
problems, and indeed some complicated ones, C is not the best
answer, yet it is the one chosen anyway.
I never put those languages up as alternatives for speed. The false
dichotomy yet again.
Then enlighten us. I am familiar with Fortran for a narrow
class of problems of course, and I am also familiar with its
declining use even in those areas.
No introspection capabilities. I cannot write truly general
autogenerated code from the preprocessor, so I don't get even the most
basic "fake introspection" that's should otherwise be so trivial to do.
No coroutines (Lua and Python have them) -- which truly closes doors
for certain kinds of programming (think parsers, simple incremental
chess program legal move generators, and so on). Multiple heaps which
a freeall(), so that you can write "garbage-collection style" programs,
without incurring the cost of garbage collection -- again there are
real applications where this kind of thing is *really* useful.
Then by all means use alternatives for those problem types. As
I said a way up there, C is not the best answer for everything,
it just seems to be the default choice for many people, unless
an obvious advantage is gained by using something else.
[...] It seems to be the only language other than
assembler which has been used successfully for operating system
development.
The power I am talking about is power to program. Not the power to
access the OS.
So we agree on this much then?
Right. Because you write every piece of C code that's ever been
written right?
Thankfully, no. The point, which I am sure you realize, is that
C can, and often is used for portable programs. Can it be used
(in non-standard form most of the time btw), for writing
inherently unportable programs? Of course. For example, I
could absolutely insist upon the existence of certain entries in
/proc for my program to run. That might be useful for a certain
utility that only makes sense on a platform that includes those
entries, but it would make very little sense to look for them in
a general purpose program, yet there are people that do that
sort of silly thing every day. I do not blame Ritchie or the C
standards bodies for that problem.
Ok, first of all runtime error handling is not the only path.
Quite. I wasn't trying to enumerate every possible reason that
C would continue to be used despite it's 'danger'.
Well just a demonstration candidate, we could take the C standard, add
in Bstrlib, remove the C string functions listed in the bsafe.c module,
remove gets and you are done (actually you could just remove the C
string functions listed as redundant in the documentation).
What you propose is in some mays very similar to the MISRA-C
effort, in that you are attempting to make the language simpler
by carving out a subset of it. It's different in that you also
add some new functionality. I don't wish to argue any more
about whether MISRA was good or bad, but I think the comparison
is somewhat appropriate. You could write a tome, entitled
something like "HSIEH-2005, A method of providing more secure
applications in a restricted variant of C" and perhaps it would
enjoy success, particularly amongst people starting fresh
without a lot of legacy code to worry about. Expecting the
entire C community to come on board would be about as naive as
expecting everyone to adopt MISRA. It's just not going to
happen, regardless of any real or perceived benefits.
Uhh ... actually no. People like my Bstrlib because its *safe* and
*powerful*. They tend not to notice or realize they are getting a
major performance boost for free as well (they *would* notice if it was
slower, of course). But my optimization and low level web pages
actually do have quite a bit of traffic -- a lot more than my pages
critical of apple or microsoft, for example.
So you are already enjoying some success then in getting your
message across.
Its not hard to beat compiler performance, even based fundamentally on
weakness in the standard (I have a web page practically dedicated to
doing just that; it also gets a lot of traffic). But by itself, that's
insufficient to gain enough interest in building a language for
everyday use that people would be interested in.
Indeed.
[...] "D" is already taken, what will you call it?
How about "C"?
Well, all you need to do is get elected ISO Dictator, and all
your problems will be solved.
Ok, well then we have an honest point of disagreement then. I firmly
believe that the current scourge of bugs that lead to CERT advisories
will not ever be solved unless people abandon the current C and C++
languages.
Probably a bit strongly worded, but I agree to a point. About
90% of those using C and C++ today should probably be using
alternative languages. About 20% of them should probably be
working at McDonald's, but that's an argument for a different
day, and certainly a different newsgroup.
I think there is great concensus on this. The reason why I
blame the ANSI C committee is because, although they are active, they
are completely blind to this problem, and haven't given one iota of
consideration to it.
I suspect they have considered it a great deal, and yet not
provided any over action that you or I would appreciate. They
are much concerned (we might easily argue 'too much') with the
notion of not breaking old code. Where I might diverge with
that position is on failing to recognize that a lot of 'old
code' is 'broken old code' and not worth protecting.
Even though they clearly are in the *best*
position to do something about it.
I actually disagree on this one, but they do have a lot of power
in the area, or did, until C99 flopped. I think the gcc/libc
crowd could put out a x++ that simply eradicates gets(). That
should yield some immediate improvements. In fact, having a
compiler flag to simply sqwawk loudly every time it encounters
it would be of benefit. Since a lot of people are now using gcc
even on Windows systems (since MS isn't active in updating the C
side of their C/C++ product), it might do a lot of good, far
sooner, by decades than a change in the standard.
And its them any only them -- the
only alternative is to abandon C (and C++) which is a very painful and
expensive solution; but you can se that people are doing exactly that.
Not a lot of Java in those CERT advisories.
That's good. The more people move to alternate languages, the
more people will have to realize that security bugs can appear
in almost any language. Tons of poorly written C code currently
represents the low-hanging fruit for the bad guys.
And so are you saying it didn't cost you anything when you first
learned it?
Since I did not have a million lines of C to worry about
maintaining at the time, indeed very little, it was not very
expensive. I'll admit it wasn't zero-cost, in that it took me
whatever time it was for the point to soak in, and to learn
better alternatives. I could have recouped some of the 'cost'
be selling some old Schildt books to unsuspecting programmers,
but felt that would have been uncivilized.
And that it won't cost the next generation of programmers,
or anyone else who learns C for the first time?
Provided that they learn it early on, and /not/ after they ship
version 1.0 of their 'next killer app', it won't be that bad.
Given that it shouldn't be taught at all to new programmers
today (and I am in favor of pelting anyone recommending it today
with garbage), I suspect it will be eradicated for all practical
purposes soon.
C99 is not being adopted because there is no *demand* from the users or
development houses for it. If the standard had been less drammatic,
and solved more real world problems, like safety, for example, I am
sure that this would not be the case.
Do I think C99 was for many people of no tangible value, or
enough improvement to justify changing compilers, related tools
and programmer behavior? Unfortunately, yes. It was a lot of
change, but little meat on the bones.
However, there was also the problem that C89/90 did for many
people exactly what they expected from the language, and for a
significant sub-group of the population, "whatever gcc adds as
an extension" had become more important than what ISO had to say
on the matter. The stalling out of gcc moving toward C99
adoption (due to conflicts between the two) is ample support for
that claim.
You also ignore the fact that
the C++ folks typically pick up the changes in the C standard for their
own. So the effect of the standard actually *is* eventually
propogated.
Here I disagree. C and C++ are not closely related anymore. It
takes far longer to enumerate all the differences that affect
both than it does to point out the similarities. Further, I
care not about C++, finding that there is almost nothing about
C++ that can not be done a better way with a different language.
C is still better than any reasonable alternative for a set of
programming tasks that matter to me, one in which C++ doesn't
even enter the picture. That is my personal opinion of course,
others may differ and they are welcome to it.
The fact that it would take a long time for a gets() removal in the
standard to be propogated to compiler, I do not find to be a credible
argument.
Why not? If the compiler doesn't bitch about it, where are all
of those newbie programmers you are concerned about going to
learn it? Surely not from books, because books /already/ warn
about gets(), and that doesn't seem to be working. If they
don't read, and it's not in the compiler, where is this benefit
going to appear?
Also note thast C89, had very fast adoption. It took a long time for
near perfect and pervasive adoption, but you had most vendors more than
90% of the way there within a very few years.
Because it was very similar to existing practice, and a smaller
language standard overall. Far less work. Frankly, I have had
/one/ occasion where something from C99 would have made life
easier for me, on a single project. It turned out I didn't get
to use it anyway, because I did not have access to C99 compilers
on all of the platforms I needed to support, so I did it
differently. I don't anticipate 'wishing' for a C99 compiler
much, if at all, in the future either. The problem domains that
C became dominant for are well-served by C89/90, as is, just
stay away from the potholes. I certainly do not need a C05
compiler just to avoid gets(), I've been doing it with C89
compilers for many years.
A compiler error telling the user that its wrong (for new platform
compilers) is the best and simplest way to do this.
And we both say that, several times, we seem to differ only in
the requirements to make that change.
Uh ... but you see that its still better than nothing right?
So is buying lottery tickets for the worst programmer you know.
You think programming will suddenly stop in 15 years?
Yeah, that's exactly what I was thinking. How did you guess?
Do you think there will be less programmer *after* this 15
year mark than there has been before it?
Nope. but I think it will 15 years too late, and even if it does
come, and the gets() removal is part of it, which assumes facts
not in evidence, that there will STILL be a lot of people using
C89/90 instead. I would much rather see it show up in compilers
with the next minor update, rather than waiting for C05, which
will still have the barrier of implementing the ugly bits of
C99, which the gcc crowd seems quite loath to do.
Or, like me, do you think C will just become COBOL in 15 years?
Yeah, as soon as a suitable replacement for system programming
shows up. Hold your breath, it's right around the corner.
The linker for the GNU linker already does this. But its perceived as
a warning. People do not always listen to warnings.
So make it email spam to the universe pronouncing "Someone at
foobar.com is using gets()!! Avoid their products!!!" instead.
Perhaps having the C runtime library spit out a warning on every
execution at startup "DANGER: THIS PROGRAM CONTAINS INSECURE
CODE!!!" along with a string of '\a' characters would be better.
I do not see a magic wand that will remove it for all time, the
genie is out of the bottle. Some nebulous future C standard is
probably the weakest of the bunch. I am not saying it shouldn't
happen, but it will not be sufficient to avoid the problem.
Use of old compilers is not the problem. The piles of CERT advisories
and news stories about exploits are generally directed at systems that
are constantly being updated with well supported compilers.
Which of those systems with CERT advisories against them have
recently updated C99 compilers? It's only been 6 years right?
How long will it be before they have a compiler you are happy
with, providing guaranteed expulsion of code with gets()?
Use of old compilers is definitely part of the problem, along of
course with badly trained programmers.
But nobody would believe your claim. My claim could be audited, and a
company would actually worry about being sued for making a false claim
of the sort I am advocating unless it were true.
If they can prove that no gets() or friends in the list are in
their product, then what is the worry? Put in a different way,
if they claimed "We're C 2010 compliant", just because they have
access to gcc2010, and yet it allows some command line argument
-std=c89, all bets are off anyway. Either way, they either use
gets() or they do not. As such, both claims are pretty similar.
Frankly, I don't care about marketing BS, so let's move on...
Did I misspeak and ask for deprecation? Or are you misrepresenting my
position as usual?
No, you just failed to notice the end of one sentence,
pertaining to your position, and the start of another one, with
the words "I would much rather see...".
I'm pretty sure I explicitely said "non-redefinable
in the preprocessor and always leads to an error" to specifically
prevent people from working around its removal.
And, just as I said above, which I will repeat to get the point
across (hopefull), "I AM NOT OPPOSED TO THEM BEING REMOVED".
I simply think more could be done in the interim, especially
since we have no guarantee of it every happening your way at
all.
... And you think there will be lots of CERT advisories on such
products? Perhaps you could point my to a few examples of such
advisories which are new, but which use old compilers such as Borland
C.
If your tactic is to only attack the people working on widely
deployed software likely to be involved in CERTs, I think the
"gets(), just say no" mantra is being driven into their head
practically every day. It's legacy code (and cleaning it) that
represents the bulk of the problem today. Scanning the complete
source tree for every product currently on the market would be
your best bet.
We can't do anything about legacy compilers -- and we don't *NEED TO*.
That's not the point. The "software crisis" is directed at development
that usually uses fairly well maintained compilers.
Well, if it is a 'crisis', then 15 years is definitely too long
to wait for a solution.
Ok ... that's interesting, but this is ridiculuous. As I said above,
you do not write every piece of software in the world.
A fact of which I am painfully aware each time I sit down at a
keyboard to a machine running Windows.
(For the record,
no, I do not think I would replicate Windows functionality and
improve on it, single-handedly.)
And we are well
aware of about 10,000 programmers living in the pacific northwest who
we know do *NOT* share your attitude.
Correct. Perhaps if they weren't so anxious to grab 20 year old
open source software and glue into their own products, there
would be less to worry about from them as well.
And you defence of the situation is that you assume every gainfully
employed programmer should be willing to quit the moment they see that
their process of programming is not likely to yield the highest
possible quality in software engineering.
That is /not/ what I said. The specific example in question had
to do with something that would be very dangerous if shipped.
The type of danger people would send lawyers hunting for you
over. there is a lot of room between that and "not likely to
yield the highest possible quality..."
Wild guess.
Very.
That isn't what I am saying. People's ability to quit or work at will
are often not related to things like programming philosophy or idealism
about their job. And software is and always will be created by
developers who have considerations other than the process of creating
perfect software.
Then we are in a lot of trouble. The ISO C body isn't going to
solve that problem. You better start tilting some more powerful
windmills, and do it quickly.
I implore you -- read the CERT advisories. Buffer Overflows are #1 by
a LARGE margin.
Yes. And when they are all gone, something else will be number
#1. As I already said, a lot of people have figured out how to
find and expose the low-hanging fruit, it's like shooting fish
in a barrel right now. It won't always be that way. I long for
the day when some whole in .NET becomes numero uno, for a
different reason than buffer overflows. It's just a matter of
time.
If you remove buffer overflows, it doesn't mean that other kinds of
bugs will suddenly increase in absolute occurrence. Unless you've got
your head in the sand, you've got to know that *SPECIFICALLY* buffer
overflows are *BY THEMSELVES* the biggest and most solvable, and
therefore most important safety problem in programming.
Yep. they're definitely the big problem today. do you really
think they'll still be the big problem by the time your C2010
compiler shows up in the field? It's possible of course, but I
hope not.
I'm not sure how this is an argument that Buffer Overflows aren't the
worst safety problem in programming by a large margin.
None of those problems actually have anything to do with programmer
abilities, or language capabilities. They have to do with corporate
direction, mismanagement, and incompetent program architecture. That's
a completely seperate issue.
Yes, I diverged in the wood, for no good reason, it was just too
bothersome for me to leave out, since it seemed related at the
time. Forgive me.
Uh ... no *you* are. My point was that he *COULDN'T* be.
OK. If that's your point, then how do you justify claiming that
the ISO C folks are culpable in buffer overflow bugs?
Sometimes you are *NOT AWARE* of your liability, and you don't *KNOW*
the situations where your software might be used.
So if your point is that the ISO committee knew about gets() and
allowed it to live on in C99, and that for example, 7.19.7.7
should contain some bold wording to that effect, I agree.
Better yet of course, marking it deprecated and forcing
compilers to emit an ERROR, not a warning for its use when
invoked in C99 conforming mode.
Even so, the knowledge was readily available elsewhere that
gets() was inherently unsafe at the time, and frankly, I have
met two or three programmers other than myself in the last 15
years that owned their own copy or copies of the applicable C
standards. Putting it in the document along wouldn't have
helped, but it is somewhat surprising that it didn't even rate a
warning in the text.
That was *my* point. Remember you are claiming that you want to pin
responsibility and liability for code to people so that you can dish
out punishment to them. I see a direct line of responsibility from
weakness in the C library back to him (or maybe it was Thompson or
Kernigham). And remember you want to punish people.
In the country I live, ex post facto laws are unconstitutional,
and I do not want to make people retroactively responsible
(although our elected representatives sometimes do).
Especially since they couldn't have possible been claiming
'certification' of any kind that far in the past, seeing it
doesn't even exist today.
Well no, but you can argue that they are responsible for the bugs they
introduce into their compilers. I've certainly stepped on a few of
them myself, for example. So if a bug in my software came down to a
bug in their compiler, do you punish me for not being aware of the bug,
or them for putting the bug in there in the first place?
It would be difficult, if not impossible, to answer that
generically about a hypothetical instance. That's why we have
lawyers. :-(
Steve Gibson famously railed on Microsoft for enabling "raw sockets" in
Windows XP.
Yes, I saw something about it on his website only yesterday,
ironically.
This allows for easy DDOS attacks, once the machines have
been zombified. Microsoft marketing, just like you, of course
dismissed any possibility that they should accept any blame whatsoever.
Don't put that one on me, their software exposes an interface in
a running operating system. If their software product leaves a
whole open on every machine it is installed on, it's their
fault. I see nothing in the ISO C standard about raw sockets,
or indeed any sockets at all, for well over 500 pages.
Can raw sockets be used for some interest things? Yes. The sad
reality is that almost /everything/ on a computer that is
inherently powerful can be misused. Unfortunately, there are
currently more people trying to break them than to use them
effectively.
Oh I see. So you just want to punish, IBM, Microsoft, Unisys, JASC
software, Adobe, Apple, ... etc. NOBODY caught the bug for about *10
years* dude.
Exactly. They all played follow-the-leader. I'm sure they'll
use the same defense if sued.
Everyone was using that sample code including *myself*.
tsk, tsk.
Speaking of lack of logic ... its the *REVERSE* that I am talking
about. Its because I *don't* have a 0 first-compile error rate that I
feel that my hidden error rate can't possibly be 0.
I'll say it a different way, perhaps this will get through.
REGARDLESS of what your first-compiler error rate, you should
feel that hidden error rate is non-zero. You /might/ convince
yourself otherwise at some point in the future, but using
first-compile errors as a metric in this way is the path to
hell.
You miss my argument. First-compile error rates are not a big deal --
the compiler catches them, you fix them. But they are indicative of
nature blind spots.
True. Unfortunately, if you had none at all, there are still
'unnatural blind spots' in code that will bite you in the
backside. This is why developers (outside of small shops)
rarely are solely responsible for testing their own code. They
get false impressions about what code is likely to be sound or
unsound based upon things like how many typos they made typing
it in. Not good.
Testing, structured walk throughs/inspections, are just imperfect
processes for trying to find hidden bugs. Sure they reduce them, but
you can't believe that they would get all of them -- they dont!
No kidding. I'm often amazed at how you give off the impression
that you think you are the sole possessor of what others
recognize as common knowledge.
I have never claimed that a program was bug free. I have
claimed that they have no known bugs, which is a different
matter completely.
When did I suggest or imply this?
Apparently not. Good.
[...] Not all development work is for use inside a VM or
other sandbox.
Again putting words in my mouth.
Stating a fact, actually.
When did I suggest that I was doing such a thing? Can you find the
relevant quote?
You didn't. I suggested it. Since it is more likely of
happening before 2020, it might be of interest to you in solving
the 'software crisis'.
