A very interesting book

[Anand Hariharan]

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]

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.

 

[CBFalconer]

CBFalconer said:

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.

 

[vippstar]

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.

 

[Harald van Dijk]

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.

 

[Richard]

CBFalconer said:

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]

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]

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.

 

[Anand Hariharan]

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]

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]

On Jul 26, 10:05 am, Anand Hariharan
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.)

 

[santosh]

On Jul 26, 10:05 am, Anand Hariharan
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]

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.

 

[santosh]

Bartc wrote:

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.

 

[Richard Bos]

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