By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,963 Members | 941 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,963 IT Pros & Developers. It's quick & easy.

How programming in C got me in trouble with the law

P: n/a
I've been programming in C for years, and never experienced troubles
until I started using the new RealC-32, a freeware C compiler from the
same company that makes RealPlayer and Quicktime. That's when the
trouble started. See, RealC-32 is like any other C compiler but with
one notable difference. Any time your code invokes undefined
behavior-- for example by dereferencing an uninitialized pointer--
rather than the usual segmentation fault, instead the program will chug
along as usual, but will silently start launching spam emails and
spyware from the computer.

It was only a matter of time before I accidentally forgot to initialize
a pointer before dereferencing it. Then, sure enough, in place of the
usual segfault, my computer started sending porn to every email account
on the 'net. Hours later, the feds busted down my door and I was
hauled off kicking and screaming.

At my trial I insisted I was not responsible for the spam, that it was
the fault of RealC-32. But a representative from the company pointed
out that they were completely in compliance with the C standard, which
allowed them free reign to do as they pleased with my computer once I
dereferenced that uninitialized pointer. The judge agreed that I was
merely using a RealC-32 extension to simplify the creation of the
spam-sending software, and that I was just as responsible for it as I
would be if I'd explicitly programmed it using, say, gcc. In the end I
was forced to succumb to their logic-- they were, afterall, quite
right.

EPILOGUE

Stone McStone continues to serve hard time in a federal "pound me in
the ass" prison. Hopefully he's learned his lesson about dereferencing
uninitialized pointers! RealC-32 has made millions of dollars by
selling adware contracts to small startup businesses. They are
currently negotiating with Diebold Inc. trying to win the contract to
provide the C compiler for Diebold's controversial e-voting machines.

Sep 17 '06 #1
Share this Question
Share on Google+
27 Replies


P: n/a
Stone McStone posted:
It was only a matter of time before I accidentally forgot to initialize
a pointer before dereferencing it.

I take it you're a novice... ? Truthfully, I can't remember the last time I
used an uninitialised pointer; I know when I was just learning about
pointers, that I made the usual beginner mistake of:

char *p;

p = 5;

, but that was because I lacked an understanding of what a pointer is.

--

Frederick Gotham
Sep 18 '06 #2

P: n/a

Frederick Gotham wrote:
Stone McStone posted:
It was only a matter of time before I accidentally forgot to initialize
a pointer before dereferencing it.


I take it you're a novice... ? Truthfully, I can't remember the last time I
used an uninitialised pointer; I know when I was just learning about
pointers, that I made the usual beginner mistake of:

char *p;

p = 5;

, but that was because I lacked an understanding of what a pointer is.
Alas, I am indeed a novice. If only I had your genius- dare I say,
youre almost DIVINE genius- I would not be held in federal prison
today. There isn't a day that goes by when I don't think about that
dereferenced pointer and all the chaos and destruction it has caused.
Everything... ruined. Darkness. Death comes. All is lost.

Sep 18 '06 #3

P: n/a
Stone McStone posted:
Alas, I am indeed a novice. If only I had your genius- dare I say,
youre almost DIVINE genius-

I might have above-average intelligence, but I'm no genius.

I would not be held in federal prison today. There isn't a day that
goes by when I don't think about that dereferenced pointer and all the
chaos and destruction it has caused. Everything... ruined. Darkness.
Death comes. All is lost.

Ah well, either:

(1) Try not to write code whose behaviour is undefined.
(2) Get a compiler which will deal gracefully with your undefined behaviour.

--

Frederick Gotham
Sep 18 '06 #4

P: n/a
st**********@yahoo.com wrote:
Frederick Gotham wrote:
Stone McStone posted:
It was only a matter of time before I accidentally forgot to initialize
a pointer before dereferencing it.

I take it you're a novice... ? Truthfully, I can't remember the last time I
used an uninitialised pointer; I know when I was just learning about
pointers, that I made the usual beginner mistake of:

char *p;

p = 5;

, but that was because I lacked an understanding of what a pointer is.

Alas, I am indeed a novice. If only I had your genius- dare I say,
youre almost DIVINE genius- I would not be held in federal prison
today. There isn't a day that goes by when I don't think about that
dereferenced pointer and all the chaos and destruction it has caused.
Everything... ruined. Darkness. Death comes. All is lost.
My theories in random order:

1) Troll.
2) Someone very bored who decided to post random
stuff on a group.
3) Someone who wants to tarnish the reputation of a
certain company mentioned in the opening post.

Sep 18 '06 #5

P: n/a
Spiros Bousbouras posted:
My theories in random order:

1) Troll.
2) Someone very bored who decided to post random
stuff on a group.
3) Someone who wants to tarnish the reputation of a
certain company mentioned in the opening post.

Ah yes, I realise this. I found the original post interesting nonetheless.

--

Frederick Gotham
Sep 18 '06 #6

P: n/a
Frederick Gotham said:
Stone McStone posted:
>Alas, I am indeed a novice. If only I had your genius- dare I say,
youre almost DIVINE genius-


I might have above-average intelligence, but I'm no genius.
Precisely the same description applies to a basset hound.

He's ***sending you up***. Don't you see that? YHBT!

If you're really of above-average intelligence, you'll know when to fold.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Sep 18 '06 #7

P: n/a
Richard Heathfield posted:
Frederick Gotham said:
>Stone McStone posted:
>>Alas, I am indeed a novice. If only I had your genius- dare I say,
youre almost DIVINE genius-


I might have above-average intelligence, but I'm no genius.

Precisely the same description applies to a basset hound.

He's ***sending you up***. Don't you see that? YHBT!

If you're really of above-average intelligence, you'll know when to fold.

I'm aware of the nature of this thread, although I though it had an
interesting point: Where the Standard specifies that the behaviour is
undefined, the implementation is free to do whatever it likes -- including
running Spyware. ;) The "nose demons" expression has run its course!

--

Frederick Gotham
Sep 18 '06 #8

P: n/a
Frederick Gotham wrote:
>
I'm aware of the nature of this thread, although I though it had an
interesting point: Where the Standard specifies that the behaviour is
undefined, the implementation is free to do whatever it likes -- including
running Spyware. ;)
I think this needs some clarification , in particular the "free
to do" part. As far as being logically consistent with the C
standard goes then it is true that the implementation is free
to run spyware when encountering undefined behaviour and
still conform to the standard. However a person writing a
C compiler operates in the real world so he/she is restricted
by rules in addition to what the C standard specifies. Most
relevant to the spyware possibility are the rules of good behaviour
and the laws of each country.

If I had reason to believe that a compiler might start running
spyware after encountering undefined behaviour I wouldn't
trust the compiler and therefore stop using it not because the
standard was violated (which it wasn't) but because the rules
of good behaviour as I understand them were violated. After
all if someone is perverted enough to create a compiler which
behaves in such a manner then they cannot be trusted even if
they say that their compiler is conforming ; it might run spyware
even when the programme does not contain undefined behaviour.
>From a practical point of view I think that "undefined behaviour"
will almost always mean one of the following two things:

1) That the compiler will contain no special provisions to deal
with the case so the output will essentially be random. As such
I would expect that the probability of erasing the whole hard disk
is vanishingly small and running spyware practically impossible.
The probability that the compiler has a bug so the behaviour would
be random even when encountering correct code is larger , I think ,
that the probability of any of the above two events happening.

2) That the compiler does contain some special provision as
part of a joke. The obvious example is some version of gcc which
ran Towers of Hanoi when encountering the pragma directive (which
was implementation defined rather than undefined).
The reason I wrote all the above is because I feel that when the
subject of undefined behaviour comes up on this group, it is dealt
with in a somewhat idealistic manner ie if the behaviour is defined
then you are certain what is going to happen but if it is undefined
then anything goes. My point is that realistically speaking if the
behaviour is defined by the standard you are still not certain because
the compiler might have bugs and if it is undefined it is still the
case
that some things which are permitted by the natural laws can not
be expeted to happen.

Sep 18 '06 #9

P: n/a
"Spiros Bousbouras" <sp****@gmail.comwrites:
From a practical point of view I think that "undefined behaviour"
will almost always mean one of the following two things:

1) That the compiler will contain no special provisions to deal
with the case so the output will essentially be random. As such
I would expect that the probability of erasing the whole hard disk
is vanishingly small and running spyware practically impossible.
The probability that the compiler has a bug so the behaviour would
be random even when encountering correct code is larger , I think ,
that the probability of any of the above two events happening.

2) That the compiler does contain some special provision as
part of a joke. The obvious example is some version of gcc which
ran Towers of Hanoi when encountering the pragma directive (which
was implementation defined rather than undefined).
(It was nethack, not Towers of Hanoi.)

Undefined behavior isn't random, it's arbitrary. This is an important
distinction; the word "random" has a specific mathematical meaning,
and using it in this context can raise unrealistic expectations.

Even if the behavior in the presence of, say, a buffer overflow is
purely accidental, if there's code on the system that will reformat
your hard drive, it's conceivable that a misbehaving program could
accidentally branch to that code.

But the results of undefined behavior aren't always purely accidental.
Viruses and other malware typically work by *deliberately* exploiting
buffer overflows. And if it were physically possible for a computer
system to make demons fly out of your nose, you can be that some virus
writer would make it do so.

--
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.
Sep 18 '06 #10

P: n/a
Keith Thompson wrote:
"Spiros Bousbouras" <sp****@gmail.comwrites:
From a practical point of view I think that "undefined behaviour"
will almost always mean one of the following two things:

1) That the compiler will contain no special provisions to deal
with the case so the output will essentially be random. As such
I would expect that the probability of erasing the whole hard disk
is vanishingly small and running spyware practically impossible.
The probability that the compiler has a bug so the behaviour would
be random even when encountering correct code is larger , I think ,
that the probability of any of the above two events happening.

2) That the compiler does contain some special provision as
part of a joke. The obvious example is some version of gcc which
ran Towers of Hanoi when encountering the pragma directive (which
was implementation defined rather than undefined).

(It was nethack, not Towers of Hanoi.)
It was more than one programmes including Towers of
Hanoi. See http://www.abelsson.com/?page=expertcprogramming
>
Undefined behavior isn't random, it's arbitrary. This is an important
distinction; the word "random" has a specific mathematical meaning,
and using it in this context can raise unrealistic expectations.
I don't think that the word random on its own has a specific
mathematical
meaning. Things like "random variable" have a specific mathematical
meaning.
I believe that in the context that I used it random has the same
meaning
as one of the meanings of arbitrary and there is less chance that it
will create
the wrong impression.
>
Even if the behavior in the presence of, say, a buffer overflow is
purely accidental, if there's code on the system that will reformat
your hard drive, it's conceivable that a misbehaving program could
accidentally branch to that code.
Yes , it's conceivable. Just very unlikely especially with the
protections
of modern operating systems. And I would say that a compiler bug
is at least as likely to have the same effect on a correct programme.
>
But the results of undefined behavior aren't always purely accidental.
Viruses and other malware typically work by *deliberately* exploiting
buffer overflows. And if it were physically possible for a computer
system to make demons fly out of your nose, you can be that some virus
writer would make it do so.
Indeed but in such a scenario the behaviour isn't undefined
anymore. The virus writer has made it defined (to suit their
own purposes).

Sep 18 '06 #11

P: n/a
Richard Heathfield wrote:
Frederick Gotham said:
.... snip ...
>>
I might have above-average intelligence, but I'm no genius.

Precisely the same description applies to a basset hound.
ROTFL

--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski

--
Posted via a free Usenet account from http://www.teranews.com

Sep 18 '06 #12

P: n/a
"Spiros Bousbouras" <sp****@gmail.comwrites:
Keith Thompson wrote:
[...]
>(It was nethack, not Towers of Hanoi.)

It was more than one programmes including Towers of
Hanoi. See http://www.abelsson.com/?page=expertcprogramming
You're right, I had forgotten that detail.
>Undefined behavior isn't random, it's arbitrary. This is an important
distinction; the word "random" has a specific mathematical meaning,
and using it in this context can raise unrealistic expectations.

I don't think that the word random on its own has a specific
mathematical meaning. Things like "random variable" have a specific
mathematical meaning. I believe that in the context that I used it
random has the same meaning as one of the meanings of arbitrary and
there is less chance that it will create the wrong impression.
Hmm. Perhaps, but for me the word "random" carries with it an
implication that the possible outcomes are determined by some
consistent probability distribution. In fact, the outcome is
determined by Murphy's Law -- or at least it's safest to think of it
that way.
>Even if the behavior in the presence of, say, a buffer overflow is
purely accidental, if there's code on the system that will reformat
your hard drive, it's conceivable that a misbehaving program could
accidentally branch to that code.

Yes , it's conceivable. Just very unlikely especially with the
protections of modern operating systems. And I would say that a
compiler bug is at least as likely to have the same effect on a
correct programme.
If there's an available library routine that can reformat a disk, and
if your program is running with sufficient privileges to invoke that
routine (which is plausible on some systems), then there's a risk that
it could happen accidentally.
>But the results of undefined behavior aren't always purely accidental.
Viruses and other malware typically work by *deliberately* exploiting
buffer overflows. And if it were physically possible for a computer
system to make demons fly out of your nose, you can be that some virus
writer would make it do so.

Indeed but in such a scenario the behaviour isn't undefined
anymore. The virus writer has made it defined (to suit their
own purposes).
No, the behavior is still undefined as far as the C standard is
concerned. The point is that, in some cases, the outcome can be
determined not by random chance, or even by applied Murphology, but by
conscious malice.

--
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.
Sep 18 '06 #13

P: n/a
st**********@yahoo.com wrote:
I've been programming in C for years, and never experienced troubles
until I started using the new RealC-32, a
[lots-of-more-bull-shit]
Are you ok ? Should we call a doctor ?
Sep 18 '06 #14

P: n/a
Keith Thompson wrote:
[...]
Even if the behavior in the presence of, say, a buffer overflow is
purely accidental, if there's code on the system that will reformat
your hard drive, it's conceivable that a misbehaving program could
accidentally branch to that code.
As I recall, old hard drive I/O cards for the IBM-PC market often had
low-level format code in the BIOS. Jump to the right address, and the
magnetic flux that was once your data was just a memory.

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Sep 18 '06 #15

P: n/a
Spiros Bousbouras wrote:
[...]
From a practical point of view I think that "undefined behaviour"
will almost always mean one of the following two things:

1) That the compiler will contain no special provisions to deal
with the case so the output will essentially be random. As such
I would expect that the probability of erasing the whole hard disk
is vanishingly small and running spyware practically impossible.
The probability that the compiler has a bug so the behaviour would
be random even when encountering correct code is larger , I think ,
that the probability of any of the above two events happening.
You've never run on a system with memory-mapped I/O, have you? A
simple strcpy() or memmove() with in an uninitialized pointer is
enough to start very nasty things happening.

Ditto for platforms without some hardware memory protection, such
as an x86 "real mode" platform. Overwrite the wrong memory, and
the O/S may start scribbling all over the drive.
2) That the compiler does contain some special provision as
part of a joke. The obvious example is some version of gcc which
ran Towers of Hanoi when encountering the pragma directive (which
was implementation defined rather than undefined).
While it's true that it's not likely that a compiler writer has gone
out of his way to explicitly program some behavior for UB situations,
the fact is that one doesn't have to "go out of the way" to do so.
And your gcc example proves that they sometimes do explicitly write
such things. (Though any "good" compiler writer is probably good
enough to do something humorous like a Tower of Hanoi program, rather
than malicious like spyware.)

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Sep 18 '06 #16

P: n/a
Keith Thompson said:

<snip>
Even if the behavior in the presence of, say, a buffer overflow is
purely accidental, if there's code on the system that will reformat
your hard drive, it's conceivable that a misbehaving program could
accidentally branch to that code.
In Liverpool, late 1989, this very nearly happened (on the machine *next* to
mine!) when the programmer forgot that you need one byte for a string's
null terminator. The branch was to the part of MS-DOS that said something
along the lines of "Formatting drive C: will trash the disk - continue
(Y/N)?" - not that exact wording, obviously, but it was clearly a "near
miss".

And in - er, either 1990 or 1991, the chap across the desk from me made
precisely the same error, and trashed his machine's CMOS. Fortunately,
Compaq had provided us with diagnostic diskettes which allowed us to boot
the machine and correct the problem.

"Nasal demons" *do* happen, people. It's just that they don't always wear
red jumpsuits.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Sep 18 '06 #17

P: n/a
st**********@yahoo.com wrote:
>
I've been programming in C for years, and never experienced troubles
until I started using the new RealC-32, a freeware C compiler from the
same company that makes RealPlayer and Quicktime. That's when the
trouble started. See, RealC-32 is like any other C compiler but with
one notable difference. Any time your code invokes undefined
behavior-- for example by dereferencing an uninitialized pointer--
rather than the usual segmentation fault,
instead the program will chug
along as usual, but will silently start launching spam emails and
spyware from the computer.

It was only a matter of time
before I accidentally forgot to initialize
a pointer before dereferencing it.
OK ..., I understand the humor, but it's not making me laugh.
It needs work.

Here's a polished bit of humor on the "do my homework" topic.
This is easily two full orders of magnitude funnier.

http://groups.google.com/group/comp....81c58037083416

--
pete
Sep 18 '06 #18

P: n/a
Frederick Gotham wrote:
I've been programming in C for years, and never experienced troubles
until I started using the new RealC-32, a freeware C compiler from the
same company that makes RealPlayer and Quicktime.
Spiros Bousbouras wrote:
My theories in random order:

1) Troll.
2) Someone very bored who decided to post random
stuff on a group.
3) Someone who wants to tarnish the reputation of a
certain company mentioned in the opening post.
1) Troll or joke, take your pick.
2) What? Bored? Isn't everyone on this group?
3) It's not very certain which company, given that RealPlayer and
Quicktime are made by two separate companies (RealNetworks and Apple).

--
Simon.
Sep 18 '06 #19

P: n/a
Simon Biber wrote:
Frederick Gotham wrote:
I've been programming in C for years, and never experienced troubles
until I started using the new RealC-32, a freeware C compiler from the
same company that makes RealPlayer and Quicktime.
No, Frederick Gotham did not write that.

Sep 19 '06 #20

P: n/a
Simon Biber wrote:
Frederick Gotham wrote:
No he didn't.
I've been programming in C for years, and never experienced troubles
until I started using the new RealC-32, a freeware C compiler from the
same company that makes RealPlayer and Quicktime.

Spiros Bousbouras wrote:
My theories in random order:

1) Troll.
2) Someone very bored who decided to post random
stuff on a group.
<SNIP>
1) Troll or joke, take your pick.
2) What? Bored? Isn't everyone on this group?
I'm not.

Sep 19 '06 #21

P: n/a
Harald van Dijk wrote:
Simon Biber wrote:
>Frederick Gotham wrote:
>>I've been programming in C for years, and never experienced troubles
until I started using the new RealC-32, a freeware C compiler from the
same company that makes RealPlayer and Quicktime.

No, Frederick Gotham did not write that.
My apologies to Frederick; I got confused.

--
Simon.
Sep 19 '06 #22

P: n/a
st**********@yahoo.com wrote:
At my trial I insisted I was not responsible for the spam, that it was
the fault of RealC-32. But a representative from the company pointed
out that they were completely in compliance with the C standard, which
allowed them free reign to do as they pleased with my computer once I
dereferenced that uninitialized pointer.
Actually that is an interesting point. Supposing this compiler did
actually exist, who should be found to be responsible for the spam?

Assuming you answer 'the makers of RealC-32', it seems there is a
sliding scale between this case, and the case of a regular program
on a regular compiler accidentally formatting the harddrive due to UB.

Sep 20 '06 #23

P: n/a

Old Wolf wrote:
st**********@yahoo.com wrote:
At my trial I insisted I was not responsible for the spam, that it was
the fault of RealC-32. But a representative from the company pointed
out that they were completely in compliance with the C standard, which
allowed them free reign to do as they pleased with my computer once I
dereferenced that uninitialized pointer.

Actually that is an interesting point. Supposing this compiler did
actually exist, who should be found to be responsible for the spam?

Assuming you answer 'the makers of RealC-32', it seems there is a
sliding scale between this case, and the case of a regular program
on a regular compiler accidentally formatting the harddrive due to UB.
Well the makers should be responsible for behaviour that
a reasonble man would not anticipate.

So if the makers put a big red notice on the front of every
box saying "Warning, if you compile any program that
invokes behavious undefinied by the C standard, this
compiler will create an executable that sends out spam",
the makers would probably be fine (although they would
not sell many compilers). Otherwise they should
be responsible for the spam because a resonable man would
not expect a simple programming error to result
in a spamming executable.

On the other hand a reasonable man should expect that
a simple programming error would cause an
executable that attemps to execute at random locations
to be produced. If he runs this executable in
a system where such an executable can cause
damage, he has no one but himself to blame for
the damage.

- William Hughes

Sep 20 '06 #24

P: n/a
William Hughes wrote:
>
Old Wolf wrote:
[...]
Actually that is an interesting point. Supposing this compiler did
actually exist, who should be found to be responsible for the spam?

Assuming you answer 'the makers of RealC-32', it seems there is a
sliding scale between this case, and the case of a regular program
on a regular compiler accidentally formatting the harddrive due to UB.

Well the makers should be responsible for behaviour that
a reasonble man would not anticipate.

So if the makers put a big red notice on the front of every
box saying "Warning, if you compile any program that
invokes behavious undefinied by the C standard, this
compiler will create an executable that sends out spam",
the makers would probably be fine (although they would
not sell many compilers). Otherwise they should
be responsible for the spam because a resonable man would
not expect a simple programming error to result
in a spamming executable.
What if the warning said:

Warning! If you compile any program that invokes undefined
behavior, the results may be *ANYTHING*, including, but not
limited to, the melting of your CPU, demons flying out of
your nose, or the slaying of your first-born male child. We
are not responsible for the results of your use of undefined
behavior.

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

Sep 20 '06 #25

P: n/a

Kenneth Brody wrote:
William Hughes wrote:

Old Wolf wrote:
[...]
Actually that is an interesting point. Supposing this compiler did
actually exist, who should be found to be responsible for the spam?
>
Assuming you answer 'the makers of RealC-32', it seems there is a
sliding scale between this case, and the case of a regular program
on a regular compiler accidentally formatting the harddrive due to UB.
Well the makers should be responsible for behaviour that
a reasonble man would not anticipate.

So if the makers put a big red notice on the front of every
box saying "Warning, if you compile any program that
invokes behavious undefinied by the C standard, this
compiler will create an executable that sends out spam",
the makers would probably be fine (although they would
not sell many compilers). Otherwise they should
be responsible for the spam because a resonable man would
not expect a simple programming error to result
in a spamming executable.

What if the warning said:

Warning! If you compile any program that invokes undefined
behavior, the results may be *ANYTHING*, including, but not
limited to, the melting of your CPU, demons flying out of
your nose, or the slaying of your first-born male child. We
are not responsible for the results of your use of undefined
behavior.

Then the makers would be saying that the use of the
program might be dangerous indeed
No one would purchase the compiler. This is an
indication that conformance to the C standard is
not a sufficient condition for comercial success.
(DUH!)

So when you are discussing more than whether
a given program has behaviour specified by the C standard you
have to take other factors into acount. However, the
restricted question of whether a given program has
behaviour specified by the C standard is an
interesting question. Indeed, it is often discussed on comp.lang.c

- William Hughes

Sep 20 '06 #26

P: n/a
"William Hughes" <wp*******@hotmail.comwrites:
Kenneth Brody wrote:
>What if the warning said:

Warning! If you compile any program that invokes undefined
behavior, the results may be *ANYTHING*, including, but not
limited to, the melting of your CPU, demons flying out of
your nose, or the slaying of your first-born male child. We
are not responsible for the results of your use of undefined
behavior.

Then the makers would be saying that the use of the
program might be dangerous indeed
No one would purchase the compiler. This is an
indication that conformance to the C standard is
not a sufficient condition for comercial success.
A popular compiler comes with strong warnings attached also:

NO WARRANTY

11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.

12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.

However, these warnings have not prevented it from becoming
widely used.
--
Just another C hacker.
Sep 20 '06 #27

P: n/a
Kenneth Brody <ke******@spamcop.netwrites:
William Hughes wrote:
>Old Wolf wrote:
[...]
Actually that is an interesting point. Supposing this compiler did
actually exist, who should be found to be responsible for the spam?

Assuming you answer 'the makers of RealC-32', it seems there is a
sliding scale between this case, and the case of a regular program
on a regular compiler accidentally formatting the harddrive due to UB.

Well the makers should be responsible for behaviour that
a reasonble man would not anticipate.

So if the makers put a big red notice on the front of every
box saying "Warning, if you compile any program that
invokes behavious undefinied by the C standard, this
compiler will create an executable that sends out spam",
the makers would probably be fine (although they would
not sell many compilers). Otherwise they should
be responsible for the spam because a resonable man would
not expect a simple programming error to result
in a spamming executable.

What if the warning said:

Warning! If you compile any program that invokes undefined
behavior, the results may be *ANYTHING*, including, but not
limited to, the melting of your CPU, demons flying out of
your nose, or the slaying of your first-born male child. We
are not responsible for the results of your use of undefined
behavior.

[...]
Then a user suing the compiler vendor for damages would not be able to
cite violation of the ISO C standard. The question of whether he'd be
able to cite anything else, or whether such a warning has any *legal*
significance, is well beyond the scope of this newsgroup.

--
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.
Sep 20 '06 #28

This discussion thread is closed

Replies have been disabled for this discussion.