Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Who owns the variable in my header file ?

Reply
Thread Tools

Re: Who owns the variable in my header file ?

 
 
Edward A. Falk
Guest
Posts: n/a
 
      12-18-2012
In article <(E-Mail Removed)>,
lipska the kat <(E-Mail Removed)> wrote:
>On 04/10/12 05:34, James Kuyper wrote:
>>
>> That's a bad assumption. One of the most common ways in which code with
>> undefined behavior actually behaves is to produce exactly the same
>> result that you incorrectly assume that it's required to produce. That's
>> because your assumptions happen to match decisions made by the
>> implementors of the version of C that you're testing with. Other
>> implementors of C are free to make different decisions, ones that are
>> incompatible with your incorrect assumptions.


Very well said.
>
>Er ... wow, OK, that is a bit of a head****


Get used to it.

From my quotes file:

What undefined means is:

undefined.
Do not rely on the results.
You have gone outside the domain of the function
You have broken the programming model of the C language.
Here there be dragons!
The implementors can do anything they want.
Be careful.
Use a different algorithm.
This is non-portable.
Don't do it.

They have a saying in computer science: "The source code is
the documentation." Don't believe it. The documentation is
the documentation and the source code is someone's best attempt
at meeting the contract specified in the documentation. Over
time, the source code will change, hopefully to better match
the documentation. If you find a case where the source code does
*not* do what the documentation says, file a bug and make a note
to yourself to never use that feature again because now you can't
trust it.

I've been doing this for a very long time. I still read the man
page for functions I use every day, just to confirm that I'm
calling them right and using the return value right.

Stick to the defined behavior in the spec, and you'll write code that
lasts. I run major programs on a daily basis that I wrote a decade ago
for a different operating system on a different architecture, with a
different byte order than I'm using today, and they still work fine.


>Do you mean to say that even if I test my program to destruction and as
>far as I can tell it's 'correct', that is it complies with requirements
>and behaves as expected it could still be incorrect when compiled with
>a different compiler ???


>Surely there is some 'base' implementation of C that is used to test
>compilers or is it a free for all ... to me this implies that there can
>be more than one 'correct' implementation of the C language, or several
>or many Cs in fact. Please remember I am a raw beginner at C although I
>find this whole discussion fascinating.


Stick to standard ansi C and you'll be fine. Avoid any features
from C89, C90, Cetc. unless you *really* need them. And trust
me, you don't.

>Given a program written in C, how does one determine that it is
>'correct' if complying with requirements and returning the same output
>from the same input is not enough.


Heh. Solve that one, and there's a PhD in it for you, at the very
least. Probably a parade too.

Just stick to standard C and read the man page for every function
you call, and you'll be fine.

Later on, you'll learn about tools such as code coverage
tools and memory monitors that will help, but that's relatively
advanced stuff.

--
-Ed Falk, http://www.velocityreviews.com/forums/(E-Mail Removed)
http://thespamdiaries.blogspot.com/
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      12-18-2012
(E-Mail Removed) (Edward A. Falk) writes:
[...]
> Stick to standard ansi C and you'll be fine. Avoid any features
> from C89, C90, Cetc. unless you *really* need them. And trust
> me, you don't.

[...]

What do you mean by "standard ansi C"? C89 was the original ANSI
C standard; C90 is the ISO standard that defines exactly the same
language.

Strictly speaking, ANSI has adopted the 2011 ISO C standard, which
supersedes and replaces C99, which supersedes and replaces C89/C90,
so "ANSI C" is now C2011. But that's not what most people mean by
"ANSI C" -- which is why I avoid the term in favor of specifying
the year of the standard I'm referring to.

(Microsoft's C compiler is the only major hosted implementation
I'm aware of that doesn't have reasonably decent support for at
least C99.)

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Edward A. Falk
Guest
Posts: n/a
 
      12-18-2012
In article <(E-Mail Removed) merica>,
Gordon Burditt <(E-Mail Removed)> wrote:
>
>It is very easy to write a program in C that deliberately crashes
>(here this means: calls abort()) under conditions which you
>might not test, for example:
> - Crashes only on Sunday.

...
> - Crashes only on Feb. 29.


For the record, every Sun computer crashed on Feb 29 1988 due
to a bug in the clock kernel driver.

There is a documented "phase of the moon" bug:

http://www.catb.org/jargon/html/P/ph...-the-moon.html

>
>And these situations you *SHOULD* test:
> - Crashes only on an input line of more than 10,000 characters.


Test this thoroughly. Bad actors WILL deliberately try to choke
your inputs like this. I caused a CERT advisory this way. (In
my defense, the guilty code was something I'd copied from another
related project.) I've spent many an hour auditing the source code
of standard system utilities and finding dozens of bugs, in an
attempt to close loopholes that had allowed crackers into our
site.

--
-Ed Falk, (E-Mail Removed)
http://thespamdiaries.blogspot.com/
 
Reply With Quote
 
Noob
Guest
Posts: n/a
 
      12-18-2012
Edward A. Falk wrote:

> I've been doing this for a very long time. I still read the man
> page for functions I use every day, just to confirm that I'm
> calling them right and using the return value right.


Case in point: memcpy vs memmove.

So many people "get it wrong" that Linus even suggested
memcpy should become an alias for memmove.

 
Reply With Quote
 
Edward A. Falk
Guest
Posts: n/a
 
      12-18-2012
In article <(E-Mail Removed)>,
Keith Thompson <(E-Mail Removed)> wrote:
>(E-Mail Removed) (Edward A. Falk) writes:
>[...]
>> Stick to standard ansi C and you'll be fine. Avoid any features
>> from C89, C90, Cetc. unless you *really* need them. And trust
>> me, you don't.

>[...]
>
>What do you mean by "standard ansi C"?


Ahh, you're right. C89 *was* the original "standard C",
wasn't it?

OK, anyway, I haven't used anything more modern than that because I
haven't needed it.

--
-Ed Falk, (E-Mail Removed)
http://thespamdiaries.blogspot.com/
 
Reply With Quote
 
Greg Martin
Guest
Posts: n/a
 
      12-18-2012
On 12-12-18 11:54 AM, Edward A. Falk wrote:
> In article <(E-Mail Removed) merica>,
> Gordon Burditt <(E-Mail Removed)> wrote:
>>
>> It is very easy to write a program in C that deliberately crashes
>> (here this means: calls abort()) under conditions which you
>> might not test, for example:
>> - Crashes only on Sunday.

> ...
>> - Crashes only on Feb. 29.

>
> For the record, every Sun computer crashed on Feb 29 1988 due
> to a bug in the clock kernel driver.
>
> There is a documented "phase of the moon" bug:
>
> http://www.catb.org/jargon/html/P/ph...-the-moon.html
>
>>
>> And these situations you *SHOULD* test:
>> - Crashes only on an input line of more than 10,000 characters.

>
> Test this thoroughly. Bad actors WILL deliberately try to choke
> your inputs like this. I caused a CERT advisory this way. (In
> my defense, the guilty code was something I'd copied from another
> related project.) I've spent many an hour auditing the source code
> of standard system utilities and finding dozens of bugs, in an
> attempt to close loopholes that had allowed crackers into our
> site.
>


In reading a number of books by and about crackers the thing that struck
me most is the patience that a top cracker will exhibit. Software
development can be a tedious affair but if you cut a corner they *will*
find it because the folks that excel at this don't seem bothered by
tedium. Once they find it they will tell others since that is part of
the culture. When I check my server logs they are full of probes for old
"exploits" which are easily defeated by keeping your software up to date
but you don't see the guys who discover the exploits because they are
careful, though they might be testing your software over a period of a
year before they get tired of the game ... or find the hole they're seeking.


 
Reply With Quote
 
Edward A. Falk
Guest
Posts: n/a
 
      12-19-2012
In article <gE4As.34347$(E-Mail Removed)>,
Greg Martin <(E-Mail Removed)> wrote:
>On 12-12-18 11:54 AM, Edward A. Falk wrote:
>>
>> [Why it's important to validate your inputs, especially looking
>> for buffer overflows]
>>

>
>In reading a number of books by and about crackers the thing that struck
>me most is the patience that a top cracker will exhibit. Software
>development can be a tedious affair but if you cut a corner they *will*
>find it because the folks that excel at this don't seem bothered by
>tedium. Once they find it they will tell others since that is part of
>the culture. When I check my server logs they are full of probes for old
>"exploits" which are easily defeated by keeping your software up to date
>but you don't see the guys who discover the exploits because they are
>careful, though they might be testing your software over a period of a
>year before they get tired of the game ... or find the hole they're seeking.


True story: The particular server I was auditing was vulnerable via
the WUFTP server (Motto: "Providing root access since 1994"). The
script kiddie who broke in left muddy footprints all over the system,
which were remarkably easy to follow. After he got in and had root
access, he spent an hour or so typing DOS commands before he gave up
and went away.

Lessons learned: keep your software up to date. Don't enable any more
services than you absolutely need.

Here's a trick I use sometimes: If I'm writing an app which I suspect
may be executed with root priveleges, but which doesn't really need them,
I deliberately drop root priveleges in the very first line of code
in my program, just to make sure some bug doesn't get exploited further
down the way.

And writing your own code securely isn't good enough. Years ago, it
was discovered that the X window system base library (libX) was copying
$DISPLAY to another location without checking its length. This meant
that ANY gui app that ran as root could be exploited by putting bad
code into $DISPLAY.

--
-Ed Falk, (E-Mail Removed)
http://thespamdiaries.blogspot.com/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Who owns the variable in my header file ? Edward A. Falk C Programming 5 10-11-2012 08:30 PM
Re: Who owns the variable in my header file ? James Kuyper C Programming 0 10-04-2012 12:43 PM
Re: Who owns the variable in my header file ? Ike Naar C Programming 0 10-03-2012 07:52 PM
Re: Who owns the variable in my header file ? Kaz Kylheku C Programming 0 10-03-2012 07:40 PM



Advertisments