473,320 Members | 1,821 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Why doesn't strrstr() exist?

(Followups set to comp.std.c. Apologies if the crosspost is unwelcome.)

strchr() is to strrchr() as strstr() is to strrstr(), but strrstr()
isn't part of the standard. Why not?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 15 '05
149 24891

In article <3n***********@individual.net>, "Default User" <de***********@yahoo.com> writes:
Michael Wojcik wrote:

Tangentially, I might note that the reason I originally replied to
Christopher's post was that I feared he might believe that Brian's
opinion represented a consensus. It does not.
You have no idea whether it represents a consensus or not.


Yes I do (and it doesn't). It's been debated here and in other groups
many times, and it's clear to anyone reviewing those debates that no
consensus exists.
A "consensus" is not necessarily complete unanimity.


Thank you, but I am perfectly aware of that. Had I meant unanimity,
I would have written "unanimity".

--
Michael Wojcik mi************@microfocus.com

Unlikely prediction o' the day:
Eventually, every programmer will have to write a Java or distributed
object program.
-- Orfali and Harkey, _Client / Server Programming with Java and CORBA_
Nov 15 '05 #51
Chris Torek wrote:
[off-topic drift, but I cannot resist...]

In article <3n***********@individual.net>
Default User <de***********@yahoo.com> wrote:
You feel that I my choice of moniker reflects something about my
level of expertise? Note that "Default User" is NOT the default
name in XanaNews, my current newsreader.


I always figured it meant that you are known for requiring a
"default:" label in every switch(). :-)


Or that I just "use" a lot of them.

Brian
Nov 15 '05 #52
Joe Wright wrote:
Default User wrote:
You feel that I my choice of moniker reflects something about my
level of expertise? Note that "Default User" is NOT the default
name in XanaNews, my current newsreader.

Nonsense. Among the several header lines of your message are..
Is it?
From: "Default User" <de***********@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: Why doesn't strrstr() exist?
Date: 25 Aug 2005 18:11:29 GMT
Lines: 15
Message-ID: <3n***********@individual.net>
User-Agent: XanaNews/1.16.3.1


What do you think this says that contradicts my point? The heading
reflects the current settings of my newsreader. That doesn't mean they
were the base settings.

Brian
Nov 15 '05 #53
we******@gmail.com wrote:
Remember that almost every virus, buffer overflow exploit, core
dump/GPF/etc is basically due to some undefined situation in the ANSI C
standard.


That's misplaced blame. I use the same standard and don't have
such problems.
Nov 15 '05 #54
Antoine Leca wrote:
Paul Hsieh va escriure:
Remember that almost every virus, buffer overflow exploit, core
dump/GPF/etc is basically due to some undefined situation in the ANSI
C standard.
<OT>
The worst exploit I've seen so far was because a library dealing with
Unicode was not checking about malformed, overlong, UTF-8 sequences, and
allowed to walk though the filesystem, including in places where webusers
are not supposed to go. AFAIK, the library is written in C++ (it could
equally been written in C, that won't change the point.)
And the exploit was successful because some key directories had bad default
permissions as factory setup.


This is the worst? Are you sure silent zombification of your machine
isn't worse?

In any event, compare this to Java, where Unicode is actually the
standard encoding for string data. Its not really possible to have
"unicode parsing problems" in Java, since all this stuff has been
specified in the core of the language. Compare this to ANSI C, which
uses wchar, which literally doesn't *specify* anything useful. So
technically the only reason one is writing Unicode parsers in C is
because the standard doesn't give you one.
Another one quite successful was based on an brocken API for address books;
the API can be accessed from (not strictly conforming) C code, but that is
not how it is used usually. And the way the API is accessed though C
purposely avoid possible buffer overflows.

The most sticky virus I had to deal with was a bootsector virus. PC
bootsectors are not known to be written in C, rather in assembly language.
So you've been in a time machine and just recently joined us in the
next millenium? Bootsector viruses are so 80s. Boot to a dos disk and
type "fdisk /fixmbr" and usually you are set.
Granted, all these behaviours are _not_ defined by the ANSI C standard.
</OT>

Just because C is very much used will mean that statically it will show up
more often in exploit or core dumps or GPF cases.
Ok, so normalize the measures based on usages of the language. Do you
think C and C++ still won't be the worst by a country mile?
[...] This only shows it is a
successful language; there might be reasons for that; in fact, the ANSI C
Standard is a big reason for its prolongated life as a successful (= widely
used) language: I mean, had it not happen, C would probably be superceeded
nowadays (same for FIV then F77; or x86/PC.)


The ANSI *C89* standard is the reason for its long life, success. But
that ducks the point that it also is the fundamental source for these
problems, exploits, etc.

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

Nov 15 '05 #55
we******@gmail.com wrote:
Antoine Leca wrote:
Paul Hsieh va escriure:
Remember that almost every virus, buffer overflow exploit, core
dump/GPF/etc is basically due to some undefined situation in the
ANSI C standard.
<OT>
The worst exploit I've seen so far was because a library dealing
with Unicode was not checking about malformed, overlong, UTF-8
sequences, and allowed to walk though the filesystem


In any event, compare this to Java, where Unicode is actually the
standard encoding for string data.


Unicode is a character set, not an encoding.
Its not really possible to have "unicode parsing problems" in Java,
since all this stuff has been specified in the core of the language.


AFAIK the language doesn't specify how to deal with Unicode
characters whose value is greater than 65,535

Does it handle UTF-8, big-endian UCS-2, little-endian UCS-2,
b-e UTF16, l-e UTF16, and UCS-4 ? All of those occur in the
real world (unfortunately!)

Nov 15 '05 #56
Randy Howard wrote:
we******@gmail.com wrote:
For a nuclear reactor, I would also include the requirement that they
use a safer programming language like Ada.

The Ariane software module that caused the problem was written in Ada.
http://sunnyday.mit.edu/accidents/Ar...entreport.html
Had it been written in C, the actual cause (integer overflow) probably
would not have caused an exception. I'm not saying that it would have
been better in C, but you *cannot* blame the C standard for what happened
there.
You are right, I cannot blame C for bugs that happen in other
languages. This is the most famous one from Ada.


You just got done telling me that Ada would avoid problems.


It avoids buffer overflows, and other sorts of problems. Its not my
intention to defend Ada. Once again, I am not saying that either you
are with us or you are with the terrorists.

This was a point to demonstrate the programmers are not perfect, not
matter what you do. So this idea that you should just blame
programmers is just pointless.
See, the thing is, with Ada bugs, you can clearly blame the programmer
for most kinds of failures.


Oh my, SURELY the Ada standard should not allow such things to
happen. Those thoughtless bastards, how could this be? ;-)
Also, this "priority inversion" you speak of - doesn't that imply
processes or threads? C does not have that AFAIK. So you cannot blame the
C standard for allowing priority inversion bugs to occurr. It neither
allows or disallows them, because C has no notion of priorities.


The programmer used priority based threading because that's what he had
available to him.


He used something that does not even exist in standard C, and
got bit in the ass. Gee, and to think that you want to hold the
standard committee (and judging by another post of yours Ritchie
himself) responsible when people do things like this.


Well, Ritchie, AFAIK, did not push for the standardization, or
recommend that everyone actually use C as a real application
development language. So I blame him for the very narrow problem of
making a language with lots of silly unnecessary problems, but not for
the fact that everyone decided to use it. The actual ANSI C committee
is different -- they knew exactly what role C was taking. They have
the ability to fix the warts in the language.
[...] Wow. Let's read on and see what sort of hole you choose to dig...
Or what words you will put in my mouth, or what false dichotomies you
will draw ...
Suppose, however, that C had implemented co-routines


Suppose that you hadn't blamed standard C for something not
written in standard C. That one had a much higher chance of
being true until just recently.
Maybe the Pathfinder code would have more
coroutines, and fewer threads, and may have avoided the problem
altogether (I am not privy to their source, so I really don't know).


That didn't stop you from blaming it on standard C, why stop
now?


First of all, the standard doesn't *have* coroutines while other
languages do. And I never *did* blame the pathfinder bug on the C
standard. I see you have the CBFalconer disease of reading whatever
the hell you want from text that simply doesn't contain the content you
think it does.
Coroutines are one of those "perfect compromises", because you can
easily specify a portable interface, that is very likely to be widely
supportable, they are actually tremendously faster than threading in
many cases, and all without adding *any* undefined behavior or
implementation defined behavior scenarios (other than a potential
inability to allocate new stacks.)


How strange that they are so wildly popular, whereas threads are
never used. *cough*


Coroutines are not very widely *deployed*. So popularity is how you
judge the power and utility of a programming mechanism? Why don't you
try to add something substantive here rather leading with ignorance?
Can you give a serious pro-con argument for full threads versus
coroutines? Because I can.
Full blown multithreading, such as
in POSIX is notoriously platform specific, and it should not surprise
anyone that only few non-UNIX platforms support full blown POSIX
threads.


That's interesting, because I have used the pthreads interfaces
for code on Windows (pthreads-win32), Linux, OS X, solaris, and
even Novell NetWare (libc, since they started supporting them
several years ago).


You undertstand that those are all mostly UNIX right? Even the windows
thing is really an implementation or emulation of pthreads on top of
Windows multithreading. Show me pthreads in an RTOS.
[...] I didn't realize they didn't work, because
for some strange reason, they do work for me. Maybe I'm just
lucky, or maybe you're too fond of spouting off about things you
have 'heard' but don't actually know to be true.

Have there been bugs in pthread libraries? Yes. Have their
been bugs in almost every library ever used in software
development? Yes. Where they impossible to fix? No.


Right. And have they fixed the generic problem of race conditions?
Race conditions are just the multitasking equivalent of
buffer-overflows. Except, as you know, they are *much* harder to
debug, and you cannot use tools, compiler warnings or other simple
mechanisms to help you avoid them. This is the real benefit of
coroutines over full threading. You can't have race conditions using
coroutines.
This fact has been noticed and adopted by those languages
where serious development is happening (Lua, Perl, Python). I don't
know if the C standards committee would be open to this -- I highly
doubt it.


Feel free to propose a complete coroutine implementation.


I would if I thought there was an audience for it. These things take
effort, and a brief perusal of comp.std.c leads me to believe that the
ANSI committee is extremely capricious.

Think about it. You want me to propose something actually useful,
powerful and which would improve the language to a committee that
continues to rubber stamp gets().

Is your real point that I am supposed to do this to waste my time and
energy, obviously get rejected because the ANSI C committee has no
interested in improving the language, and this will be proof that I am
wrong?

Tell me, when is the last time the C language committee considered a
change in the language that made it truly more powerful that wasn't
already implemented in many compilers as extensions? Can you give me
at least a plausibility argument that I wouldn't be wasting my time by
doing such a thing?

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

Nov 15 '05 #57
Chris Torek wrote:
(Again, quite off-topic, but ...)

[Ariane rocket example]

In article <11**********************@g47g2000cwa.googlegroups .com>
<we******@gmail.com> wrote:
You are right, I cannot blame C for bugs that happen in other
languages. This is the most famous one from Ada. ...
See, the thing is, with Ada bugs, you can clearly blame the programmer
for most kinds of failures.
I am reminded of a line from a novel and movie:

"*We* fix the blame. *They* fix the problem. Their way's better."


So in this case, how do we "fix" the problem of buffer overflows in C
programs? Shall we teach every bad programmer how not to do it, and
zap them if they get it wrong (a la Randy Howard style)? Or do you
perform some C library modifications so that the problem is
substantially mitigated?
[Pathfinder example]
The programmer used priority based threading because that's what he had
available to him.
Actually, the Pathfinder used vxWorks, a system with which I am
now somewhat familiar. (Not that I know much about versions
predating 6.0, but this particular item has been this way "forever",
or long enough anyway.)

The vxWorks system offers "mutex semaphores" as one of its several
flavors of data-protection between threads. The mutex creation
call, semMCreate(), takes several flag parameters. One of these
flags controls "task" (thread, process, whatever moniker you prefer)
priority behavior when the task blocks on the mutex.

The programmer *chose* this behavior, because vxWorks does offer
priority inheritance. (Admittedly, vxWorks priority inheritance
has a flaw, but that is a different problem.)

Thus, your premise -- that the programmer used priority based
scheduling (without inheritance) that led to the priority inversion
problem "because that's what he had available" is incorrect: he
could have chosen to make all the threads the same priority, and/or
used priority inheritance, all with simple parameters to the various
calls (taskSpawn(), semMCreate(), and so on).


I'm confused as to how you know that programmer who made the mistake
was in charge of what priority his task ran at. And in any event I
don't claim its the programmer (or designer, or whoever's fault it
really was's) *only* choice. Its just an example of a land mine being
there, and it being stepped on.

The reality is that VxWork "solves" this problem and others by having a
very sophisticated built-in debugging environment. They just had to
look at the task list and see that the high priority task was blocked.
Coroutines are one of those "perfect compromises" ...


Coroutines are hardly perfect.


You, of course, missed the word that I typed immediately following the
word perfect.
[...] However, if you like them, I suggest you investigate the Icon
programming language, for instance.


I looked briefly at it. The impression I had is that it supported too
many modes of coroutines which made them unnecessarily complicated to
use (I may be thinking of another language.)

In any event, I have *studied* coroutines in university, and can
revisit them in far more mainstream languages like Python and Lua. My
understanding of them is not the point (I think I do -- or at least the
"one shot continuation" kind) my point is they should probably be part
of the C standard.

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

Nov 15 '05 #58
In article <11**********************@g47g2000cwa.googlegroups .com>,
we******@gmail.com writes
Randy Howard wrote:
we******@gmail.com wrote:
He used something that does not even exist in standard C, and
got bit in the ass. Gee, and to think that you want to hold the
standard committee (and judging by another post of yours Ritchie
himself) responsible when people do things like this.


Well, Ritchie, AFAIK, did not push for the standardization, or
recommend that everyone actually use C as a real application
development language. So I blame him for the very narrow problem of
making a language with lots of silly unnecessary problems, but not for
the fact that everyone decided to use it. The actual ANSI C committee
is different -- they knew exactly what role C was taking. They have
the ability to fix the warts in the language.
Feel free to propose a complete coroutine implementation.


I would if I thought there was an audience for it. These things take
effort, and a brief perusal of comp.std.c leads me to believe that the
ANSI committee is extremely capricious.


It's NOT down to the ANSI committee..... it is down to WG14 an ISO
committee of which ANSI is but one part. Since 1990 C has been handles
by ISO as an international standard. There are committees from many
countries involved. ANSI gets one vote like all the rest so don't blam
ANSI for all of it.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Nov 15 '05 #59
Old Wolf wrote:
we******@gmail.com wrote:
Antoine Leca wrote:
Paul Hsieh va escriure:
Remember that almost every virus, buffer overflow exploit, core
dump/GPF/etc is basically due to some undefined situation in the
ANSI C standard.

<OT>
The worst exploit I've seen so far was because a library dealing
with Unicode was not checking about malformed, overlong, UTF-8
sequences, and allowed to walk though the filesystem
In any event, compare this to Java, where Unicode is actually the
standard encoding for string data.


Unicode is a character set, not an encoding.


Right. It turns out that UTF-16 is the encoding (I don't know whether
or not its LE or BE, but I suspect, its not an exposed thing from the
representation point of view -- i.e., it just matches whatever works
best for your platform.)
Its not really possible to have "unicode parsing problems" in Java,
since all this stuff has been specified in the core of the language.


AFAIK the language doesn't specify how to deal with Unicode
characters whose value is greater than 65,535


Not so. It specifies UTF-16, which can represent the whole range.
Does it handle UTF-8, big-endian UCS-2, little-endian UCS-2,
b-e UTF16, l-e UTF16, and UCS-4 ? All of those occur in the
real world (unfortunately!)


I am not *that* familliar with Java. But I wouldn't be surprised if
Java didn't come with utilities to support all of those. UCS-2 are
just subsets of UTF16, and UCS-4 is trivial. The only real question is
UTF-8 support, which I don't know about.

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

Nov 15 '05 #60
we******@gmail.com wrote:
Randy Howard wrote:
we******@gmail.com wrote: ....
Coroutines are one of those "perfect compromises", because you can
easily specify a portable interface, that is very likely to be widely
supportable, they are actually tremendously faster than threading in
many cases, and all without adding *any* undefined behavior or
implementation defined behavior scenarios (other than a potential
inability to allocate new stacks.)
How strange that they are so wildly popular, whereas threads are
never used. *cough*


Coroutines are not very widely *deployed*. So popularity is how you
judge the power and utility of a programming mechanism?


Powerful and useful programming mechanisms tend to become popular. If
they've been around for a reasonable length of time without becoming
popular, if they're not yet widely deployed, then it's reasonable to
guess that this might be because they're not as powerful or as useful
as you think they are, or that they might have disadvantages that are
more than sufficient to compensate for those advantages. The
implication of his comment is that he's not merely guessing; he knows
reasons that he considers sufficient to justify their lack of
popularity.

....
That's interesting, because I have used the pthreads interfaces
for code on Windows (pthreads-win32), Linux, OS X, solaris, and
even Novell NetWare (libc, since they started supporting them
several years ago).


You undertstand that those are all mostly UNIX right?


No, Windows conforms to POSIX (though from what I've heard, it doesn't
conform very well; I'm happy to say I know nothing about the details),
but that doesn't make it UNIX.
Tell me, when is the last time the C language committee considered a
change in the language that made it truly more powerful that wasn't
already implemented in many compilers as extensions? Can you give me
at least a plausibility argument that I wouldn't be wasting my time by
doing such a thing?


You've answered your own question: the single best way to get something
standardized is to convince someone to implement it as an extension,
develop experience actually using it, show people that it's useful, and
have it become so popular that the committee has no choice but to
standardize it. Why should the committee waste it's very limited amount
of time standardizing something that isn't a sufficiently good idea to
have already become a widely popular extension? If something good is so
new that it hasn't become popular yet, it's too early to standardize
it. Standardizing something freezes it; the need to maintain backwards
compatibility means that it's almost impossible to make substantive
changes to something once it's been standardized. Nothing should be
standardized until people have gained enough experience with it that it
seems unlikely that it will ever again need significant modification.

And, before you bring it up: yes, the committee has occasionally
ignored this advice; however, the results of doing so have often been
regrettable.

Nov 15 '05 #61
we******@gmail.com wrote:
Randy Howard wrote:
we******@gmail.com wrote:
Randy Howard wrote: ....
"False dichotomy". Look it up. I never mentioned high or low level
language, and don't consider it relevant to the discussion. Its a
false dichotomoy because you immediately dismiss the possibility of a
safe low-level language.
No, it's not an immediate dimissal. It's also not a dichotomy:
low-level languages are inherently unsafe, but high-level languages are
not inherently safe. If it's low-level, by definition it gives you
access to unprotected access to dangerous features of the machine
you're writing for. If it protected your access to those features, that
protection (regardless of what form it takes) would make it a
high-level language.

.... 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.
Yes, you can access things more directly in C than in other higher
level languages. That's what makes them higher-level languages. One of
the most dangerous features of C is that it has pointers, which is a
concept only one layer of abstraction removed from the concept of
machine addresses. Most of the "safer" high level languages provide
little or no access to machine addresses; that's part of what makes
them safer.
I am dodging the false dichotomy. Yes. You are suggesting that making
C safer is equivalent to removing buffer overflows from assembly. The
two have nothing to do with each other.
You can't remove buffer overflows from C without moving it at least a
little bit farther away from assembly, for precisely the same reason
why you can't remove buffer overflows from assembly without making it
less of an assembly language.
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.
> [...] If you want to argue that too many people
> write code in C when their skill level is more appropriate to a
> language with more seatbelts, I won't disagree. The trick is
> deciding who gets to make the rules.

But I'm not arguing that either. I am saying C is to a large degree
just capriciously and unnecessarily unsafe (and slow, and powerless,
and unportable etc., etc).
Slow? Yes, I keep forgetting how much better performance one
achieves when using Ruby or Python. Yeah, right.


I never put those languages up as alternatives for speed. The false
dichotomy yet again.


A more useful response would have been to identify these
safer-and-specdier-than-C languages that you're referring to.
Unportable? You have got to be kidding. I must be
hallucinating when I see my C source compiled and executing on
Windows, Linux, NetWare, OS X, Solaris, *bsd, and a host of
other UNIX-like platforms, on x86, x86-64, PPC, Sparc, etc.


Right. Because you write every piece of C code that's ever been
written right?


His comment says nothing to suggest that he's ported any specific
number of programs to those platforms. It could be a single program, it
could be a million. Why are you interpreting his claim suggesting that
ported many different programs to those platforms?
I don't think you understood me. I know of no company that has
a policy for this. However, if I was working on something and
felt that something was being done that could be inherently
dangerous, and it was going to ship anyway, I would take some
form of legal action, if for no other reason than to be able to
disassociate myself from the impending lawsuits.


Ok ... that's interesting, but this is ridiculuous. As I said above,
you do not write every piece of software in the world. And we are well
aware of about 10,000 programmers living in the pacific northwest who
we know do *NOT* share your attitude.


Well, that's their fault, and their liability. That doesn't make the
attitude wrong.
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.
No, they should be willing to quit if deliberately ordered to ship
seriously defective products. There's a huge middle ground between
"seriously defective" and "highest possible quality". In that huge
middle ground, they should argue and strive for better quality, but not
necessarily threaten to quit over it.
I would much rather go look for work than participate in
something that might wind up with people dying over the actions
of some meddling manager.


That's nice for you. That's not going to be a choice for lots of other
people.


That's a choice every employed person has. If they choose not to take
it, that's their fault - literally, in the sense that they can and
should be held personally liable for the deaths caused by their
defective choice.

.... Hmmm ... so you live in India?


Why would you think so?


Wild guess.


Why are you making wild guesses? Why are you making guesses that have
no discernable connection to the topic on hand?
.... 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.


Yes, people should be held responsibile for things they're actually
responsible for. Ritchie isn't responsible for mis-use of the things
he's created.

Nov 15 '05 #62
we******@gmail.com wrote
(in article
<11**********************@g44g2000cwa.googlegroups .com>):
Why does being a low language mean you have to present a programming
interface surrounded by landmines?
If you have access to any sequence of opcodes available on the
target processor, how can it not be?


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.
Exposing a sufficiently low level
interface may require that you expose some danergous semantics, but why
expose them up front right in the most natural paths of usage?


Do you feel that 'gets()' is part of the most natural path in C?


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.
But its interesting that you bring up the questions of assembly
language. If you persuse the x86 assembly USENET newsgroups, you will
see that many people are very interested in expanding the power and
syntax for assembly language (examples include HLA, RosAsm, and
others).


For a suitably generous definition of 'many', perhaps.


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.
I would have been shocked if you had not figured out a way to
bring your package up. :-)


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.
Which does absolutely nothing to prevent the possibility of
developing insecure software in assembler. It may offer some
advantages for string handling, but that closes at best only one
of a thousand doors.


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.
But I'm not arguing that either. I am saying C is to a large degree
just capriciously and unnecessarily unsafe (and slow, and powerless,
and unportable etc., etc).


Slow? Yes, I keep forgetting how much better performance one
achieves when using Ruby or Python. Yeah, right.


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.
Powerless? How so?


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?
Unportable? You have got to be kidding. I must be
hallucinating when I see my C source compiled and executing on
Windows, Linux, NetWare, OS X, Solaris, *bsd, and a host of
other UNIX-like platforms, on x86, x86-64, PPC, Sparc, etc.


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.
That is all true, and it does nothing to address the point that
C is still going to be used for a lot of development work. The
cost of the runtime error handling is nonzero. Sure, there are
a lot of applications today where they do not need the raw speed
and can afford to use something else. That is not always the
case. People are still writing a lot of inline assembly even
when approaching 4GHz clock speeds.


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'.
Just take the C standard, deprecate the garbage, replace
a few things, genericize some of the APIs, well define some of the
scenarios which are currently described as undefined, make some of the
ambiguous syntaxes that lead to undefined behavior illegal, and you're
immediately there.


I don't immediately see how this will be demonstrably faster,
but you are free to invent such a language tomorrow afternoon.


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.
Do it, back up your claims, and no doubt the world will beat a
path to your website. Right?


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. :-)
Your problem is that you assume making C safer (or faster, or more
portable, or whatever) will take something useful away from C that it
currently has. Think about that for a minute. How is possible that
your mind can be in that state?


It isn't possible. What is possible is for you to make gross
assumptions about what 'my problem' is based up the post you are
replying to here. I do not assume that C can not be made safer.
What I said, since you seem to have missed it, is that the
authors of the C standard are not responsible for programmer
bugs.


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.
What cost? Some 'world-wide rolled-up cost'? For me, it cost
me almost nothing at all. I first discovered gets() was
problematic at least a decade ago, probably even earlier, but I
don't keep notes on such things. It hasn't cost me anything
since.


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.
The standards body, just needs to remove it and those costs go away.


They do not. As we have already seen, it takes years, if not
decades for a compiler supporting a standard to land in
programmer hands. With the stunningly poor adoption of C99, we
could not possibly hope to own or obtain an open source C0x
compiler prior to 2020-something, if ever. In the mean time,
those that are serious solved the problem years ago.


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.
Great idea. 15 years from now that will have some value.


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.
A better idea. Patch gcc to bitch about them TODAY, regardless
of the standard.


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.
Interesting -- because I do. You make gets a reserved word, not
redefinable by the preprocessor, and have it always lead to a syntax
error.


What part of 'people can still fire up and old compiler' did you
fail to read and/or understand?


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.
This has value because, developers can claim to be "C 2010 compliant"
or whatever, and this can tell you that you know it doesn't have gets()
or any other wart that you decided to get rid of.


They could also simply claim "we are smarter than the average
bear, and we know better to use any of the following offensive
legacy functions, such as gets(), ..."


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...
To clarify, since it didn't soak in the first time, I am not
opposed to them being removed. I simply don't this as a magic
bullet, and certainly not in the sense that it takes far too
long for the compilers to catch up with it. I would much rather
see compilers modified to deny gets() and its ilk by default,
and require a special command line option to bypass it, /if at
all/. However, the warning message should be far more useful
than
gets.c: 325: error: gets() has been deprecated.


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.
If, and only if, they use a compiler with such changes. We
still see posts on a regular basis with people using old 16-bit
Borland compilers to write new software.


... 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.
Oh I see. So, which socialist totally unionized company do you work as
a programmer for? I'd like to apply!


I don't think you understood me. I know of no company that has
a policy for this. However, if I was working on something and
felt that something was being done that could be inherently
dangerous, and it was going to ship anyway, I would take some
form of legal action, if for no other reason than to be able to
disassociate myself from the impending lawsuits.


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..."
Hmmm ... so you live in India?


Why would you think so?


Wild guess.


Very.
I'm trying to guess where it is in this
day and age that you can just quit your job solely because you don't
like the pressures coming from management.


Where do you live? Because I am trying to guess where on the
planet you would /not/ have the right to quit your job.
Indentured servitude is not widely practiced anymore, AFAIK.


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.
You can have 10 dozen other forms of security failure, that have
nothing to do with buffer overflows.


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 had done just about everything I could imagine to lock the
system down, and it still got out of control in 2 hours letting
a 12-yr-old browse a website and play some games.

Of course, if enough people do the same thing, the bad guys will
figure out how to do this on Linux boxes as well. But for now,
the OS X and Linux systems have been causing me (and the kids)
zero pain and I'm loving it.


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.
> Programmers are generally not aware of the liability of
> their mistakes.

Then those you refer to must be generally incompetent.

Dennis Ritchie had no idea that NASA would put a priority inversion in
their pathfinder code.


Are you implying that Dennis Ritchie is responsible for some bad
code in the pathfinder project?


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.
My point is
that programmers don't know what the liability of their code is,
because they are not always in control of when or where or for what it
might be used.


Wow, that is tortured at best. Presumably Ritchie is in your
list because of C or UNIX? How could he be 'liable' for an
application or driver written by somebody else 30 years later?


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.
Are the contributors to gcc responsible for every bad piece of
software compiled with it?


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. :-(
If someone writes a denial-of-service attack program that sits
on a Linux host, is that Torvald's fault? I've heard of people
trying to shift blame before, but not that far. Maybe you might
want to blame Linus' parents too, since if they hadn't conceived
him, Linux wouldn't be around for evil programmers to write code
upon. Furrfu.


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.
The recent JPEG parsing buffer overflow exploit, for example, came from
failed sample code from the JPEG website itself. You think we should
hunt down Tom Lane and linch him?


Nope. If you take sample code and don't investigate it fully
before putting it into production use, that's /your/ problem.


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.
Just measuring first time compile error rates, myself, I score roughly
one syntax error per 300 lines of code. I take this as an indicator
for the likely number of hidden bugs I just don't know about in my
code. Unless my first-compile error rate was 0, I just can't have any
confidence that I don't also have a 0 hidden bug rate.


Strange logic, or lack thereof. Having no first-compile errors
doesn't provide ANY confidence that you don't have hidden bugs.


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.
Do you really think you can do anything to a language that
allows you to touch hardware that will prevent people from
misusing it?


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.
It would probably be a better idea for you to finish your
completely new "better C compiler" (keeping to your string
library naming) and make it so popular that C withers on the
vine.


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

--
Randy Howard (2reply remove FOOBAR)

Nov 15 '05 #63
Chris Hills wrote:
It's NOT down to the ANSI committee..... it is down to WG14 an ISO
committee of which ANSI is but one part. ...


It's already evident that "websnarf" doesn't understand
standardization.
Nov 15 '05 #64
we******@gmail.com wrote:
In any event, compare this to Java, where Unicode is actually the
standard encoding for string data. Its not really possible to have
"unicode parsing problems" in Java, since all this stuff has been
specified in the core of the language. Compare this to ANSI C, which
uses wchar, which literally doesn't *specify* anything useful. So
technically the only reason one is writing Unicode parsers in C is
because the standard doesn't give you one.


C is *meant* for implementing systems at that level, and doesn't
presuppose such things as the specific native character encoding.
People who have to deal with a variety of encodings would have to
do similar things in Java too.
Nov 15 '05 #65
we******@gmail.com wrote
(in article
<11**********************@g47g2000cwa.googlegroups .com>):
This was a point to demonstrate the programmers are not perfect, not
matter what you do. So this idea that you should just blame
programmers is just pointless.
It's better than blaming someone that doesn't even have access
to the source code in most cases. If I saw a car wreck, I
wouldn't immediately go in search of the CEO of the company that
built the car. I'd first try to find out about the driver. It
might turn out that the car was fundamentally flawed, and
impossible to drive correctly.

You could easily make the argument that gets() is impossible, or
nearly so, to use properly. That doesn't preclude you from
getting input in other ways.
The programmer used priority based threading because that's what he had
available to him.


He used something that does not even exist in standard C, and
got bit in the ass. Gee, and to think that you want to hold the
standard committee (and judging by another post of yours Ritchie
himself) responsible when people do things like this.


Well, Ritchie, AFAIK, did not push for the standardization, or
recommend that everyone actually use C as a real application
development language. So I blame him for the very narrow problem of
making a language with lots of silly unnecessary problems, but not for
the fact that everyone decided to use it.


I have yet to encounter a language without a lot of silly
problems. Some folks argue that lisp is such a language, but I
don't take them seriously. :-)
The actual ANSI C committee
is different -- they knew exactly what role C was taking. They have
the ability to fix the warts in the language.
No, they have the ability to recommend fixes to a language, but
as we have already seen, the developer community is more than
willing to ignore them when push comes to shove. A community
that strong-willed should be strong enough to address the gets()
problem itself, and not rely on 'permission' from the standard
group.
Maybe the Pathfinder code would have more
coroutines, and fewer threads, and may have avoided the problem
altogether (I am not privy to their source, so I really don't know).


That didn't stop you from blaming it on standard C, why stop
now?


First of all, the standard doesn't *have* coroutines while other
languages do.


It doesn't have threads either. If you want to argue about
pthreads, take it up with the POSIX guys. I suspect Butenhof
and a few others would just love to argue you with you about it
over in c.p.t.
How strange that they are so wildly popular, whereas threads are
never used. *cough*


Coroutines are not very widely *deployed*.


Correct.
So popularity is how you
judge the power and utility of a programming mechanism?
No, but it has a lot to do with whether or not programmers see
it as a suitable alternative at design time.
Why don't you
try to add something substantive here rather leading with ignorance?
Why don't you stop playing games? It's readily apparent that
programming isn't knew to either of us, so let's stop fencing
with ad homs and move on.
Can you give a serious pro-con argument for full threads versus
coroutines? Because I can.
Yes. There is a POSIX standard for pthreads. This allows me to
develop cross-platform, portable software that utilizes them
across a diverse group of OS platforms and CPU architectures for
tools that, for a number of reasons, must be written in C, or
assembler, which isn't all that practical since different CPU
architectures are involved, and the amount of work involved
would be staggering. There is no coroutine solution available
AFAIK to solve the problem across all of the platforms, and I do
not have the luxury of discussing vaporware.

If there was coroutine support in a suitable language, and if it
was readily available on a wide variety of OS and hardware, I
would consider it, especially if it offered parity or
improvement over threads in terms of performance, flexibility
and stability. I have not spent much time on them, apart from
the theoretical, because they do not form a practical solution
to the problems I have to address today.

Ironically, I can say similar things about the Windows threading
model, which does exist, but only solves a fraction of the
problem, and in a much more tortured way.
That's interesting, because I have used the pthreads interfaces
for code on Windows (pthreads-win32), Linux, OS X, solaris, and
even Novell NetWare (libc, since they started supporting them
several years ago).


You undertstand that those are all mostly UNIX right? Even the windows
thing is really an implementation or emulation of pthreads on top of
Windows multithreading.


Wow. I didn't know that. I thought that the reason I
downloaded pthreads-win32 was simply because Microsoft forgot to
put it on the CD and had mistakenly left it on somebody else's
website. *sigh*
Show me pthreads in an RTOS.
Read Bill Weinberg's (MontaVists) paper for an alternate view.
http://www.mvista.com/dswp/wp_rtos_to_linux.pdf
Have there been bugs in pthread libraries? Yes. Have their
been bugs in almost every library ever used in software
development? Yes. Where they impossible to fix? No.


Right. And have they fixed the generic problem of race conditions?


No, you have to code to avoid them, just as you do to avoid
logic flaws.
Race conditions are just the multitasking equivalent of
buffer-overflows.
Hardly.
Except, as you know, they are *much* harder to debug,
And to exploit. Buffer overflows are comparably easy to
exploit. The best way to 'debug' races is to avoid them in the
first place.
and you cannot use tools, compiler warnings or other simple
mechanisms to help you avoid them.
You can use the knowledge of how to avoid them to good effect
however. I have not had to chase one down for quite a while,
and will be mildly surprised if one pops up down the road.
This is the real benefit of coroutines over full threading.
You can't have race conditions using coroutines.
Unfortunately, you can't have coroutines using a number of
popular languages either.

And you can have race conditions, even without threads. Two
separate processes doing I/O to the same file can race, with or
without coroutines in either or both. Race conditions are not
something threads hold a patent on, not by a long shot.
Feel free to propose a complete coroutine implementation.


I would if I thought there was an audience for it. These things take
effort, and a brief perusal of comp.std.c leads me to believe that the
ANSI committee is extremely capricious.


Then skip them, and sell it instead. People use things (such as
pthreads) that aren't part of standard C every day, with varying
degrees of success. If you had a package, and it did not
subscribe to the 'all the world's an intel' philosophy, I would
entertain the notion. Not all of us have the luxury of
supporting a single, or even a few platforms. The choices are
limited, or you roll your own.
Think about it. You want me to propose something actually useful,
powerful and which would improve the language to a committee that
continues to rubber stamp gets().
Yeah. And if nobody tries, it is a self-fulfilling prophecy
that it won't change.
Is your real point that I am supposed to do this to waste my time and
energy, obviously get rejected because the ANSI C committee has no
interested in improving the language, and this will be proof that I am
wrong?
No. I think that if you are correct in believing it has value
and the world needs it, then you propose it for standardization,
and while you wait, you build it anyway, because if it's that
good, then people will want to buy it if they can't get it
another way. Even it if it is accepted, you can still sell it,
look at the folks selling C99 solutions and libraries today,
despite of the lack of general availability.

You can sit around being mad at the world over your pet peeves,
or you can do something about it. Of course, the former is far
easier.
Tell me, when is the last time the C language committee considered a
change in the language that made it truly more powerful that wasn't
already implemented in many compilers as extensions?
I can't think of an example offhand, but I am restricted by not
being completely fluent on all the various compiler extensions,
as I try to avoid them whenever possible. Even so, you have a
point about their past history.
Can you give me at least a plausibility argument that I wouldn't
be wasting my time by doing such a thing?


If you don't think it's worth fooling with, then why are we
arguing about it at all? either it is a 'software crisis', or
it is, to use a coarse expression, 'just a fart in the wind'.
If it is the latter, let's stop wasting time on it.

--
Randy Howard (2reply remove FOOBAR)

Nov 15 '05 #66
Randy Howard <ra*********@FOOverizonBAR.net> wrote:
we******@gmail.com wrote
(in article
<11**********************@g44g2000cwa.googlegroups .com>):
Why does being a low language mean you have to present a programming
interface surrounded by landmines?

If you have access to any sequence of opcodes available on the
target processor, how can it not be?


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.


Neither does C.

Richard
Nov 15 '05 #67
ku****@wizard.net wrote
(in article
<11**********************@g44g2000cwa.googlegroups .com>):
we******@gmail.com wrote:
Randy Howard wrote:
we******@gmail.com wrote:
Randy Howard wrote: ...
"False dichotomy". Look it up. I never mentioned high or low level
language, and don't consider it relevant to the discussion. Its a
false dichotomoy because you immediately dismiss the possibility of a
safe low-level language.
No, it's not an immediate dimissal. It's also not a dichotomy:
low-level languages are inherently unsafe, but high-level languages are
not inherently safe. If it's low-level, by definition it gives you
access to unprotected access to dangerous features of the machine
you're writing for. If it protected your access to those features, that
protection (regardless of what form it takes) would make it a
high-level language.


I'm glad that is obvious to someone else. I was feeling lonely.
:-)
You can't remove buffer overflows from C without moving it at least a
little bit farther away from assembly, for precisely the same reason
why you can't remove buffer overflows from assembly without making it
less of an assembly language.


Yes. We could just as easily have had "C without Pointers"
instead of "C with classes". Guess how many people would have
went for the first of the two? We can argue about the benefits
or lack thererof with the second some other time. :-)
Slow? Yes, I keep forgetting how much better performance one
achieves when using Ruby or Python. Yeah, right.


I never put those languages up as alternatives for speed. The false
dichotomy yet again.


A more useful response would have been to identify these
safer-and-specdier-than-C languages that you're referring to.


Exactly. It would have been far more difficult to do though,
and he already has 'false dichotomy' in his paste buffer.
Unportable? You have got to be kidding. I must be
hallucinating when I see my C source compiled and executing on
Windows, Linux, NetWare, OS X, Solaris, *bsd, and a host of
other UNIX-like platforms, on x86, x86-64, PPC, Sparc, etc.


Right. Because you write every piece of C code that's ever been
written right?


His comment says nothing to suggest that he's ported any specific
number of programs to those platforms. It could be a single program, it
could be a million. Why are you interpreting his claim suggesting that
ported many different programs to those platforms?


Intentional misreading, I suspect.
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.


No, they should be willing to quit if deliberately ordered to ship
seriously defective products. There's a huge middle ground between
"seriously defective" and "highest possible quality". In that huge
middle ground, they should argue and strive for better quality, but not
necessarily threaten to quit over it.


Eerily, we had almost exactly the same response to this bit.
Once again, there is hope. :-)
I would much rather go look for work than participate in
something that might wind up with people dying over the actions
of some meddling manager.


That's nice for you. That's not going to be a choice for lots of other
people.


That's a choice every employed person has. If they choose not to take
it, that's their fault - literally, in the sense that they can and
should be held personally liable for the deaths caused by their
defective choice.


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


Yes, people should be held responsibile for things they're actually
responsible for. Ritchie isn't responsible for mis-use of the things
he's created.


He's probably in favor of suing Stihl is someone uses one of
their chainsaws to decapitate their spouse too. After all, it's
the same false premise at work.
--
Randy Howard (2reply remove FOOBAR)

Nov 15 '05 #68
Richard Bos wrote
(in article <43***************@news.xs4all.nl>):
Randy Howard <ra*********@FOOverizonBAR.net> wrote:
we******@gmail.com wrote
(in article
<11**********************@g44g2000cwa.googlegroups .com>):
> Why does being a low language mean you have to present a programming
> interface surrounded by landmines?

If you have access to any sequence of opcodes available on the
target processor, how can it not be?

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.


Neither does C.


Ref: J.5.10 Yes, I know about where it appears in the
document, but it's close enough given we are discussing the real
world. Since one can also link assembly code modules with C
into an executable without it, it seems a moot point anyway.

--
Randy Howard (2reply remove FOOBAR)

Nov 15 '05 #69
On Tue, 30 Aug 2005 15:52:05 GMT, Randy Howard
<ra*********@FOOverizonBAR.net> wrote:
we******@gmail.com wrote
(in article
<11**********************@g47g2000cwa.googlegroup s.com>):
This was a point to demonstrate the programmers are not perfect, not
matter what you do. So this idea that you should just blame
programmers is just pointless.


It's better than blaming someone that doesn't even have access
to the source code in most cases. If I saw a car wreck, I
wouldn't immediately go in search of the CEO of the company that
built the car. I'd first try to find out about the driver. It
might turn out that the car was fundamentally flawed, and


Can't you guys find a more suitable venue for your argument?

How about comp.programming?
--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 15 '05 #70
we******@gmail.com writes:
Randy Howard wrote:
we******@gmail.com wrote:
> Randy Howard wrote:
>>> Bad programming + good programming language does not allow for buffer
>>> overflow exploits.
>>
>> For suitably high-level languages that might be true (and
>> provable). Let us not forget that C is *not* a high-level
>> language. It's not an accident that it is called high-level
>> assembler.
>
> Right. If you're not with us, you are with the terrorists.


Excuse me?


"False dichotomy". Look it up. I never mentioned high or low level
language, and don't consider it relevant to the discussion. Its a
false dichotomoy because you immediately dismiss the possibility of a
safe low-level language.


"websnarf", let me offer a suggestion. If you want to point out a
false dichotomy, use the words "false dichotomy". I had no clue what
you meant by your remark about terrorists, and I'd be surprised if
anyone else did either. (I didn't mention it earlier because,
frankly, I didn't care what you meant.)

If you want to communicate, you need to write more clearly. If you're
more interested in showing of how obscure you can be, please do so
somewhere else.

--
Keith Thompson (The_Other_Keith) 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.
Nov 15 '05 #71
Randy Howard wrote:
.. A community
that strong-willed should be strong enough to address the gets()
problem itself, and not rely on 'permission' from the standard
group.


Actually all you need to do is not use gets (except
perhaps in certain carefully controlled situations).
There are other, standard, mechanisms that can be used
safely enough. If the actual problem is perceived to
be that naive novice programmers might use gets
without appreciating the opportunity for buffer
overrun, consider that the same programmers will make
comparable errors throughout their code. A genuine
fix for the actual problem requires something quite
different from removing gets from the system library.
Nov 15 '05 #72
Alan Balmer wrote
(in article <0c********************************@4ax.com>):
Can't you guys find a more suitable venue for your argument?


I'm sorry. Is a discussion about what might or might not happen
in future C standards drowning out discussions of homework
problems and topicality?

--
Randy Howard (2reply remove FOOBAR)

Nov 15 '05 #73
Douglas A. Gwyn wrote
(in article <43***************@null.net>):
Randy Howard wrote:
.. A community
that strong-willed should be strong enough to address the gets()
problem itself, and not rely on 'permission' from the standard
group.
Actually all you need to do is not use gets (except
perhaps in certain carefully controlled situations).
There are other, standard, mechanisms that can be used
safely enough.


Indeed, if I am not mistaken I made that very point several
times already. Apparently it lacks for an iron-clad guarantee.
If the actual problem is perceived to be that naive novice
programmers might use gets without appreciating the opportunity
for buffer overrun, consider that the same programmers will make
comparable errors throughout their code.
Yes. Also, it is incredibly unlikely that a naive novice
programmer will be producing software that will be widely
deployed and wind up in a CERT advisory, but I suppose it is not
impossible.

I am somewhat curious about why even as late as C99, or even
later in TC1, there is still no official wording in the standard
concerning gets() being of any concern at all. It seems that it
couldn't have offended many people to simply saying "hey, this
is in the standard already, but it's really not a good idea to
use it for new development, and in fact, it is highly
recommended that an existing usage be expunged." That seems to
be the strongest argument in favor of Hsieh's position that I
have seen so far. It is very hard to think of a justification
for it appearing unadorned with a a warning in the text.
A genuine fix for the actual problem requires something quite
different from removing gets from the system library.


What would you propose?

--
Randy Howard (2reply remove FOOBAR)

Nov 15 '05 #74
On Tue, 30 Aug 2005 21:36:44 GMT, Randy Howard
<ra*********@FOOverizonBAR.net> wrote:
Alan Balmer wrote
(in article <0c********************************@4ax.com>):
Can't you guys find a more suitable venue for your argument?


I'm sorry. Is a discussion about what might or might not happen
in future C standards drowning out discussions of homework
problems and topicality?


Reread your last 223-line post. That's not what it was about.

Unless you are concentrating mostly on the "might not happen" aspect,
in which case everything becomes topical. I can think of hundreds of
things which might not appear in future C standards.
--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 15 '05 #75
Randy Howard wrote:
Yes. Also, it is incredibly unlikely that a naive novice
programmer will be producing software that will be widely
deployed and wind up in a CERT advisory, but I suppose it is not
impossible.
Judging by some of the reported bugs, one wonders.

Just a few weeks ago, there was an IAVA for a bug in
Kerberos v5 that was essentially of the form
if (!try_something) {
error_flag = CODE;
free(buffer);
}
free(buffer);
How that could have passed even a casual code review
is a mystery.
I am somewhat curious about why even as late as C99, or even
later in TC1, there is still no official wording in the standard
concerning gets() being of any concern at all. It seems that it
couldn't have offended many people to simply saying "hey, this
is in the standard already, but it's really not a good idea to
use it for new development, and in fact, it is highly
recommended that an existing usage be expunged." That seems to
be the strongest argument in favor of Hsieh's position that I
have seen so far. It is very hard to think of a justification
for it appearing unadorned with a a warning in the text.


The simple answer is that the C standard is a specification
document, not a programming tutorial. Such a warning
properly belongs in the Rationale Document, not in the spec.
Nov 15 '05 #76
we******@gmail.com wrote:

Second of all, remember, I *BEAT* the performance of C's strings
across the board on multiple platforms with a combination of run
time and API design in Bstrlib. This is a false idea that error
checking always costs performance. Performance is about design,
not what you do about safety.


You keep going on about how "C is slow" and "it would be easy
to make it faster and safer". Now you claim that you have a
library that does make C "faster and safer".

In other messages, you've explained that by "safer", you mean
being less prone to buffer overflows and undefined behaviour.

The only way a C-like language can avoid buffer overflows
is to include a runtime bounds check.

Please explain how -adding- a runtime bounds check to some
code, makes it faster than the exact same code but without
the check.

Nov 15 '05 #77
In article <11**********************@o13g2000cwo.googlegroups .com>,
we******@gmail.com writes
Randy Howard wrote:
we******@gmail.com wrote:

It is the fault of the development team, comprised of whoever
that involves for a given project. If the programmer feels like
his boss screwed him over, let him refuse to continue, swear out
an affidavit and have it notarized the bad software was
knowingly shipped, and that you refuse to endorse it.
Oh I see. So, which socialist totally unionized company do you work as
a programmer for? I'd like to apply!


You don't need to work in a unionised company to do that. I have seen
Professional Software Engineers put disclaimers on work they have had to
modify that whilst they are happy with their own work they were very
unhappy with the rest of it. It even got locked into the comments in the
CVs database to make sure it was on record.

Of course the corporate manslaughter Bill (UK) helps now.
[...] If you
are being overworked, you can either keep doing it, or you can
quit, or you can convince your boss to lighten up.


Hmmm ... so you live in India?


How the hell do you come to that conclusion? seriously I would like to
see your reasoning here.
I'm trying to guess where it is in this
day and age that you can just quit your job solely because you don't
like the pressures coming from management.
Any civilised country. Life is too short to mess about. It is the way
Professionals should behave.

Try and force me to write something in a way that I know is
wrong. Go ahead, it'll be a short argument, because I will
resign first.


That's a nice bubble you live in. Or is it just in your mind?


No. People do that. Seen it done. apparently you don't mind what you do
as long as you are paid. Where do you draw the line?

Try and force a brain surgeon to operate on your head with a
chainsaw. good luck.
>> [...] If you could be fined or perhaps even jailed for
>> gross neglicence in software development the way doctors can be
>> today, I suspect the problem would be all but nonexistent.
>
> Ok, that's just vindictive nonsense.


Why? We expect architects, doctors, lawyers, pretty much all
other real 'professions' to meet and typically exceed a higher
standard, and those that do not are punished, fined, or stripped
of their license to practice in the field. Why should
programmers get a pass? Is it because you do not feel it is a
professional position?


Because its not as structured, and that's simply not practical.
Doctors have training, internships, etc. Lawyers have to pass a bar
exam, etc. There's no such analogue for computer programmers.


Yes there is. Most certainly. There is the PE in many countries and
Chartered Engineer in others. It requires a Degree, training and
experience.

The discussion in another thread is should it be made mandatory world
wide.
We don't let anyone that wants to prescribe medicine, why should
we let anyone that wants to put software up for download which
could compromise system security?
> Programmers are generally not aware of the liability of
> their mistakes.


Then those you refer to must be generally incompetent.
Agreed.
Correct. It's also not possible to completely remove medical
malpractice, but it gets punished anyway. It's called a
deterrent.


You don't think medical practioners use the latest and safest
technology available to practice their medicine?


Not always.
Go measure your own first-compile error rate
That is a meaningless statistic.
For a nuclear reactor, I would also include the requirement that they
use a safer programming language like Ada.
As the studies have shown.. language choice has a minimum impact on
errors.
Personally I would be
shocked to know that *ANY* nuclear reactor control mechanism was
written in C. Maybe a low level I/O driver library, that was
thoroughly vetted (because you probably can't do that in Ada), but
that's it.
Which destroys your argument! Use Ada because it is safe but the
interface between Ada and the hardware is C.... So effectively C
controls the reactor.

I guess all the professionals in other fields where they are
held up to scrutiny must be irresponsible daredevils too.


No -- they have great assistance and controlled environments that allow
them to perform under such conditions.


Yes.
Something akin to using a
better programming language.
No.
[...] For
example, there are operations that have very low success rates,
yet there are doctors that specialize in them anyway, despite
the low odds.


Well, your analogy only makes some sense if you are talking about
surgeons in developing countries who simply don't have access to the
necessary anesthetic, support staff or even the proper education to do
the operation correctly. In those cases, there is little choice, so
you make do with what you have. But obviously its a situation you just
want to move away from -- they way you solve it, is you give them
access to the safer, and better ways to practice medicine.


There is a blinkered view. Some operations are the only choice between
life and death. a relative on mine had that... this op has a 40% success
rate. Without it your life expectancy is about 2 weeks.

So you do the dangerous op.

If you don't want to take the risk, then go write in visual
whatever#.net and leave it to those that are.


So you want some people to stay away from C because the language is too
dangerous.


It is in the hands of the inexperienced.
While I want the language be fixed so that most people
don't trigger the landmines in the language so easily. If you think
about it, my solution actually *costs* less.


I have seem more errors in "safe" languages because people thought it if
compiled OK it must be good code... there is a LOT more to it than
getting it to compile. Only an idiot would think that.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Nov 15 '05 #78
In article <00*****************************@news.verizon.net> , Randy
Howard <ra*********@FOOverizonBAR.net> writes
The actual ANSI C committee
is different -- they knew exactly what role C was taking. They have
the ability to fix the warts in the language.
No, they have the ability to recommend fixes to a language,


Actually "they" (the WG14 committee) can change or "fix" the language
Unfortunately IMOH they are not doing so.
but
as we have already seen, the developer community is more than
willing to ignore them when push comes to shove. A community
that strong-willed should be strong enough to address the gets()
problem itself, and not rely on 'permission' from the standard
group.
This is why things like MISRA-C exist and are widely used.
Tell me, when is the last time the C language committee considered a
change in the language that made it truly more powerful that wasn't
already implemented in many compilers as extensions?


I can't think of an example offhand, but I am restricted by not
being completely fluent on all the various compiler extensions,
as I try to avoid them whenever possible. Even so, you have a
point about their past history.


They are about to do it for the IBM maths extensions. Also some DSP
maths functions
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Nov 15 '05 #79
On Thu, 25 Aug 2005 20:15:55 +0000, Douglas A. Gwyn wrote:
Walter Roberson wrote:
This starts to get into murky waters. Z-X is a subtraction
of pointers, the result of which is ptrdiff_t, which is a signed
integral type. Logically, though, Z-X could be of size_t, which
is unsigned. This difference has probably been discussed in the past,
but I have not happened to see the discussion of what happens with
pointer subtraction if the object size would fit in the unsigned
type but not in the signed type. Anyhow, ro, lo, ol should not be int.


ptrdiff_t is supposed to be defined as a type wide enough to
accommodate *any* possible result of a valid subtraction of
pointers to objects. If an implementation doesn't *have* a
suitable integer type, that is a deficiency..


The standard disagrees with you. 6.5.6p9 says:

"When two pointers are subtracted, both shall point to elements of the
same array object, or one past the last element of the array object; the
result is the difference of the subscripts of the two array elements. The
size of the result is implementation-defined, and its type (a signed
integer type) is ptrdiff_t defined in the <stddef.h> header. If the
result is not representable in an object of that type, the behavior is
undefined. ..."

It states very clearly in the last sentence that the result of pointer
subtraction need not be representable as a ptrdiff_t. In such a case you
get undefined behaviour i.e. it is the program that is at fault, not the
implementation.

Lawrence

Nov 15 '05 #80
Douglas A. Gwyn wrote:
Randy Howard wrote:
Yes. Also, it is incredibly unlikely that a naive novice
programmer will be producing software that will be widely
deployed and wind up in a CERT advisory, but I suppose it is not
impossible.
Judging by some of the reported bugs, one wonders.

Just a few weeks ago, there was an IAVA for a bug in
Kerberos v5 that was essentially of the form
if (!try_something) {
error_flag = CODE;
free(buffer);
}
free(buffer);
How that could have passed even a casual code review
is a mystery.


I recently had to find out why two of our build environments were
behaving slightly differently from each other.
It turned out that a largely unrelated component, which is only included
in one of the environments, did something in the line of
EnterCriticalSection();
if (condition)
return;
ExitCriticalSection();
and due to the architecture of our system, this affected quite a number
of processes.
The simple answer is that the C standard is a specification
document, not a programming tutorial. Such a warning
properly belongs in the Rationale Document, not in the spec.


I think that marking gets() as deprecated should be warning enough for
people to understand that the function must not be used for new code or
code that is being prepared for a new compiler version.

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
Nov 15 '05 #81
Lawrence Kirby <lk****@netactive.co.uk> writes:
On Thu, 25 Aug 2005 20:15:55 +0000, Douglas A. Gwyn wrote:
Walter Roberson wrote:
This starts to get into murky waters. Z-X is a subtraction
of pointers, the result of which is ptrdiff_t, which is a signed
integral type. Logically, though, Z-X could be of size_t, which
is unsigned. This difference has probably been discussed in the past,
but I have not happened to see the discussion of what happens with
pointer subtraction if the object size would fit in the unsigned
type but not in the signed type. Anyhow, ro, lo, ol should not be int.


ptrdiff_t is supposed to be defined as a type wide enough to
accommodate *any* possible result of a valid subtraction of
pointers to objects. If an implementation doesn't *have* a
suitable integer type, that is a deficiency..


The standard disagrees with you. 6.5.6p9 says:

"When two pointers are subtracted, both shall point to elements of the
same array object, or one past the last element of the array object; the
result is the difference of the subscripts of the two array elements. The
size of the result is implementation-defined, and its type (a signed
integer type) is ptrdiff_t defined in the <stddef.h> header. If the
result is not representable in an object of that type, the behavior is
undefined. ..."

It states very clearly in the last sentence that the result of pointer
subtraction need not be representable as a ptrdiff_t. In such a case you
get undefined behaviour i.e. it is the program that is at fault, not the
implementation.


Actually it doesn't say that the result need not be representable;
only that *if* the result is not representable then something else
is true. The cited paragraph doesn't say that the "if" clause can
be satisfied. We might infer that it can, but the text doesn't say
that it can.

I've been unable to find any statement one way or the other about
whether ptrdiff_t must accommodate all pointer subtractions done on
valid arrays. Consider for example the following. Suppose
PTRDIFF_MAX == INT_MAX, and SIZE_MAX == UINT_MAX; then

char *p0 = malloc( 1 + (size_t)PTRDIFF_MAX );
char *p1 = p0 + PTRDIFF_MAX;
char *p2 = p1 + 1;
size_t s = p2 - p0;

If undefined behavior prevents the last assignment from working,
what are we to conclude? That size_t is the wrong type? That
SIZE_MAX has the wrong value? That malloc should have failed
rather than delivering a too-large object? That ptrdiff_t is
the wrong type? Or that all standard requirements were met,
and the problem is one of low quality of implementation?

I believe, in the absense of an explicit statement to the contrary,
the limits on ptrdiff_t and PTRDIFF_MAX allow the possibility that
a difference of valid pointers to a valid array object might not be
representable as a value of type ptrdiff_t. I also think the
language would be improved if there were a requirement that a
difference of valid pointers to a valid array object must always be
representable as a value of type ptrdiff_t.

However, whether the language does or does not, or should or should
not, have such a requirement, the *standard* would be improved if it
included an explicit statement about whether this requirement must
be met.
Nov 15 '05 #82
Douglas A. Gwyn wrote
(in article <43***************@null.net>):
The simple answer is that the C standard is a specification
document, not a programming tutorial. Such a warning
properly belongs in the Rationale Document, not in the spec.


Okay, where can I obtain the Rationale Document that warns
programmers not to use gets()?
--
Randy Howard (2reply remove FOOBAR)

Nov 15 '05 #83
Randy Howard wrote:
Okay, where can I obtain the Rationale Document that warns
programmers not to use gets()?


http://www.open-std.org/jtc1/sc22/wg...onaleV5.10.pdf
Nov 15 '05 #84
Chris Hills <ch***@phaedsys.org> writes:
In article <11**********************@o13g2000cwo.googlegroups .com>,
we******@gmail.com writes

[...]
For a nuclear reactor, I would also include the requirement that they
use a safer programming language like Ada.


As the studies have shown.. language choice has a minimum impact on
errors.
Personally I would be
shocked to know that *ANY* nuclear reactor control mechanism was
written in C. Maybe a low level I/O driver library, that was
thoroughly vetted (because you probably can't do that in Ada), but
that's it.


Which destroys your argument! Use Ada because it is safe but the
interface between Ada and the hardware is C.... So effectively C
controls the reactor.


Just to correct the misinformation, there's no reason a low level I/O
driver library couldn't be written in Ada. The language was designed
for embedded systems. Ada can do all the unsafe low-level stuff C can
do; it just isn't the default.

--
Keith Thompson (The_Other_Keith) 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.
Nov 15 '05 #85
Wojtek Lerch <Wo******@yahoo.ca> writes:
Randy Howard wrote:
Okay, where can I obtain the Rationale Document that warns
programmers not to use gets()?


http://www.open-std.org/jtc1/sc22/wg...onaleV5.10.pdf


Which says, in 7.19.7.7:

Because gets does not check for buffer overrun, it is generally
unsafe to use when its input is not under the programmer's
control. This has caused some to question whether it should
appear in the Standard at all. The Committee decided that gets
was useful and convenient in those special circumstances when the
programmer does have adequate control over the input, and as
longstanding existing practice, it needed a standard
specification. In general, however, the preferred function is
fgets (see 7.19.7.2).

Personally, I think the Committee blew it on this one. I've never
heard of a real-world case where a program's input is under
sufficiently tight control that gets() can be used safely. On the
other hand, I have seen numerous calls to gets() in programs that are
expected to receive interactive input. As far as I know, the
"longstanding existing practice" cited in the Rationale is the
*unsafe* use of gets(), not the hypothetical safe use.

In the unlikely event that I were implementing a system where I had
that kind of control over a program's stdin, I'd still use fgets() so
I could do some error checking, at least in the context of unit
testing. Even in such a scenario, I'd be far more likely to read from
a source other than stdin, where gets() can't be used anyway.

I just found 13 calls to gets() in the source code for a large
software package implemented in C (which I prefer not to identify).
They were all in small test programs, not in production code, and they
all used buffers large enough that an interactive user is not likely
to overflow it -- but that's no excuse for writing unsafe code.

I'd be interested in seeing any real-world counterexamples.

--
Keith Thompson (The_Other_Keith) 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.
Nov 15 '05 #86
Wojtek Lerch wrote
(in article <e3*******************@news20.bellglobal.com>):
Randy Howard wrote:
Okay, where can I obtain the Rationale Document that warns
programmers not to use gets()?


http://www.open-std.org/jtc1/sc22/wg...onaleV5.10.pdf


Indeed. It doesn't exactly make the point very clearly, or
pointedly. Somehow "generally unsafe" doesn't seem strong
enough to me.

--
Randy Howard (2reply remove FOOBAR)

Nov 15 '05 #87
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

Personally, I think the Committee blew it on this one. I've never
heard of a real-world case where a program's input is under
sufficiently tight control that gets() can be used safely. On the
other hand, I have seen numerous calls to gets() in programs that are
expected to receive interactive input. As far as I know, the
"longstanding existing practice" cited in the Rationale is the
*unsafe* use of gets(), not the hypothetical safe use.


I think gets() could be made safer with some minor changes.

Add something like "#define GETSMAX n" to stdio.h, where n is an
implementation-defined constant with a guaranteed minimum. Then,
redefine gets() such that it is guaranteed to never put more than
GETSMAX-1 characters plus the trailing \0 into the buffer. Additional
characters in the input will be thrown away.

Code that uses gets() could then be made "safe" by making sure the
buffer passed in has at least GETSMAX characters available.

An interesting alternative to this would be to provide a function or
variable that can be set by the programmer at run time to alter gets()
max length behavior, something like setgetssize(size_t n). This would
allow an existing program filled with declarations like "char
inbuf[80]" to be fixable with one line.

Of course, nothing is stopping programmers from writing their own
line-oriented input function with exactly the interface they like. For
something on the order of gets() of fgets() it wouldn't take very long.
Nov 15 '05 #88
an******@example.com (Anonymous 7843) writes:
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

Personally, I think the Committee blew it on this one. I've never
heard of a real-world case where a program's input is under
sufficiently tight control that gets() can be used safely. On the
other hand, I have seen numerous calls to gets() in programs that are
expected to receive interactive input. As far as I know, the
"longstanding existing practice" cited in the Rationale is the
*unsafe* use of gets(), not the hypothetical safe use.
I think gets() could be made safer with some minor changes.


I disagree.
Add something like "#define GETSMAX n" to stdio.h, where n is an
implementation-defined constant with a guaranteed minimum. Then,
redefine gets() such that it is guaranteed to never put more than
GETSMAX-1 characters plus the trailing \0 into the buffer. Additional
characters in the input will be thrown away.

Code that uses gets() could then be made "safe" by making sure the
buffer passed in has at least GETSMAX characters available.


Assuming such a change is made in the next version of the standard, or
widely implemented as an extension, code that uses the new safe gets()
will inevitably be recompiled on implementations that provide the old
unsafe version.

The solution is to eradicate gets(), not to fix it.

To paraphrase Dennis Ritchie's comments on the proposed "noalias"
keyword (and not to imply that he does or doesn't agree with me on
gets()):

gets() must go. This is non-negotiable.

--
Keith Thompson (The_Other_Keith) 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.
Nov 15 '05 #89
"Randy Howard" <ra*********@FOOverizonBAR.net> wrote in message
news:00*****************************@news.verizon. net...
Wojtek Lerch wrote
(in article <e3*******************@news20.bellglobal.com>):
Randy Howard wrote:
Okay, where can I obtain the Rationale Document that warns
programmers not to use gets()?


http://www.open-std.org/jtc1/sc22/wg...onaleV5.10.pdf


Indeed. It doesn't exactly make the point very clearly, or
pointedly. Somehow "generally unsafe" doesn't seem strong
enough to me.


Sure. Whatever. I don't think a lot of programmers learn C from the
Standard or the Rationale anyway. It should be the job of teachers and
handbooks to make sure that beginners realize that it's not a good idea to
use gets(), or to divide by zero, or to cause integer overflow.

On the other hand, I don't think it would be unreasonable for the Standard
to officially declare gets() as obsolescent in the "Future library
directions" chapter.
Nov 15 '05 #90
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

an******@example.com (Anonymous 7843) writes:

Add something like "#define GETSMAX n" to stdio.h, where n is an
implementation-defined constant with a guaranteed minimum. Then,
redefine gets() such that it is guaranteed to never put more than
GETSMAX-1 characters plus the trailing \0 into the buffer. Additional
characters in the input will be thrown away.

Code that uses gets() could then be made "safe" by making sure the
buffer passed in has at least GETSMAX characters available.
Assuming such a change is made in the next version of the standard, or
widely implemented as an extension, code that uses the new safe gets()
will inevitably be recompiled on implementations that provide the old
unsafe version.


Making a change in a new C standard is supposed to fix
implementations adhering to old standards? That's a mighty
high wall to climb, for any proposed change.

Aside from that, if the "new code" used GETSMAX or
setgetsbuflen() it would actually fail to compile on an old
implementation.
gets() must go. This is non-negotiable.


The situation isn't quite the same. noalias was a new
proposal with no existing code in jeopardy. gets() is
used widely in quick-n-dirty contexts like unit tests.

Ideally, gets() *would* go (see, I secretly agree with you,
please don't tell anyone) and there would a replacement
that comes to a nice compromise between the simplicity of
using gets() and the lets-not-incite-undefined-behavior
aspect of fgets().

Something like getstr(char *, size_t) with the truncation
of long lines.
Nov 15 '05 #91
In article <ln************@nuthaus.mib.org>, Keith Thompson <kst-
u@mib.org> writes
Wojtek Lerch <Wo******@yahoo.ca> writes:
Randy Howard wrote:
Okay, where can I obtain the Rationale Document that warns
programmers not to use gets()?


http://www.open-std.org/jtc1/sc22/wg...onaleV5.10.pdf


Which says, in 7.19.7.7:

Because gets does not check for buffer overrun, it is generally
unsafe to use when its input is not under the programmer's
control. This has caused some to question whether it should
appear in the Standard at all. The Committee decided that gets
was useful and convenient in those special circumstances when the
programmer does have adequate control over the input, and as
longstanding existing practice, it needed a standard
specification. In general, however, the preferred function is
fgets (see 7.19.7.2).

Personally, I think the Committee blew it on this one. I've never
heard of a real-world case where a program's input is under
sufficiently tight control that gets() can be used safely. On the
other hand, I have seen numerous calls to gets() in programs that are
expected to receive interactive input. As far as I know, the
"longstanding existing practice" cited in the Rationale is the
*unsafe* use of gets(), not the hypothetical safe use.

In the unlikely event that I were implementing a system where I had
that kind of control over a program's stdin, I'd still use fgets() so
I could do some error checking, at least in the context of unit
testing. Even in such a scenario, I'd be far more likely to read from
a source other than stdin, where gets() can't be used anyway.

I just found 13 calls to gets() in the source code for a large
software package implemented in C (which I prefer not to identify).
They were all in small test programs, not in production code, and they
all used buffers large enough that an interactive user is not likely
to overflow it -- but that's no excuse for writing unsafe code.

I'd be interested in seeing any real-world counterexamples.


I think this was one of the reasons in the very early days of some of
the more security conscious computer networks that could be externally
accessed. They would sent as stream of several Kbytes of characters
back at anyone who did not get the password right at the first attempt.
Thus over flowing any buffers.
Back in the days when I had a better power to weight ratio and a 1200
full duplex modem was FAST I found a few like that. No it was not parity
errors or wrong baud rate. They looked different. In fact it was a
different world back then.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Nov 15 '05 #92
an******@example.com (Anonymous 7843) writes:
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

an******@example.com (Anonymous 7843) writes:
>
> Add something like "#define GETSMAX n" to stdio.h, where n is an
> implementation-defined constant with a guaranteed minimum. Then,
> redefine gets() such that it is guaranteed to never put more than
> GETSMAX-1 characters plus the trailing \0 into the buffer. Additional
> characters in the input will be thrown away.
>
> Code that uses gets() could then be made "safe" by making sure the
> buffer passed in has at least GETSMAX characters available.
Assuming such a change is made in the next version of the standard, or
widely implemented as an extension, code that uses the new safe gets()
will inevitably be recompiled on implementations that provide the old
unsafe version.


Making a change in a new C standard is supposed to fix
implementations adhering to old standards? That's a mighty
high wall to climb, for any proposed change.


No, of course a change in a new standard won't fix old
implementations. That was my point.
Aside from that, if the "new code" used GETSMAX or
setgetsbuflen() it would actually fail to compile on an old
implementation.
Sure, but it would make it more difficult to detect code that uses
gets() incorrectly. Given the current standard, that's basically any
code that uses gets().
gets() must go. This is non-negotiable.


The situation isn't quite the same. noalias was a new
proposal with no existing code in jeopardy. gets() is
used widely in quick-n-dirty contexts like unit tests.


Yes, and it shouldn't be.
Ideally, gets() *would* go (see, I secretly agree with you,
please don't tell anyone) and there would a replacement
that comes to a nice compromise between the simplicity of
using gets() and the lets-not-incite-undefined-behavior
aspect of fgets().

Something like getstr(char *, size_t) with the truncation
of long lines.


You're proposing a new variant of fgets() that doesn't specify the
input file (and therefore always uses stdin), and that strips the
trailing '\n'. I would have no objection to that. But with or
without this new function, gets() should not be used, and ideally
should not be standardized or implemented.

--
Keith Thompson (The_Other_Keith) 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.
Nov 15 '05 #93
Anonymous 7843 wrote
(in article <i9rRe.1983$mH.1699@fed1read07>):
Making a change in a new C standard is supposed to fix
implementations adhering to old standards? That's a mighty
high wall to climb, for any proposed change.
Yes. A far better use of spam would be to send out notices to
everyone with an email account on the dangers of gets() instead
of trying to convince them to order prescription medicine
online.
Aside from that, if the "new code" used GETSMAX or
setgetsbuflen() it would actually fail to compile on an old
implementation.
There are so many better alternatives available, I see no reason
to reuse the same name for different behavior. It's not like
they are running out of names for functions. Since str-whatever
is reserved already, strget might make a nice solution, and an
implementation similar to what various folks have proposed in
the past, such as Heathfield's 'fgetline' (IIRC), or ggets()
from CBF, etc. There certainly wouldn't be any harm in /adding/
a new replacement that can be used safely, and deprecating
gets() entirely. Reusing gets() would just confuse even more
people. The world does not need more confused newbies, they are
already in abundant supply and replicate faster than they
disappear.
gets() must go. This is non-negotiable.


The situation isn't quite the same. noalias was a new
proposal with no existing code in jeopardy. gets() is
used widely in quick-n-dirty contexts like unit tests.


I can't think of a single example of gets() being used in a
piece of code worth worrying about. If it is used widely in
quick-n-dirty contexts, then it isn't a problem. It's trivial
to fix 'quick-n-dirty programs if you get bitten by it.

The bigger packages using it, /need/ to break as early as
possible, before they spread into broader use and cause more
problems.
Something like getstr(char *, size_t) with the truncation
of long lines.


There are lots of options, and that may be part of the problem.
Too many choices. Fortunately, all of them are better than the
currently standardized gets().

--
Randy Howard (2reply remove FOOBAR)

Nov 15 '05 #94
Wojtek Lerch wrote
(in article <2d********************@rogers.com>):
"Randy Howard" <ra*********@FOOverizonBAR.net> wrote in message
news:00*****************************@news.verizon. net...
Wojtek Lerch wrote
(in article <e3*******************@news20.bellglobal.com>):
Randy Howard wrote:
Okay, where can I obtain the Rationale Document that warns
programmers not to use gets()?

http://www.open-std.org/jtc1/sc22/wg...onaleV5.10.pdf
Indeed. It doesn't exactly make the point very clearly, or
pointedly. Somehow "generally unsafe" doesn't seem strong
enough to me.


Sure. Whatever. I don't think a lot of programmers learn C from the
Standard or the Rationale anyway.


Unfortunately, some of them don't listen to anything not nailed
down though. The typical freshly-minted know-it-all response is
"Who are you to tell me not to use it? The ISO C standards body
put it in there for a reason. If it was bad, it wouldn't be in
an international standard. duh."
It should be the job of teachers and handbooks to make sure that
beginners realize that it's not a good idea to use gets(), or to
divide by zero, or to cause integer overflow.
You'd think so. Judging by the number of college students today
that ask questions about basic problems with floating point
error propagation and avoidance, I am not enthusiastic about the
odds. That was a freshman year course back in the day, since we
weren't going to school to learn how to specify em units in a
style sheet, we were supposed to be learning about using
computers for something useful, like solving engineering
problems.
On the other hand, I don't think it would be unreasonable for the
Standard to officially declare gets() as obsolescent in the "Future
library directions" chapter.


If ISO expects anyone to take C0x seriously, then they have to
do something about this sort of thing, including gets() and
perhaps some strong words at least about some of the other
string function suspects as well. If gets() stays in unadorned,
it'll be pathetic.
--
Randy Howard (2reply remove FOOBAR)

Nov 15 '05 #95
Keith Thompson wrote
(in article <ln************@nuthaus.mib.org>):
Which says, in 7.19.7.7:

Because gets does not check for buffer overrun, it is generally
unsafe to use when its input is not under the programmer's
control. This has caused some to question whether it should
appear in the Standard at all. The Committee decided that gets
was useful and convenient in those special circumstances when the
programmer does have adequate control over the input, and as
longstanding existing practice, it needed a standard
specification. In general, however, the preferred function is
fgets (see 7.19.7.2).

Personally, I think the Committee blew it on this one.
I think that is an almost universal opinion, apart from those
that were sitting on it at the time. They're outnumbered about
10000:1 from what I can tell. Every time a buffer overrun gets
reported, or another "Shellcoder's Handbook" bets published, the
odds get even worse.

Having a few people sitting around doing the three-monkeys trick
doesn't change it.
As far as I know, the
"longstanding existing practice" cited in the Rationale is the
*unsafe* use of gets(), not the hypothetical safe use.
Exactamundo. I'd love to see a single example of a widely used
program implemented with gets() that can be demonstrated as
safe, due to the programmer having 'adequate control'. Can
anyone point to one that is in the wild?
I just found 13 calls to gets() in the source code for a large
software package implemented in C (which I prefer not to identify).
I wonder what it would take to get SourceForge to scan every
line of C or C++ source looking for it and putting out a 'bad
apples' list on their home page. A basic service for the good
of humanity. Embargoing downloads for projects until they are
expunged would be even better. Time to wake up...
They were all in small test programs, not in production code, and they
all used buffers large enough that an interactive user is not likely
to overflow it -- but that's no excuse for writing unsafe code.


One particular email package that is widely claimed to be
extremely secure and well-written includes a dozen or more
instances of void main() in it's various components. The author
couldn't care less, despite having been made aware of it.
That's a lesser evil in the grand scheme of things, but when
people refuse to change things, even when they know they are
wrong, you know it isn't going to be easy.

--
Randy Howard (2reply remove FOOBAR)

Nov 15 '05 #96
"Randy Howard" <ra*********@FOOverizonBAR.net> wrote in message
news:00*****************************@news.verizon. net...
Wojtek Lerch wrote
(in article <2d********************@rogers.com>):
"Randy Howard" <ra*********@FOOverizonBAR.net> wrote in message
news:00*****************************@news.verizon. net...
Indeed. It doesn't exactly make the point very clearly, or
pointedly. Somehow "generally unsafe" doesn't seem strong
enough to me.


Sure. Whatever. I don't think a lot of programmers learn C from the
Standard or the Rationale anyway.


Unfortunately, some of them don't listen to anything not nailed
down though. The typical freshly-minted know-it-all response is
"Who are you to tell me not to use it? The ISO C standards body
put it in there for a reason. If it was bad, it wouldn't be in
an international standard. duh."


Well, *then* you can point them to the Rationale and explain what it means
by "generally unsafe". You could even try to explain why it was
standardized even though it was known to be unsafe, and why a lot of people
disagree with that decision. A good teacher can take advantage of this kind
of stuff.

Anyway, think of all the unsafe things they'll have to learn not to do
before they become competent programmers. Pretty much all of them are more
difficult to avoid than gets().
It should be the job of teachers and handbooks to make sure that
beginners realize that it's not a good idea to use gets(), or to
divide by zero, or to cause integer overflow.


You'd think so.


I haven't said anything about how well I think they're doing their job. I'm
sure there are a lot of bad teachers and bad handbooks around. But I doubt
banning gets() would make it significantly easier for their victims to
become competent programmers.
Nov 15 '05 #97
About my attitude to gets(), this was dredged from google.
Conversations repeat; there are about 78 things in
this "The fate of gets" thread.
Dennis Ritchie Nov 9 1999, 8:00 Newsgroups: comp.std.c
From: Dennis Ritchie <d...@bell-labs.com> Date: 1999/11/09
Subject: Re: The fate of gets Clive D.W. Feather wrote:
..... If most implementers will ship gets() anyway,
there's little practical effect to eliminating it from the Standard.
On the other hand, we removed it from our library about a week
after the Internet worm. Of course, some couldn't afford
to do that.


Dennis

Nov 15 '05 #98
Randy Howard <ra*********@FOOverizonBAR.net> wrote:
Wojtek Lerch wrote
"Randy Howard" <ra*********@FOOverizonBAR.net> wrote in message
Wojtek Lerch wrote
Indeed. It doesn't exactly make the point very clearly, or
pointedly. Somehow "generally unsafe" doesn't seem strong
enough to me.


Sure. Whatever. I don't think a lot of programmers learn C from the
Standard or the Rationale anyway.


Unfortunately, some of them don't listen to anything not nailed
down though. The typical freshly-minted know-it-all response is
"Who are you to tell me not to use it? The ISO C standards body
put it in there for a reason. If it was bad, it wouldn't be in
an international standard. duh."


I think you over-estimate the average VB-level programmer. s/ISO C
standards body/Great and Sacred Microsoft/ and s/an international
standard/MSVC++###/ would be more realistic.

Richard
Nov 15 '05 #99
Keith Thompson wrote:
Which says, in 7.19.7.7:
Because gets does not check for buffer overrun, it is generally
unsafe to use when its input is not under the programmer's
control. This has caused some to question whether it should
appear in the Standard at all. The Committee decided that gets
was useful and convenient in those special circumstances when the
programmer does have adequate control over the input, and as
longstanding existing practice, it needed a standard
specification. In general, however, the preferred function is
fgets (see 7.19.7.2).
Personally, I think the Committee blew it on this one. I've never
heard of a real-world case where a program's input is under
sufficiently tight control that gets() can be used safely.
You must have a lack of imagination -- there are a great many
cases where one is coding for a small app where the programmer
himself has complete control over all data that the app will
encounter. Note that that is not at all the same environment
as arbitrary or interactive input, where of course lack of
proper validation of input would be a BUG.
... As far as I know, the
"longstanding existing practice" cited in the Rationale is the
*unsafe* use of gets(), not the hypothetical safe use.
No, it's simply the existing use of gets as part of the stdio
library, regardless of judgment about safety. As such, it was
part of the package for which the C standard was expected to
provide specification.
I just found 13 calls to gets() in the source code for a large
software package implemented in C (which I prefer not to identify).
They were all in small test programs, not in production code, and they
all used buffers large enough that an interactive user is not likely
to overflow it -- but that's no excuse for writing unsafe code.


If in fact the test programs cannot overflow their buffers
with any of the test data provided, they are perforce safe
enough. In fact that's exactly the kind of situation where
gets has traditionally been used and thus needs to exist,
with a portable interface spec, in order to minimize porting
expense.
Nov 15 '05 #100

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.