secure integer library

Robert Seacord wrote:

The CERT/CC has released a beta version of a secure integer library for
the C Programming Language. The library is available for download from
the CERT/CC Secure Coding Initiative web page at:
http://www.cert.org/secure-coding/

The purpose of this library is to provide a collection of utility
functions that can assist software developers in writing C programs that
are free from common integer problems such as integer overflow, integer
truncation, and sign errors that are a common source of software
vulnerabilities.

Functions have been provided for all integer operations subject to
overflow such as addition, subtraction, multiplication, division, unary
negation, etc.) for int, long, long long, and size_t integers. The
following example illustrates how the library can be used to add two
signed long integer values:

long retsl, xsl, ysl;
xsl = LONG_MAX;
ysl = 0;
retsl = addsl(xsl,ysl);

For short integer types (char and short) it is necessary to truncate the
result of the addition using one of the safe conversion functions
provided, for example:

char retsc, xsc, ysc;
xsc = SCHAR_MAX;
ysc = 0;
retsc = si2sc(addsi(xsc, ysc));

For error handling, the secure integer library uses the mechanism for
Runtime-constraint handling defined by TR 24731 "Specification for
Safer, More Secure C Library Functions" available at:
http://www.open-std.org/jtc1/sc22/wg...docs/n1135.pdf

The implementation uses the high performance algorithms defined by Henry
S. Warren in the book "Hacker's Delight".

For more information on vulnerabilities and other problems resulting
from the incorrect use of integers in C and C++ please read Chapter 5 of
"Secure Coding in C and C++" which is available as a free download from
the CERT web site:

http://www.cert.org/books/secure-coding/moreinfo.html

Please address any defect reports, comments and suggestions concerning
the Secure Integer Library or CERT Secure Coding Initiative to me.
Thanks to Henry and to Juan Alvarado who coded the implementation.

Thanks,
rCs

This is very interesting thing. It gives the layout of a "secure" form
of performing the basic operations. It could be easily and much more
efficientely implemented with compiler support, what I will try to
implement in the next future.

I have already implemented within the framework of lcc-win32 an overflow
exception detection with compiler support, and this could be an
extension to that.

Another interesting feature is that this library uses the mechanism
proposed by the secure C library document to handle the exception, as
I proposed in this group some time ago. That mechanism could become
the standard way to signal errors within the C community. This would
be a welcome change from the complete ignoring of error handling and
error treatment within the language.

This attitude (that the standards comitee implicitely supports) is
designed to destroy all usages of C within modern software development.

Happily things are starting to move, obviously from outside the
standards comitee.

Aug 19 '06 #3

Robert Seacord wrote:

The purpose of this library is to provide a collection of utility
functions that can assist software developers in writing C programs that
are free from common integer problems such as integer overflow, integer
truncation, and sign errors that are a common source of software
vulnerabilities.

You want to help people write secure code by forcing to re-write

a = b + c;

to

a = add2siciasi(b, c); // or whatever your macros are... I stopped
laughing after looking at a few files

Right...

What about the cases where you WANT overflows to happen [or more
importantly don't care if they do]? e.g. emulating a cyclic rotation.

What about just teaching developers to use the right data types? I'd
say that's more important than teaching them to use your library.

Tom

Tom

Aug 19 '06 #4

Ark

Tom St Denis wrote:

Robert Seacord wrote:
>The purpose of this library is to provide a collection of utility
functions that can assist software developers in writing C programs that
are free from common integer problems such as integer overflow, integer
truncation, and sign errors that are a common source of software
vulnerabilities.

You want to help people write secure code by forcing to re-write

a = b + c;

to

a = add2siciasi(b, c); // or whatever your macros are... I stopped
laughing after looking at a few files

Right...

What about the cases where you WANT overflows to happen [or more
importantly don't care if they do]? e.g. emulating a cyclic rotation.

What about just teaching developers to use the right data types? I'd
say that's more important than teaching them to use your library.

Tom

Tom

Sorry Tom, your post is sheer nonsense.
0.
You are not forced to use it everywhere; if you do know what you are
doing, go ahead and do it.
1.
Everything has its uses, and I, as well as you, can easily see the
usefulness of this stuff.
2.
On efficiency: some architectures (e.g., ARM Architecture 5 and above)
support arithmetic with saturation in the instruction set, so the if the
functions are inlined, there may me no performance penalty.
3.
The reality of this world is that application domain experts (also) get
to write (embedded) production code. Those types naturally think of a +
as of a mathematical operation, not as a signedness-and-length-dependent
gobbledygook C made of it. For them, this library is indispensable.

Aug 19 '06 #5

Ark wrote:

Tom St Denis wrote:

>Robert Seacord wrote:

>>The purpose of this library is to provide a collection of utility
functions that can assist software developers in writing C programs that
are free from common integer problems such as integer overflow, integer
truncation, and sign errors that are a common source of software
vulnerabilities.

You want to help people write secure code by forcing to re-write

a = b + c;

to

a = add2siciasi(b, c); // or whatever your macros are... I stopped
laughing after looking at a few files

Right...

What about the cases where you WANT overflows to happen [or more
importantly don't care if they do]? e.g. emulating a cyclic rotation.

What about just teaching developers to use the right data types? I'd
say that's more important than teaching them to use your library.

Tom

Tom

Sorry Tom, your post is sheer nonsense.
0.
You are not forced to use it everywhere; if you do know what you are
doing, go ahead and do it.
1.
Everything has its uses, and I, as well as you, can easily see the
usefulness of this stuff.
2.
On efficiency: some architectures (e.g., ARM Architecture 5 and above)
support arithmetic with saturation in the instruction set, so the if the
functions are inlined, there may me no performance penalty.
3.
The reality of this world is that application domain experts (also) get
to write (embedded) production code. Those types naturally think of a +
as of a mathematical operation, not as a signedness-and-length-dependent
gobbledygook C made of it. For them, this library is indispensable.

All the problem he has disappear with a C compiler that supports
operator overloading.

Note that the pentiums (Intel architecture) support arithmetic with
saturation too, and they have a huge piece of the market.

Aug 19 '06 #6

Ark wrote:

Sorry Tom, your post is sheer nonsense.
0.
You are not forced to use it everywhere; if you do know what you are
doing, go ahead and do it.

But it's *secure* so clearly if I'm not using it then I'm insecure.
You think that's nonsense? Try working for a PHB.

1.
Everything has its uses, and I, as well as you, can easily see the
usefulness of this stuff.

I can't. Of course I know how to develop software in a portable
fashion.

2.
On efficiency: some architectures (e.g., ARM Architecture 5 and above)
support arithmetic with saturation in the instruction set, so the if the
functions are inlined, there may me no performance penalty.

For those specific applications a trivial macro set is all you need for
portable development. It's a very niche subset of problems though.

3.
The reality of this world is that application domain experts (also) get
to write (embedded) production code. Those types naturally think of a +
as of a mathematical operation, not as a signedness-and-length-dependent
gobbledygook C made of it. For them, this library is indispensable.

Yeah, see I disagree. The C standard may be confusing as fuck w.r.t.
data types but the platforms are not.

unsigned long a, b, c;
a = b + c;

On ANY platform you touch that's guaranteed to perform at least a
32-bit addition. Even though an unsigned long may be 47 bits, have 9
trap bits and 6 padding bits, the operation is still guaranteed to have
a numerical accuracy across different platforms and at least 32 bits of
precision amongst them.

[etc, etc].

Learning when to mask things off with an AND and how to load/store data
in a portable fashion should be Intro to C 101 material.

Tom

Aug 19 '06 #7

jacob navia wrote:

All the problem he has disappear with a C compiler that supports
operator overloading.

If you wanted operator overloading use fucking C++. My god is it that
hard? Why would you choose a language that doesn't have what you want
over one that does? Oh right, because you're a MORON [or joe-jobbing]

Note that the pentiums (Intel architecture) support arithmetic with
saturation too, and they have a huge piece of the market.

You won't make a lot of friends using them though, unless you use check
the cpu revision first.

Tom

Aug 19 '06 #8

jacob navia wrote:

Robert Seacord wrote:

>The CERT/CC has released a beta version of a secure integer
library for the C Programming Language. The library is available
for download from the CERT/CC Secure Coding Initiative web page at:
http://www.cert.org/secure-coding/

.... snip ...

>
This is very interesting thing. It gives the layout of a "secure"
form of performing the basic operations. It could be easily and
much more efficientely implemented with compiler support, what I
will try to implement in the next future.

I have already implemented within the framework of lcc-win32 an
overflow exception detection with compiler support, and this could
be an extension to that.

The C standard permits you to trap all integer overflows. You may
not trap any unsigned overflows. Since your systems operate solely
on the x86, implementation of overflow protection is extremely
simple. Arm the appropriate interrupt vector (I think it may be 0)
on startup, and follow each actual arithmetic operation with the
'into' instruction. This will only act if the overflow flag is
set.

You can enable/disable all this action simply by controlling that
interrupt vector. It it points to a 'reti' instruction all will be
ignored. This won't detect overflows within casts, etc.

Implementing this would be a service to the community. It requires
no source changes. Of course you have to be sure that other
non-standard extensions are not fouling up the system, which may be
a problem for you.

--
"The power of the Executive to cast a man into prison without
formulating any charge known to the law, and particularly to
deny him the judgement of his peers, is in the highest degree
odious and is the foundation of all totalitarian government
whether Nazi or Communist." -- W. Churchill, Nov 21, 1943

Aug 19 '06 #9

Tom St Denis wrote:

>

.... snip ...

>
What about the cases where you WANT overflows to happen [or more
importantly don't care if they do]? e.g. emulating a cyclic rotation.

There is no such thing. Once an integer overflow occurs the action
is undefined, and the program is invalid. Just because most
systems do ignore them and perform a 2's complement peculiar action
is no excuse.

--
"The power of the Executive to cast a man into prison without
formulating any charge known to the law, and particularly to
deny him the judgement of his peers, is in the highest degree
odious and is the foundation of all totalitarian government
whether Nazi or Communist." -- W. Churchill, Nov 21, 1943

Aug 19 '06 #10

CBFalconer wrote:

jacob navia wrote:

>>Robert Seacord wrote:

>>>The CERT/CC has released a beta version of a secure integer
library for the C Programming Language. The library is available
for download from the CERT/CC Secure Coding Initiative web page at:
http://www.cert.org/secure-coding/

... snip ...

>>This is very interesting thing. It gives the layout of a "secure"
form of performing the basic operations. It could be easily and
much more efficientely implemented with compiler support, what I
will try to implement in the next future.

I have already implemented within the framework of lcc-win32 an
overflow exception detection with compiler support, and this could
be an extension to that.

The C standard permits you to trap all integer overflows. You may
not trap any unsigned overflows. Since your systems operate solely
on the x86, implementation of overflow protection is extremely
simple. Arm the appropriate interrupt vector (I think it may be 0)
on startup, and follow each actual arithmetic operation with the
'into' instruction. This will only act if the overflow flag is
set.

You can enable/disable all this action simply by controlling that
interrupt vector. It it points to a 'reti' instruction all will be
ignored. This won't detect overflows within casts, etc.

Implementing this would be a service to the community. It requires
no source changes. Of course you have to be sure that other
non-standard extensions are not fouling up the system, which may be
a problem for you.

I just test the overflow flag after every operation that could make an
overflow. Unsigned numbers are not tested.

What was missing was what to do if an overflow is found since it is
not specified. With this secure library implementations I will just
call the current exception handler with an overflow message.

Aug 19 '06 #11

CBFalconer wrote:

There is no such thing. Once an integer overflow occurs the action
is undefined, and the program is invalid. Just because most
systems do ignore them and perform a 2's complement peculiar action
is no excuse.

You mean

unsigned x = 1UL << 31;

x = x + x;

That's going to cause the end of the earth as we know it?

Damn. Ok. Good to know.

Tom

Aug 19 '06 #12

Tom St Denis wrote:

You mean

unsigned x = 1UL << 31;

I meant unsigned long

Tom

Aug 19 '06 #13

Clark S. Cox III

Tom St Denis wrote:

CBFalconer wrote:
>There is no such thing. Once an integer overflow occurs the action
is undefined, and the program is invalid. Just because most
systems do ignore them and perform a 2's complement peculiar action
is no excuse.

You mean

unsigned x = 1UL << 31;

x = x + x;

That's going to cause the end of the earth as we know it?

Damn. Ok. Good to know.

No, simply put, that isn't integer overflow.
--
Clark S. Cox III
cl*******@gmail.com

Aug 19 '06 #14

Clark S. Cox III wrote:

Tom St Denis wrote:

>>CBFalconer wrote:

>>>There is no such thing. Once an integer overflow occurs the action
is undefined, and the program is invalid. Just because most
systems do ignore them and perform a 2's complement peculiar action
is no excuse.

You mean

unsigned x = 1UL << 31;

x = x + x;

That's going to cause the end of the earth as we know it?

Damn. Ok. Good to know.

No, simply put, that isn't integer overflow.

That is obvious. Besides, nobody is speaking about
overflow for unsigned numbers. Only signed overflow
is undefined behavior according to the standard.

But any improvement of C in the "more safety"
direction is too much for certain people apparently.

Any "argument" counts:

"... the end of the earth as we know it"

As if anybody caring to ensure the correctness of the software
was half mad or not a "C" programmer.

jacob

Aug 19 '06 #15

jacob navia <ja***@jacob.remcomp.frwrites:
[...]

But any improvement of C in the "more safety"
direction is too much for certain people apparently.

Any "argument" counts:

"... the end of the earth as we know it"

As if anybody caring to ensure the correctness of the software
was half mad or not a "C" programmer.

jacob, will you *please* stop making up this utter crap about people's
motivations?

Nobody other than you has said anything about "the end of the earth as
we know it", or anything similar.

Most of us here are not implementers. As such we have little or no
ability to control what language features are available to us. We
work with compilers that conform to the C standard as it actually
exists (usually C90 with some extensions, sometimes most of C99,
rarely all of C99). This newsgroup is a place for us to discuss
programming in the C language as it is defined by the standard(s) in
the real world.

If you want to discuss techniques for writing safer code *in standard
C*, this is the right place.

If you want to advocate changes to the standard, or extensions outside
the standard, take it somewhere else. (I've told you many times that
comp.std.c is the most appropriate newsgroup for advocating changes to
the standard; if you don't get a favorable reception there, that
doesn't make your ideas topical here.) And you've practically got
your own newsgroup, after all.

And if you want to accuse either the standards committee or C
programmers in general of not caring about safety, or of wanting to
destroy the C language or keep it stagnant, or whatever paranoid
fantasy you've come up with, please do us all a favor and keep it to
yourself.

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

Aug 19 '06 #16

On Sat, 19 Aug 2006 21:36:56 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

>Nobody other than you has said anything about "the end of the earth as
we know it", or anything similar.

Actually, Tom St Denis did, though you may have him killfiled and
Jacob chose to quote him in a totally nonstandard way.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

Aug 19 '06 #17

On Sat, 19 Aug 2006 20:48:40 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>
All the problem he has disappear with a C compiler that supports
operator overloading.

If I wanted a truck, I'd drive a truck. I don't transport cows in my
sportscar. Similarly if I wanted C++ I'd use it.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

Aug 19 '06 #18

Clark S. Cox III

jacob navia wrote:

Clark S. Cox III wrote:
>Tom St Denis wrote:

>>CBFalconer wrote:

There is no such thing. Once an integer overflow occurs the action
is undefined, and the program is invalid. Just because most
systems do ignore them and perform a 2's complement peculiar action
is no excuse.

You mean

unsigned x = 1UL << 31;

x = x + x;

That's going to cause the end of the earth as we know it?

Damn. Ok. Good to know.

No, simply put, that isn't integer overflow.

That is obvious. Besides, nobody is speaking about
overflow for unsigned numbers. Only signed overflow
is undefined behavior according to the standard.

Actually, this is exactly what Mr. St Denis was talking about. I was
simply pointing out that his example was unrelated to the actual
discussion taking place in the thread.

But any improvement of C in the "more safety"
direction is too much for certain people apparently.

Any "argument" counts:

"... the end of the earth as we know it"

As if anybody caring to ensure the correctness of the software
was half mad or not a "C" programmer.

Ensuring correctness is not worth it if it makes my already correct
programs slower.

Ensuring correctness is not worth it if it makes my legacy code
uncompilable.

I don't remember anyone claiming that "more safety" would cause "the end
of the Earth as we know it."

--
Clark S. Cox III
cl*******@gmail.com

Aug 20 '06 #19

Mark McIntyre <ma**********@spamcop.netwrites:

On Sat, 19 Aug 2006 21:36:56 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

>>Nobody other than you has said anything about "the end of the earth as
we know it", or anything similar.

Actually, Tom St Denis did, though you may have him killfiled and
Jacob chose to quote him in a totally nonstandard way.

Actually, I not only read Tom St Denis's use of the phrase "the end of
the earth as we know it", it was also quoted in jacob's article to
which I responded. I just missed it somehow. He used it
sarcastically, but I think I misinterpreted jacob's response to it.

Looking back at the thread, and particularly at jacob's article to
which I was responding, I'm no longer quite sure what point jacob was
trying to make.

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

Aug 20 '06 #20

Tom St Denis wrote:

CBFalconer wrote:

>There is no such thing. Once an integer overflow occurs the action
is undefined, and the program is invalid. Just because most
systems do ignore them and perform a 2's complement peculiar action
is no excuse.

You mean

unsigned x = 1UL << 31;

x = x + x;

That's going to cause the end of the earth as we know it?

Damn. Ok. Good to know.

That's not an integer overflow, that's an unsigned overflow, and
the action is specified by the standard. Change unsigned to int
(assuming 32 bit ints) and yes, then you have an integer overflow
and UB.

--
Chuck F (cb********@yahoo.com) (cb********@maineline.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.netUSE maineline address!

Aug 20 '06 #21

stdazi

Robert Seacord wrote:

The CERT/CC has released a beta version of a secure integer library for
the C Programming Language. The library is available for download from
the CERT/CC Secure Coding Initiative web page at:
http://www.cert.org/secure-coding/

The purpose of this library is to provide a collection of utility
functions that can assist software developers in writing C programs that
are free from common integer problems such as integer overflow, integer
truncation, and sign errors that are a common source of software
vulnerabilities.

Functions have been provided for all integer operations subject to
overflow such as addition, subtraction, multiplication, division, unary
negation, etc.) for int, long, long long, and size_t integers. The
following example illustrates how the library can be used to add two
signed long integer values:

long retsl, xsl, ysl;
xsl = LONG_MAX;
ysl = 0;
retsl = addsl(xsl,ysl);

For short integer types (char and short) it is necessary to truncate the
result of the addition using one of the safe conversion functions
provided, for example:

char retsc, xsc, ysc;
xsc = SCHAR_MAX;
ysc = 0;
retsc = si2sc(addsi(xsc, ysc));

For error handling, the secure integer library uses the mechanism for
Runtime-constraint handling defined by TR 24731 "Specification for
Safer, More Secure C Library Functions" available at:
http://www.open-std.org/jtc1/sc22/wg...docs/n1135.pdf

The implementation uses the high performance algorithms defined by Henry
S. Warren in the book "Hacker's Delight".

For more information on vulnerabilities and other problems resulting
from the incorrect use of integers in C and C++ please read Chapter 5 of
"Secure Coding in C and C++" which is available as a free download from
the CERT web site:

http://www.cert.org/books/secure-coding/moreinfo.html

Please address any defect reports, comments and suggestions concerning
the Secure Integer Library or CERT Secure Coding Initiative to me.
Thanks to Henry and to Juan Alvarado who coded the implementation.

Thanks,
rCs

I was always missing a functionality to detect integer overflows
(sometimes it's a pain when you realize the "wrong answer" is due to a
overflow), but I'd never really like to use the above implementation.

It stunts performance and (most importantly) coding time. I don't want
to think how ugly the code looks in a for loop manipulating many
integers. It's not that hard to put some "limits" in regions of code
you find prone to overflows - after some time, you get used to.

The best place for that kind of utility is IMO the compiler, and IIRC,
there is a patch for gcc too!

Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC

Work: 412-268-7608
FAX: 412-268-6989

Aug 20 '06 #22

rCs

Random response to some of the ideas I've seen expressed in this
thread.

First of all, when I talk about integers I talk about "unexpected"
behavior. We all know that unsigned integers are defined by the C
standard as modulo so by definition this is the correct behavior. In
practice, however, many programmers fail to code for modulo behavior
resulting in unsigned overflow, incorrect program behavior, and
software vulnerabilities.

Second, integer overflow is not the only problem. For example, the
following code will never overflow for most implementations:

char sc1, sc2, sc_result;

sc_result = sc1 + sc2;

Let's assume for example that signed char is 8 bits and int is 32 bits.
Because of integer promotions both sc1 and sc2 are promoted to signed
integers before this addition takes place. This means overflow is
impossible, but truncation is not. Simply providing an overflow
detection mechanism in this case is insufficient.

Third, I would also like to see range checking built into compilers.
There is of course, a great deal of overhead even here (I have heard
100%-500%). I think my favorite idea is to extend the specification
to allow for a new type of range checked integers, for example:

int i 25:100 = 35;

This is similar to the range clause in Ada and would in this example
declare an integer with a range of 25 to 100, initialized to 35. The
compiler would be required to make sure the range is not violated.

I don't think performance is an issue in this case because you won't
get the overhead unless you use the feature and in that case you are
only paying for what you get.

Error handling is more of a problem. How do you report a range error
given the lack of an error handling mechanism in C? My best solution
would be to implement the runtime constraint mechanism used in TR 24731
and the secure integer library that started this thread but I am open
to other ideas.

If you expect your existing compiler to provide integer range checking,
good luck! I know that gcc provides an -ftrapv flag that provides
overflow protection for a small list of signed integer operations.
Their implementation handles errors by calling abort(). As far as I
know, Visual Studio offers no overflow protection although they have
tried to tighten up their compiler warnings for integer truncation.

Fourth, I agree that integer overflow protection is not necessary
everywhere. Protecting each operation is sort of a sloppy approach to
limiting the ranges of values at input and making sure that all the
intermediate representations of integer values have sufficient
precision. However, this can be difficult to guarantee when you have
multiple integer inputs that are combined in a variety of ways. When
no such guarantees are possible, I recommend the use of this library
(or similar protections) for integer values that originate from
untrusted sources (e.g., users) and then are used as sizes, lengths,
loop counters, or indicies as the incorrect use of integers in these
cases most common results in exploitable vulnerabilities.

rCs

Aug 20 '06 #23

rCs a écrit :

Random response to some of the ideas I've seen expressed in this
thread.

First of all, when I talk about integers I talk about "unexpected"
behavior. We all know that unsigned integers are defined by the C
standard as modulo so by definition this is the correct behavior. In
practice, however, many programmers fail to code for modulo behavior
resulting in unsigned overflow, incorrect program behavior, and
software vulnerabilities.

Second, integer overflow is not the only problem. For example, the
following code will never overflow for most implementations:

char sc1, sc2, sc_result;

sc_result = sc1 + sc2;

Let's assume for example that signed char is 8 bits and int is 32 bits.
Because of integer promotions both sc1 and sc2 are promoted to signed
integers before this addition takes place. This means overflow is
impossible, but truncation is not. Simply providing an overflow
detection mechanism in this case is insufficient.

Good point, however it would be impossible to test for this at run time
since this "feature" is part of the expected behavior of
many programs

Third, I would also like to see range checking built into compilers.
There is of course, a great deal of overhead even here (I have heard
100%-500%). I think my favorite idea is to extend the specification
to allow for a new type of range checked integers, for example:

int i 25:100 = 35;

This is similar to the range clause in Ada and would in this example
declare an integer with a range of 25 to 100, initialized to 35. The
compiler would be required to make sure the range is not violated.

Interesting idea.

I don't think performance is an issue in this case because you won't
get the overhead unless you use the feature and in that case you are
only paying for what you get.

Exactly.

Error handling is more of a problem. How do you report a range error
given the lack of an error handling mechanism in C? My best solution
would be to implement the runtime constraint mechanism used in TR 24731
and the secure integer library that started this thread but I am open
to other ideas.

Yes, I proposed using TR 24731 error handling mechanism as a default
error handling mechanism for C in the comp.lang.c discussion group.
http://groups.google.fr/group/comp.s...5d0a124fe18c1c

Obviously that is an interesting idea since silence was the only answer.
Skarmander and Keith Thompson answered but none of the comitee guys
answered since obviously I have complained (and loudly) about gets()
being still in the standard...

If you expect your existing compiler to provide integer range checking,
good luck! I know that gcc provides an -ftrapv flag that provides
overflow protection for a small list of signed integer operations.
Their implementation handles errors by calling abort(). As far as I
know, Visual Studio offers no overflow protection although they have
tried to tighten up their compiler warnings for integer truncation.

Fourth, I agree that integer overflow protection is not necessary
everywhere. Protecting each operation is sort of a sloppy approach to
limiting the ranges of values at input and making sure that all the
intermediate representations of integer values have sufficient
precision. However, this can be difficult to guarantee when you have
multiple integer inputs that are combined in a variety of ways. When
no such guarantees are possible, I recommend the use of this library
(or similar protections) for integer values that originate from
untrusted sources (e.g., users) and then are used as sizes, lengths,
loop counters, or indicies as the incorrect use of integers in these
cases most common results in exploitable vulnerabilities.

rCs

Aug 20 '06 #24

"rCs" <rc*@cert.orgwrites:
[snip]

Second, integer overflow is not the only problem. For example, the
following code will never overflow for most implementations:

char sc1, sc2, sc_result;

sc_result = sc1 + sc2;

Let's assume for example that signed char is 8 bits and int is 32 bits.
Because of integer promotions both sc1 and sc2 are promoted to signed
integers before this addition takes place. This means overflow is
impossible, but truncation is not. Simply providing an overflow
detection mechanism in this case is insufficient.

[snip]

Truncation isn't the only possibility.

First, let's assume that int is bigger than char. If it isn't (which
requires CHAR_BIT 8), then some other odd things can happen; we'll
ignore those unlikely possibilities.

sc1 and sc2 are promoted (i.e., converted) to type int and added,
yielding a result of type int. So far, no overflow is possible. Then
the result is assigned to sc_result -- but first it must be converted
from int to char.

For an arithmetic operations on a signed integer type, overflow
invokes undefined behavior. For a *conversion* to a signed integer
type, where the target type cannot represent the value, either the
result is implementation-defined or an implementation-defined signal
is raised (the latter possibility was introduced in C99).

For signed integer overflow on both arithmetic operations and
conversions, the most common behavior is that the high-order bits are
discarded, but the standard allows for many other possibilities.

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

Aug 20 '06 #25

On Sun, 20 Aug 2006 19:15:22 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Skarmander and Keith Thompson answered but none of the comitee guys
answered since obviously I have complained (and loudly) about gets()
being still in the standard...

The part from "since" onwards is unnecessary, insulting and
gratuitous, and explains exactly why people killfile you. If you want
to be listened to, stop making defamatory remarks.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

Aug 20 '06 #26

jacob navia <ja***@jacob.remcomp.frwrites:
[...]

Obviously that is an interesting idea since silence was the only answer.
Skarmander and Keith Thompson answered but none of the comitee guys
answered since obviously I have complained (and loudly) about gets()
being still in the standard...

I've also complained about gets() being in the standard, and I get
responses from committee members all the time.

jacob, it seems to me that you are *really bad* at guessing other
people's motivations. That's ok (not everyone can be good at
everything), but I suggest that you stop trying to do so, at least in
public, until you figure out how to do it right. It would greatly
improve your personal signal-to-noise ratio, and would likely cause
people to pay more serious attention to your ideas.

I admit I'm being a bit sarcastic here, but this is also intended as
serious advice.

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

Aug 20 '06 #27

Mark McIntyre a écrit :

On Sun, 20 Aug 2006 19:15:22 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>>Skarmander and Keith Thompson answered but none of the comitee guys
answered since obviously I have complained (and loudly) about gets()
being still in the standard...

The part from "since" onwards is unnecessary, insulting and
gratuitous, and explains exactly why people killfile you. If you want
to be listened to, stop making defamatory remarks.

Mr Gwyn, that is related to the people in the comitee
answered AT LENGTH defending gets().

You can read that thread in Google:
Thread name: Why does rewind() ignore errors?
Thread author: Keith Thompson
Date: May 26th 2006 21:34

There you will se Mr Gwyn defending gets() and treating people that
wanted that function away from the standard as "fanatics".

This was done under the thunderous SILENCE of the other comitee members.

NONE of them cared to express a different view.

I am not insulting anybody, neither did I treat them as "fanatics"
as they did to me.

jacob

Aug 20 '06 #28

Keith Thompson a écrit :

jacob navia <ja***@jacob.remcomp.frwrites:
[...]

>>Obviously that is an interesting idea since silence was the only answer.
Skarmander and Keith Thompson answered but none of the comitee guys
answered since obviously I have complained (and loudly) about gets()
being still in the standard...

I've also complained about gets() being in the standard, and I get
responses from committee members all the time.

Yes, all of them defending gets().

Maybe I am exaggerating. I hope so actually that it is just an
oversight, but really, after that discussion about gets() there is
nothing that can be done there.

The next standard is not even "in the works", and language evolution
is completely at a standstill, because, (as they have often repeated)
their job is to leave the language as it is without any change
so that legacy software doesn't get disturbed and C can die a
quite death without even a whisper.

C++ is where all development is done. The language is relatively
new, and people there accept that a language must be improved
by the comitee, that in C++ has a very positive function.

Contrast that with the C situation where getting rid of a bug
like gets() implies insults from the comitee representatives
like "fanatics".

Nothing is done, no new directions, no improvements and proposal like
getting rid of trigraphs/gets()/asctime()/ provoke only answers
like "nothing will be done".

But maybe there are people in the comitee that have another opinion,
they just do not participate to any discussion.

I spoke with the French standards comitee and they would maybe care to
review my suggestions AFTER I spend 10 000 euros in costs...

So I am stuck and neither comp.lang.c nor comp.std.c discussions will
change anything.

jacob

Aug 20 '06 #29

jacob navia <ja***@jacob.remcomp.frwrites:
[...]

The next standard is not even "in the works", and language evolution
is completely at a standstill, because, (as they have often repeated)
their job is to leave the language as it is without any change
so that legacy software doesn't get disturbed and C can die a
quite death without even a whisper.

You see, this is exactly what I meant when I said that you are *really
bad* at guessing other people's motivations.

I don't believe that *anybody* who has participated in these
discussions wants C to "die a quiet death". That's just your
interpretation, and it's absolutely wrong. I've spent far too much
time trying to help you understand that, but apparently you're
unwilling to listen.

[...]

So I am stuck and neither comp.lang.c nor comp.std.c discussions will
change anything.

So do us all a favor and stop posting here.

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

Aug 20 '06 #30

Keith Thompson a écrit :

jacob navia <ja***@jacob.remcomp.frwrites:
[...]

>>The next standard is not even "in the works", and language evolution
is completely at a standstill, because, (as they have often repeated)
their job is to leave the language as it is without any change
so that legacy software doesn't get disturbed and C can die a
quite death without even a whisper.

You see, this is exactly what I meant when I said that you are *really
bad* at guessing other people's motivations.

I don't believe that *anybody* who has participated in these
discussions wants C to "die a quiet death". That's just your
interpretation, and it's absolutely wrong. I've spent far too much
time trying to help you understand that, but apparently you're
unwilling to listen.

Please tell me then one example of a comitee member
that cares about error handling in the C library specification
and wants to put gets() in the obsolescent part of the standard.

Please tell me a single proposal done by the comitee that
proposes a solution to a problem in the language.

Contrary to the C++ comitee where they give new directions to
the language and library, the C comitee doesn't propose a single
thing.

There are several "technical reports" but it is not at all clear
how binding they are.

[...]

>>So I am stuck and neither comp.lang.c nor comp.std.c discussions will
change anything.

So do us all a favor and stop posting here.

Yes, you and many people here would like that I stop.

You will win eventually. I am very tired, and have been sustaining
with my own personal budget and my own time a free C implementation
since something like 10 years.

Aug 20 '06 #31

jacob navia <ja***@jacob.remcomp.frwrites:

Keith Thompson a écrit :

[...]

>I don't believe that *anybody* who has participated in these
discussions wants C to "die a quiet death". That's just your
interpretation, and it's absolutely wrong. I've spent far too much
time trying to help you understand that, but apparently you're
unwilling to listen.

Please tell me then one example of a comitee member
that cares about error handling in the C library specification
and wants to put gets() in the obsolescent part of the standard.

Please tell me a single proposal done by the comitee that
proposes a solution to a problem in the language.

Contrary to the C++ comitee where they give new directions to
the language and library, the C comitee doesn't propose a single
thing.

There are several "technical reports" but it is not at all clear
how binding they are.

That's not what I'm talking about. What I'm talking about is your
ridiculous assertion that certain people want C to "die a quiet
death". They don't.

You probably have some good points to make about safety. Your
combative attitude is what causes people to ignore you. Please think
about that.

>>>So I am stuck and neither comp.lang.c nor comp.std.c discussions will
change anything.
So do us all a favor and stop posting here.

Yes, you and many people here would like that I stop.

You will win eventually. I am very tired, and have been sustaining
with my own personal budget and my own time a free C implementation
since something like 10 years.

Good for you. I have no complaints about the fact that you're
maintaining a free C implementation. (It happens to be of no use to
me, because I don't do win32 programming, but that doesn't mean it's
not a wonderful thing for those who can use it.) My only complaints
are about what you post here.

I don't *really* want you to stop posting. I would like you to post
*constructively*, without insulting people who merely disagree with
you. But I'm just about ready to give up (yet again) on making you
understand that.

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

Aug 20 '06 #32

jacob navia wrote:

rCs a écrit :

.... snip ...

>
>Error handling is more of a problem. How do you report a range
error given the lack of an error handling mechanism in C? My
best solution would be to implement the runtime constraint
mechanism used in TR 24731 and the secure integer library that
started this thread but I am open to other ideas.

Yes, I proposed using TR 24731 error handling mechanism as a
default error handling mechanism for C in the comp.lang.c
discussion group.
http://groups.google.fr/group/comp.s...5d0a124fe18c1c

Obviously that is an interesting idea since silence was the only
answer. Skarmander and Keith Thompson answered but none of the
comitee guys answered since obviously I have complained (and
loudly) about gets() being still in the standard...

You are one of the few people who have total control over some
compiler system. This should be your opportunity to do something
important. I already advised you how to insert overflow checking
in x86 object code (which you may well have already known). If you
create a system that does this, and simultaneously STRICTLY ADHERES
to the C standard, be it C90, C95, or C99, you will have done the
community a service. To do all this you have to have a switch,
preferably on by default, which bans all extensions.

Even if such a compiler system is limited to Windows use, it will
be used fairly heavily to expose coding faults. It need not be the
fastest, but it does need to me the most accurate. This could
start by properly detecting all integer overflows, and expand
later.

For example, it is possible (at great run time overhead) to make
all pointers indirect and thus totally control pointer validity.
This might be a future direction for a supersafe validation
system. I don't recommend it as a first effort.

Consider it.

--
Chuck F (cb********@yahoo.com) (cb********@maineline.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.netUSE maineline address!

Aug 20 '06 #33

Ed Jensen

jacob navia <ja***@jacob.remcomp.frwrote:

Yes, you and many people here would like that I stop.

You will win eventually. I am very tired, and have been sustaining
with my own personal budget and my own time a free C implementation
since something like 10 years.

Jacob, I enjoy reading your comments here, and agree with many of
them.

Aug 21 '06 #34

jacob navia wrote:

>

.... snip ...

>
You will win eventually. I am very tired, and have been sustaining
with my own personal budget and my own time a free C implementation
since something like 10 years.

IIRC you withdrew the compiler from the 'free source'
classification several years ago.

--
Chuck F (cb********@yahoo.com) (cb********@maineline.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.netUSE maineline address!

Aug 21 '06 #35

CBFalconer <cb********@yahoo.comwrites:

jacob navia wrote:
>>
... snip ...
>>
You will win eventually. I am very tired, and have been sustaining
with my own personal budget and my own time a free C implementation
since something like 10 years.

IIRC you withdrew the compiler from the 'free source'
classification several years ago.

To be fair, he didn't say it's free source, merely that it's free.

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

Aug 21 '06 #36

On Sun, 20 Aug 2006 23:36:56 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Mark McIntyre a écrit :
>On Sun, 20 Aug 2006 19:15:22 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>>>Skarmander and Keith Thompson answered but none of the comitee guys
answered since obviously I have complained (and loudly) about gets()
being still in the standard...

The part from "since" onwards is unnecessary, insulting and
gratuitous, and explains exactly why people killfile you. If you want
to be listened to, stop making defamatory remarks.

There you will se Mr Gwyn defending gets() and treating people that
wanted that function away from the standard as "fanatics".

*shrug*. There are arguments for and against gets(). Personally I find
the simplest solution is just not to use it. I would consider it
'fanatical' to rant on and on about it though.

>This was done under the thunderous SILENCE of the other comitee members.

NONE of them cared to express a different view.

Or perhaps all of them have killfiled you due to your constant
rudeness.

>I am not insulting anybody, neither did I treat them as "fanatics"
as they did to me.

I disagree, you frequently insult people, you show blatant disregard
for the customs and rules of the groups, and you treat many posters as
fanatics.

And in what way does /any/ of the above make your original remark less
defamatory and quite probably actionable? Get a grip on yourself.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

Aug 21 '06 #37

Herbert Rosenau

On Sun, 20 Aug 2006 22:09:48 UTC, jacob navia <ja***@jacob.remcomp.fr>
wrote:

>
Please tell me then one example of a comitee member
that cares about error handling in the C library specification
and wants to put gets() in the obsolescent part of the standard.

No need for as jacob naiva has already proven that he is a twit only.

Please tell me a single proposal done by the comitee that
proposes a solution to a problem in the language.

The comitee does what is needed on C, not what a twit means tha C
should support.

Contrary to the C++ comitee where they give new directions to
the language and library, the C comitee doesn't propose a single
thing.

It is completely irrelevant what a twit things.

There are several "technical reports" but it is not at all clear
how binding they are.

It is completely irrelevant what a twit things.

>
[...]

>So I am stuck and neither comp.lang.c nor comp.std.c discussions will
change anything.

So do us all a favor and stop posting here.

Yes, you and many people here would like that I stop.

Anybody will profit from you leaving NOT in this group.

You will win eventually. I am very tired, and have been sustaining
with my own personal budget and my own time a free C implementation
since something like 10 years.

Noways. As you have proven yourself you has a compiler that has
nothing to do with C but with a langues that looks partlti as C but is
definitely NOT C and not a bit compatible with the rest of the world.
It is not even compatible to any other compiler on windows.

STOP spamming for your crap here.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

Aug 22 '06 #38

Walter Roberson

In article <wm***************************@JUPITER1.PC-ROSENAU.DE>,
Herbert Rosenau <os****@pc-rosenau.dewrote:

>No need for as jacob naiva has already proven that he is a twit only.

Herbert, in my opinion, we would be better off without personal
insults of that sort. This newsgroup has disagreements enough
as it is without needing to get into ad hominem attacks. If you
must say something, then attack the ideas (through logic), not the person.
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)

Aug 22 '06 #39

Robert Seacord

MrDev (if that's your real name ;^),

Non-Windows version?

the code was designed to be portable, so it should work on non-windows
platforms.

i'll make sure we test it on Linux and MacOS prior to the final release.

rCs

Aug 22 '06 #40