A very interesting book

[jacob navia]

Buffer overflows are a fact of life, and, more specifically, a fact of
C.

All is not lost however. In the book

"Value Range Analysis of C programs" Axel Simon tries to establish a
theoretical framework for analyzing C programs. In contrast to other
books where the actual technical difficulties are "abstracted away",
this books tries to analyze real C programs taking into account
pointers, stack frames, etc.

It has just arrived today, I was waiting for it since several weeks.

http://www.di.ens.fr/~simona/book.html
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Ian Collins]

jacob navia wrote:

CBFalconer wrote:

>Friedrich wrote:
... snip ...

>>Well some arguments here a more than strange. Some wrote every
language is equally unsafe because there might be a buffer
overrun. Howerver AFAIKT I just remember one recent problem with
buffer overruns in a certain Interpreter (written in C). I can
not remember having read about it let's say in Ocaml, Haskell or
even FreePascal. I can not see how one can deny that not doing
bounds checking can be safer than the other way. I can also not
see why the standard shouldn't be checking and just on occasion
you have something like
#pragma unsafe or the like to play your "nasty" tricks.

C can't have run-time checking without horrendous loss of
efficiency (basically it would require interpretation) because of
the unrestricted use of pointers.

This is plainly not true. Each access to an array would
have two reads from memory + two integers comparisons
to do. Progress in hardware make such tests completely
transparent. And nobody is saying they should be anything
more than optional.

I'd be interested in seeing an efficient access checker implemented at
compile time.

On the platform I use where the debugger does the checking (Solaris) the
impact can be truly painful. Every memory access is replaced at runtime
with a function call. I guess the function called has to scan
allocation tables for the address. If the compiler could do this, one
could select types of accesses to be checked.

--
Ian Collins.

[Ian Collins]

Keith Thompson wrote:

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

>Keith Thompson <ks***@mib.orgwrote:

>>Richard Heathfield <rj*@see.sig.invalidwrites:
If you want Ada, you know where to find it.
Ada is as powerful as C. It doesn't forbid unsafe actions, it merely
requires you to specify them explicitly in most cases. For example,
to interpret an integer as a pointer (something C allows with a simple
cast), you have to instantiate Unchecked_Conversion and then call the
instance. (Strictly speaking, the C cast performs a type conversion,
not a reinterpretation, but it's implemented as a reinterpretation in
every implementation I've seen.)

In other words, Ada requires a special construct to be applied to
interpret an integer as a pointer; C, by contrast, requires a special
construct to be applied to interpret an integer as a pointer. Apart from
the size of the construct, I see no difference.

The difference is that the "special construct" in C, a cast doesn't
stand out. It's the same construct used to for perfectly safe type
conversions, such as a conversion from int to long.

Which was two of the reasons C++ added "new style" casts. Maybe C
should follow?

--
Ian Collins.

[Anand Hariharan]

On Fri, 25 Jul 2008 03:06:36 -0400, CBFalconer wrote:

There is no destinction between
a pointer to a char, and a pointer to an array of 10,000 chars.

Are they not different types?

In addition malloced storage is not distinguished in any way
(except some usage aspects) from any other storage.

Does not 'free' require a pointer returned by malloc/calloc/realloc? Or
do you consider this an usage aspect?

[CBFalconer]

Anand Hariharan wrote:

CBFalconer wrote:

>There is no destinction between a pointer to a char, and a
pointer to an array of 10,000 chars.

Are they not different types?

Not when passed on to another function, etc.

>

>In addition malloced storage is not distinguished in any way
(except some usage aspects) from any other storage.

Does not 'free' require a pointer returned by malloc/calloc/realloc?
Or do you consider this an usage aspect?

Yes.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Keith Thompson]

Ian Collins <ia******@hotmail.comwrites:

jacob navia wrote:

[...]

>This is plainly not true. Each access to an array would
have two reads from memory + two integers comparisons
to do. Progress in hardware make such tests completely
transparent. And nobody is saying they should be anything
more than optional.

I'd be interested in seeing an efficient access checker implemented at
compile time.

On the platform I use where the debugger does the checking (Solaris) the
impact can be truly painful. Every memory access is replaced at runtime
with a function call. I guess the function called has to scan
allocation tables for the address. If the compiler could do this, one
could select types of accesses to be checked.

If the compiler could do this, it could optimize away a great many of
the checks. For example, this:

int arr[10];
int i;
for (i = 0; i < 10; i ++) {
arr[i] = i;
}

wouldn't require any runtime checks at all.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Anand Hariharan <zn********************@tznvy.pbzwrites:

On Fri, 25 Jul 2008 03:06:36 -0400, CBFalconer wrote:

>There is no destinction between
a pointer to a char, and a pointer to an array of 10,000 chars.

Are they not different types?

Yes, they are. The point, I think, is that given

char *ptr;

you can't tell (unless you keep track it yourself *very* carefully)
whether it points to a single object of type char, or to the first
element of an array of 10,000 chars.

>In addition malloced storage is not distinguished in any way
(except some usage aspects) from any other storage.

Does not 'free' require a pointer returned by malloc/calloc/realloc? Or
do you consider this an usage aspect?

Yes, it requires such a pointer, but the requirement isn't enforce;
you just get undefined behavior if you pass it something else (unless
it's a null pointer). Given a pointer value, there's no way to
determine at runtime whether it points to an object allocated via
malloc(), to a local variable, or to something else.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Anand Hariharan]

On Fri, 25 Jul 2008 19:26:05 -0700, Keith Thompson wrote:

Anand Hariharan <zn********************@tznvy.pbzwrites:

>On Fri, 25 Jul 2008 03:06:36 -0400, CBFalconer wrote:

>>There is no destinction between
a pointer to a char, and a pointer to an array of 10,000 chars.

Are they not different types?

Yes, they are. The point, I think, is that given

char *ptr;

you can't tell (unless you keep track it yourself *very* carefully)
whether it points to a single object of type char, or to the first
element of an array of 10,000 chars.

Methinks one can distinguish between

char *PointerToAChar;
char (* PointerToAnArrayOf10000Chars)[10000];

[vippstar]

On Jul 26, 10:05 am, Anand Hariharan
<[e-mail]:

On Fri, 25 Jul 2008 19:26:05 -0700, Keith Thompson wrote:

Anand Hariharan <[e-mail]:

On Fri, 25 Jul 2008 03:06:36 -0400, CBFalconer wrote:
There is no destinction between
a pointer to a char, and a pointer to an array of 10,000 chars.

Are they not different types?

Yes, they are. The point, I think, is that given

char *ptr;

you can't tell (unless you keep track it yourself *very* carefully)
whether it points to a single object of type char, or to the first
element of an array of 10,000 chars.

Methinks one can distinguish between

char *PointerToAChar;
char (* PointerToAnArrayOf10000Chars)[10000];

Yes, they can. The point, I think, is that gives

char *ptr;

you can't tell (unless you keep track it yourself *very* carefully)
whether it points to a single object of type char, or to the first
element of an array of 10,000 chars.

[Richard Heathfield]

CBFalconer said:

Anand Hariharan wrote:

>CBFalconer wrote:

>>There is no destinction between a pointer to a char, and a
pointer to an array of 10,000 chars.

Are they not different types?

Not when passed on to another function, etc.

Wrong.

Whether or not these values are being passed to a function, the pointer to
char has type char *, whereas the pointer to an array of 10000 char has
type char (*)[10000]. These are different types.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Greg Comeau]

In article <g6**********@aioe.org>,
Anand Hariharan <ma********************@gmail.comwrote:

>On Fri, 25 Jul 2008 03:06:36 -0400, CBFalconer wrote:

>There is no destinction between
a pointer to a char, and a pointer to an array of 10,000 chars.

Are they not different types?

Indeed they are. However, I think he meant this context:

char c;
char a[100000];

char *p;
p = &c;
p = a;
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[vippstar]

On Jul 26, 5:45 pm, [e-mail] (Greg Comeau) wrote:

In article <g6dvi1$[e-mail]>,
Anand Hariharan <[e-mail]:

On Fri, 25 Jul 2008 03:06:36 -0400, CBFalconer wrote:

There is no destinction between
a pointer to a char, and a pointer to an array of 10,000 chars.

Are they not different types?

Indeed they are. However, I think he meant this context:

char c;
char a[100000];

Note that this particular example needs not to be compiled by *ANY*
implementation; It exceeds environmental limits.
C89 says implementations must accept at least one object 32767 bytes
long. C99 increases this to 65535.

char *p;
p = &c;
p = a;

[Greg Comeau]

In article <b0**********************************@m73g2000hsh. googlegroups.com>,
<vi******@gmail.comwrote:

>On Jul 26, 5:45 pm, [e-mail] (Greg Comeau) wrote:

>In article <g6dvi1$[e-mail]>,
Anand Hariharan <[e-mail]:

>On Fri, 25 Jul 2008 03:06:36 -0400, CBFalconer wrote:
There is no destinction between
a pointer to a char, and a pointer to an array of 10,000 chars.
Are they not different types?

Indeed they are. However, I think he meant this context:

char c;
char a[100000];

Note that this particular example needs not to be compiled by *ANY*
implementation; It exceeds environmental limits.
C89 says implementations must accept at least one object 32767 bytes
long. C99 increases this to 65535.

Indeed, so let's change "10,100 chars" to "1000" so as to not
let the point wander.

Of course too the "pointer to an array of 1000 chars" is
more slang, since as other have pointed out that's more
formmally char (*)[1000] and not char *, but that was not C's point
either.

>char *p;
p = &c;
p = a;

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[CBFalconer]

Richard Heathfield wrote:

CBFalconer said:

>Anand Hariharan wrote:

>>CBFalconer wrote:

There is no destinction between a pointer to a char, and a
pointer to an array of 10,000 chars.

Are they not different types?

Not when passed on to another function, etc.

Wrong.

Whether or not these values are being passed to a function, the
pointer to char has type char *, whereas the pointer to an array
of 10000 char has type char (*)[10000]. These are different types.

While I can't find the appropriate quote on a quick standard
search, I distinctly recall that an array is passed as a pointer to
the initial component of that array. That totally eliminates the
10000 in the above example, and is one reason that range checking
is not practicable in C.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Richard Heathfield]

CBFalconer said:

Richard Heathfield wrote:

>CBFalconer said:

>>Anand Hariharan wrote:
CBFalconer wrote:

There is no destinction between a pointer to a char, and a
pointer to an array of 10,000 chars.

Are they not different types?

Not when passed on to another function, etc.

Wrong.

Whether or not these values are being passed to a function, the
pointer to char has type char *, whereas the pointer to an array
of 10000 char has type char (*)[10000]. These are different types.

While I can't find the appropriate quote on a quick standard
search, I distinctly recall that an array is passed as a pointer to
the initial component of that array.

There is a difference between "array" and "pointer to array".

That totally eliminates the 10000 in the above example,

No, it doesn't. The type char (*)[10000] is not an array, but a pointer to
an array of 10000 char.

and is one reason that range checking is not practicable in C.

That makes no sense to me. Range checking in C is not only practicable but
commonplace. And if you actually mean bounds checking, some
implementations provide that, too. Therefore, it *is* practicable.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Harald van =?UTF-8?b?RMSzaw==?=]

On Sat, 26 Jul 2008 10:04:36 -0400, CBFalconer wrote:

Richard Heathfield wrote:

>CBFalconer said:

>>Anand Hariharan wrote:
CBFalconer wrote:

There is no destinction between a pointer to a char, and a pointer
to an array of 10,000 chars.

Are they not different types?

Not when passed on to another function, etc.

Wrong.

Whether or not these values are being passed to a function, the pointer
to char has type char *, whereas the pointer to an array of 10000 char
has type char (*)[10000]. These are different types.

While I can't find the appropriate quote on a quick standard search, I
distinctly recall that an array is passed as a pointer to the initial
component of that array. That totally eliminates the 10000 in the above
example, and is one reason that range checking is not practicable in C.

extern int foo(char (*)[10000]);
extern int bar(char *);

char buf[10000];

void f(void) {
foo(&buf); /* the passed argument has type pointer to array of 10000
chars. the array size is not ignored. */
bar(buf); /* the passed argument has type pointer to char. the array
size is ignored. */
}

When you said "pointer to an array of 10,000 chars", you probably meant
"pointer to the initial element of an array of 10,000 chars". When you
call bar, you don't have a parameter of type pointer to array.

[Greg Comeau]

In article <48***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:

>Richard Heathfield wrote:

>CBFalconer said:

>>Anand Hariharan wrote:
CBFalconer wrote:

There is no destinction between a pointer to a char, and a
pointer to an array of 10,000 chars.

Are they not different types?

Not when passed on to another function, etc.

Wrong.

Whether or not these values are being passed to a function, the
pointer to char has type char *, whereas the pointer to an array
of 10000 char has type char (*)[10000]. These are different types.

While I can't find the appropriate quote on a quick standard
search, I distinctly recall that an array is passed as a pointer to
the initial component of that array. That totally eliminates the
10000 in the above example, and is one reason that range checking
is not practicable in C.

Indeed, however, you slang'd because

pointer to the initial component of that array
is not the same as
pointer to ....[implied: the whole].... array

which threw off many to what your original point was :)
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Richard]

Richard Heathfield <rj*@see.sig.invalidwrites:

CBFalconer said:

>Richard Heathfield wrote:

>>CBFalconer said:
Anand Hariharan wrote:
CBFalconer wrote:
>
>There is no destinction between a pointer to a char, and a
>pointer to an array of 10,000 chars.
>
Are they not different types?

Not when passed on to another function, etc.

Wrong.

Whether or not these values are being passed to a function, the
pointer to char has type char *, whereas the pointer to an array
of 10000 char has type char (*)[10000]. These are different types.

While I can't find the appropriate quote on a quick standard
search, I distinctly recall that an array is passed as a pointer to
the initial component of that array.

There is a difference between "array" and "pointer to array".

I find it astonishing that two of the most pedantic regs in c.l.c can be
arguing about this.

It shows one thing : some people here giving advice appear not to know
the basics of the subject in which they are self professed "experts".

>That totally eliminates the 10000 in the above example,

No, it doesn't. The type char (*)[10000] is not an array, but a pointer to
an array of 10000 char.

>and is one reason that range checking is not practicable in C.

That makes no sense to me. Range checking in C is not only practicable but
commonplace. And if you actually mean bounds checking, some
implementations provide that, too. Therefore, it *is* practicable.

--

[Serve Lau]

"jacob navia" <ja***@nospam.comschreef in bericht
news:g6**********@aioe.org...

Buffer overflows are a fact of life, and, more specifically, a fact of
C.

All is not lost however. In the book

"Value Range Analysis of C programs" Axel Simon tries to establish a
theoretical framework for analyzing C programs. In contrast to other
books where the actual technical difficulties are "abstracted away",
this books tries to analyze real C programs taking into account
pointers, stack frames, etc.

In my experience the whole "buffer overflows are a huge problem with C" is
heavily overrated.

1. I rarely come across bugs in the field that have to do with buffer
overflows. Yes, sometimes it happens during development that you acces an
invalid pointer. But you do a test run and see that the system doesnt work
properly anymore and you fix it.

2. Having a "safe" language is not the real solution. Lets take java, it
does bounds checking. What does it do when it sees a buffer overflow? It
throws an exception and you can bet the program is not designed to recover
from this kind of error. Almost the same result as in C, the program doesnt
work correctly. The only difference is that you get a neat error message
saying which line in which file displayed the bug. But at the end of the day
the bug is still there.

But I agree, it would be great if some software could actually be created
that runs together with your unit tests and checks for buffer overflows
provided it can be turned off after testing.
Another thing, I see here that people have the opinion that you should "just
always hire really good programmers". But how does a programmer get "really
good"? Right, by making mistakes and realize the importance of his mistakes.
After a big money costing buffer overflow mistake you think twice to ignore
them in the future, but when you're a student and your little student
database program you tend to care way less :)

[Keith Thompson]

vi******@gmail.com writes:

On Jul 26, 10:05 am, Anand Hariharan
<[e-mail]:

>On Fri, 25 Jul 2008 19:26:05 -0700, Keith Thompson wrote:

Anand Hariharan <[e-mail]:
On Fri, 25 Jul 2008 03:06:36 -0400, CBFalconer wrote:
There is no destinction between
a pointer to a char, and a pointer to an array of 10,000 chars.

>Are they not different types?

Yes, they are. The point, I think, is that given

char *ptr;

you can't tell (unless you keep track it yourself *very* carefully)
whether it points to a single object of type char, or to the first
element of an array of 10,000 chars.

Methinks one can distinguish between

char *PointerToAChar;
char (* PointerToAnArrayOf10000Chars)[10000];

Yes, they can. The point, I think, is that gives

char *ptr;

you can't tell (unless you keep track it yourself *very* carefully)
whether it points to a single object of type char, or to the first
element of an array of 10,000 chars.

Well said.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Anand Hariharan]

On Sat, 26 Jul 2008 20:04:05 +0200, Serve Lau wrote:

"jacob navia" <ja***@nospam.comschreef in bericht
news:g6**********@aioe.org...

>Buffer overflows are a fact of life, and, more specifically, a fact of
C.

All is not lost however. In the book

"Value Range Analysis of C programs" Axel Simon tries to establish a
theoretical framework for analyzing C programs. In contrast to other
books where the actual technical difficulties are "abstracted away",
this books tries to analyze real C programs taking into account
pointers, stack frames, etc.

In my experience the whole "buffer overflows are a huge problem with C" is
heavily overrated.

With due respect, it just means that your experience has been restricted
to those implementations of C that get you to think so.

1. I rarely come across bugs in the field that have to do with buffer
overflows. Yes, sometimes it happens during development that you acces an
invalid pointer. But you do a test run and see that the system doesnt work
properly anymore and you fix it.

Consider yourself to be blessed and lucky. You have software that shows
some symptoms of "not working properly". There are software that gives no
such indication, and these are ticking time-bombs. Crackers that have too
much time on their hands craft exploits that can compromise the securities
of a system that host such software.

Even should your software give some indication of "not working properly", ...

2. Having a "safe" language is not the real solution. Lets take java, it
does bounds checking. What does it do when it sees a buffer overflow? It
throws an exception and you can bet the program is not designed to recover
from this kind of error. Almost the same result as in C, the program doesnt
work correctly. The only difference is that you get a neat error message
saying which line in which file displayed the bug. But at the end of the day
the bug is still there.

.... the cost of identifying the real location of the buffer overflow is
*FAR* more significant that it would be in a Java program that fails like
you have described above. "Almost the same result as in C" is just plain
wrong. Failing noisily is a good thing that other programming languages
achieve at a (purportedly) higher overhead than C does not incur by not
implementing such safety nets.

[Anand Hariharan]

On Sat, 26 Jul 2008 11:25:06 -0700, Keith Thompson wrote:

vi******@gmail.com writes:

>On Jul 26, 10:05 am, Anand Hariharan
<[e-mail]:

>>On Fri, 25 Jul 2008 19:26:05 -0700, Keith Thompson wrote:
Anand Hariharan <[e-mail]:
On Fri, 25 Jul 2008 03:06:36 -0400, CBFalconer wrote:
There is no destinction between
a pointer to a char, and a pointer to an array of 10,000 chars.

Are they not different types?

Yes, they are. The point, I think, is that given

char *ptr;

you can't tell (unless you keep track it yourself *very* carefully)
whether it points to a single object of type char, or to the first
element of an array of 10,000 chars.

Methinks one can distinguish between

char *PointerToAChar;
char (* PointerToAnArrayOf10000Chars)[10000];

Yes, they can. The point, I think, is that gives

char *ptr;

you can't tell (unless you keep track it yourself *very* carefully)
whether it points to a single object of type char, or to the first
element of an array of 10,000 chars.

Well said.

Umm, I assumed 'vippstar' is a different avatar of you (Keith Thompson).

If that is not true, then from the the unsnipped, quoted text above, it is
extremely suggestive (if not evident) that 'vippstar' has reproduced
word-for-word (except for "they can" and "gives") what you have written.

[Keith Thompson]

Anand Hariharan <zn********************@tznvy.pbzwrites:

On Sat, 26 Jul 2008 11:25:06 -0700, Keith Thompson wrote:

>vi******@gmail.com writes:

>>On Jul 26, 10:05 am, Anand Hariharan
<[e-mail]:
On Fri, 25 Jul 2008 19:26:05 -0700, Keith Thompson wrote:
Anand Hariharan <[e-mail]:
On Fri, 25 Jul 2008 03:06:36 -0400, CBFalconer wrote:
There is no destinction between
a pointer to a char, and a pointer to an array of 10,000 chars.

Are they not different types?

Yes, they are. The point, I think, is that given

char *ptr;

you can't tell (unless you keep track it yourself *very* carefully)
whether it points to a single object of type char, or to the first
element of an array of 10,000 chars.

Methinks one can distinguish between

char *PointerToAChar;
char (* PointerToAnArrayOf10000Chars)[10000];
Yes, they can. The point, I think, is that gives

char *ptr;

you can't tell (unless you keep track it yourself *very* carefully)
whether it points to a single object of type char, or to the first
element of an array of 10,000 chars.

Well said.

Umm, I assumed 'vippstar' is a different avatar of you (Keith Thompson).

No, I've never posted here other than under my own name.

If that is not true, then from the the unsnipped, quoted text above, it is
extremely suggestive (if not evident) that 'vippstar' has reproduced
word-for-word (except for "they can" and "gives") what you have written.

Yes, exactly. (I was making a little joke.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[santosh]

Anand Hariharan wrote:

On Sat, 26 Jul 2008 11:25:06 -0700, Keith Thompson wrote:

>vi******@gmail.com writes:

>>On Jul 26, 10:05 am, Anand Hariharan
<[e-mail]:
On Fri, 25 Jul 2008 19:26:05 -0700, Keith Thompson wrote:
Anand Hariharan <[e-mail]:
On Fri, 25 Jul 2008 03:06:36 -0400, CBFalconer wrote:
There is no destinction between
a pointer to a char, and a pointer to an array of 10,000 chars.

Are they not different types?

Yes, they are. The point, I think, is that given

char *ptr;

you can't tell (unless you keep track it yourself *very*
carefully) whether it points to a single object of type char, or
to the first element of an array of 10,000 chars.

Methinks one can distinguish between

char *PointerToAChar;
char (* PointerToAnArrayOf10000Chars)[10000];
Yes, they can. The point, I think, is that gives

char *ptr;

you can't tell (unless you keep track it yourself *very* carefully)
whether it points to a single object of type char, or to the first
element of an array of 10,000 chars.

Well said.

Umm, I assumed 'vippstar' is a different avatar of you (Keith
Thompson).

If that is not true, then from the the unsnipped, quoted text above,
it is extremely suggestive (if not evident) that 'vippstar' has
reproduced word-for-word (except for "they can" and "gives") what you
have written.

I read that "Well said" as a joke, precisely because 'vippstar' used
Keith's words almost exactly.

[Bartc]

"Bart van Ingen Schenau" <Ba********************@ict.nlwrote in message
news:57**********************************@x41g2000 hsb.googlegroups.com...

On 23 jul, 03:37, "Dann Corbit" <[e-mail]:

>"Richard Heathfield" <[e-mail] in message

I haven't claimed that no buffer is involved. I've claimed that the C
program as shown doesn't use a buffer. It doesn't. What the
implementation
does in translation is of no concern as long as it faithfully
interprets
the program's semantics. If it chooses to add a buffer, so be it - but
the
C program does *not* use one.

The point discussed was in connection with vulnerabilities in connection
with the C programming language.
If a C program calls library functions, uses inline assembly or whatever
and
performs buffer movements then that is salient to the discussion of
vulnerabilities and buffer overflow.
Whether or not it was the end-user of the compiler or the compiler vendor
who broke something is irrelevant to the discussion.

By that reasoning, buffer overflows are a problem for every single
computer language in existance.
Even for the safest of safe languages, you can not possibly rule out
that a (flawed) translator introduces a buffer overflow in the
program.

If a language is interpreted then it is easy to put in these kinds of
run-time checks.

For the interpreter itself, it will be easier to thoroughly test just this
one, smallish program, and run a million identical copies, then to try and
ensure that a million totally different programs, from a million
programmers, and of unlimited complexity, do not have buffer overflow types
of problems.

So, why do people complain all the time about the possibility of
buffer overflows in C, but not in other languages?

I /think/ it may be possible to interpret C, and with the same sorts of
checks, so making this an implementation choice. Unless the language
requires that it must be possible to write outside of a buffer or array,
then C would appear less safe than other languages.
--
Bartc

[santosh]

Bartc wrote:

<snip>

I /think/ it may be possible to interpret C, and with the same sorts
of checks, so making this an implementation choice. Unless the
language requires that it must be possible to write outside of a
buffer or array, then C would appear less safe than other languages.

I think that /any/ language can be interpreted or compiled. And in
places the boundary between what one considers interpretation or
compilation are almost non-existent.

<http://www.softintegration.com/>

But C was, I think, not /designed/ to be interpreted. It was designed as
a system programming language, and interpreters are not very feasible
for very low-level code. Reduction of speed is only one issue.

[Malcolm McLean]

"Bartc" <[e-mail] in message

I /think/ it may be possible to interpret C, and with the same sorts of
checks, so making this an implementation choice. Unless the language
requires that it must be possible to write outside of a buffer or array,
then C would appear less safe than other languages.

There's a C interpreter in Schildt's book. It might be a nice exercise to
add buffer overflow checks to it.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Richard Bos]

Keith Thompson <ks***@mib.orgwrote:

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Keith Thompson <ks***@mib.orgwrote:

Richard Heathfield <rj*@see.sig.invalidwrites:
If you want Ada, you know where to find it.

Ada is as powerful as C. It doesn't forbid unsafe actions, it merely
requires you to specify them explicitly in most cases. For example,
to interpret an integer as a pointer (something C allows with a simple
cast), you have to instantiate Unchecked_Conversion and then call the
instance. (Strictly speaking, the C cast performs a type conversion,
not a reinterpretation, but it's implemented as a reinterpretation in
every implementation I've seen.)

In other words, Ada requires a special construct to be applied to
interpret an integer as a pointer; C, by contrast, requires a special
construct to be applied to interpret an integer as a pointer. Apart from
the size of the construct, I see no difference.

The difference is that the "special construct" in C, a cast doesn't
stand out. It's the same construct used to for perfectly safe type
conversions, such as a conversion from int to long.

One shouldn't use a cast when converting from int to long in the first
place. We're talking about C, here, not about C++. You're complaining
about people who stick Unchecked_Conversion instances on integer-on-
integer conversions, not about casts on pointers. IOW, you're
complaining about bad programmers, not about C.
Well, C has many, many more programmers than Ada, so yes, of course C
also has many more bad programmers than Ada. That does not mean that C
is inherently unsafe; what it means is that popular things get abused
more than unpopular things. Well, duh; more people drive cars badly than
motorcycles, too, but that doesn't make a car less safe than a
motorcycle.

Richard