Inflexible array members

[Richard Heathfield]

Adam Warner said:

Both you and Richard are snipping too much context.

I disagree.

Exactly! Point 1: I am not confusing a language with implementations
of that language because the Java Language Specification mandates bounds
checking semantics:

Reality check - this is comp.lang.c. [OT stuff about Java snipped] The C
language definition discusses various situations where a translator /must/
diagnose a problem, and leaves it up to implementations to diagnose other
situations as they will. Thus, whether statically determinable array bounds
violations are diagnosed is purely a "quality of implementation" issue.

Yet I still inhabit reality where the culture of C-is-a-portable-assembly-
language invariably eschews code safety. In your previous reply in this
thread you didn't even care about a basic static type definition check
that would have warned about a potential buffer overrun. A warning with no
runtime overhead implications and yet you still didn't care.

Just as I wouldn't criticise my wife for failing to tell me to fasten my
seatbelt, so I don't criticise my compiler for failing to tell me about
buffer overruns. Remembering to fasten my seatbelt is /my/ job, and I can
take care of it myself, but of course someone needs to keep an eye on the
kids in the back. Avoiding buffer overruns is /my/ job, and I can take care
of it myself, but of course someone needs to keep an eye on the Java kids
in the back.

 

[Mark McIntyre]

On Sun, 09 Jul 2006 13:05:31 +1200, in comp.lang.c , Adam Warner

(snip offtopic discussion of Java)

This is existential proof that safety can be mandated by a language
specification rather than purely a property of implementations.

I'm puzzled as to why you think anyone would be surprised at this. Why
are you stating the blindingly obvious?

Point 2: You were supposed to realise there is a penalty to be paid for
this feature.

Again, why are you stating the obvious?

Yet I still inhabit reality where the culture of C-is-a-portable-assembly-
language invariably eschews code safety.

If you have a culture of writing crap code in your company, don't
blame the language, blame your hiring policy. Seriously.

Reality check: the 'culture' of which you speak is the same one that
allows VB programmers to write rubbish VB, Java programmers to write
rubbish Java, and managers to write rubbish reports. Its nothing to do
with C.

In your previous reply in this
thread you didn't even care about a basic static type definition check
that would have warned about a potential buffer overrun. A warning with no
runtime overhead implications and yet you still didn't care.

You have absolutely no idea what I care about, so please don't
disingenuously insert your beliefs into my mouth.

Indifference to code safety is a signal to implementers.

No, its a signal to managers to fire their programmers.

You seem to want to live in a sandbox. Please feel free to move there.
--
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

 

[August Karlstrom]

Just as I wouldn't criticise my wife for failing to tell me to fasten my
seatbelt, so I don't criticise my compiler for failing to tell me about
buffer overruns. Remembering to fasten my seatbelt is /my/ job, and I can
take care of it myself, but of course someone needs to keep an eye on the
kids in the back. Avoiding buffer overruns is /my/ job, and I can take care
of it myself, but of course someone needs to keep an eye on the Java kids
in the back.

Bah, real programmers write in machine code.


August

 

[Adam Warner]

On Sun, 09 Jul 2006 13:05:31 +1200, in comp.lang.c , Adam Warner

(snip offtopic discussion of Java)


I'm puzzled as to why you think anyone would be surprised at this. Why
are you stating the blindingly obvious?

You have again snipped the context. Perhaps I had to state the blindingly
obvious because the first time around you snipped my examples before
telling me they were confused. Now you're puzzled, wondering why I would
say something so obvious. I guess everything I say is both confused and
blindingly obvious.

I again claim I was not confusing the language with implementations of the
language. You disagreed ("I disagree, but I suspect it'd be a bit like
explaining to an agoraphobic why its quite safe to stand in on a
hilltop.") with this statement: "C the language does not incorporate the
concept of safe code nor the localisation of unsafe code."

I contrasted C the language with language specifications that do have a
concept of safe code. I quoted them.

Again, why are you stating the obvious?

One could suspect that I was trying to explain why in the sentences that
followed. Here's the context:

Point 2: You were supposed to realise there is a penalty to be paid for
this feature. Which is why I then mentioned another language
specification that provides for levels of compilation safety so that
implementations can support both safe code and code without, for
example, bounds checking. In contrast Java the language dictates that
out of bounds indexing is perfectly legal program semantics so one
cannot indiscriminately elide bounds checking from correct Java
programs.

If you have a culture of writing crap code in your company, don't blame
the language, blame your hiring policy. Seriously.

Reality check: the 'culture' of which you speak is the same one that
allows VB programmers to write rubbish VB, Java programmers to write
rubbish Java, and managers to write rubbish reports. Its nothing to do
with C.


You have absolutely no idea what I care about, so please don't
disingenuously insert your beliefs into my mouth.

My example code was:

#include <stdlib.h>

typedef unsigned char byte_t[1];

int main() {
byte_t *b=malloc(1);
(*b)[1]=123;
return 0;
}

$ gcc -std=c99 -Wall -Wextra array.c
$

I wrote: "This compiles without a single warning that the static indexing
is out of bounds." Here is your response:

So? Its the programmer's responsibility not to break the rules.


I am satisfied that I have treated you fairly. This is my final reply.

 

[Mark McIntyre]

You have again snipped the context.

No. I removed irrelevant and offtopic material .This is what you do in
usenet, to avoid excessively long posts.

I'm done here. You want to change the C language, thats fine, submit a
request to the ISO committee, perhaps discussing it first in
comp.std.c. If instead you want to discuss how to use C, feel free to
post here again.
--
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

 

[Chris Torek]

From my perspective a type system should distinguish between a scalar and
a vector and not permit one to be misused as the other ...

C just does not let you do this. As far as C is concerned,
*every* object is also a one-element array of that object:

int *ip, i;
ip = &i;

/* use of either *ip or ip[0] */

(though a scalar can be abstracted as the first element of a
vector of length 1).

Worse yet, given any pointer value of type "pointer to T" that
is both valid (i.e., points to some object, or is NULL) and non-NULL
(i.e., we take the "or is NULL" part away), not only is *p valid,
but p may also be valid for some nonzero "i"s, including
negative values of "i":

int a[100];

ip = &a[50];
/* now ip[-50] names a[0], ip[-1] names a[49], ip[0] names a[50],
and so on */

The declaration "int *var;" is conceptually a pointer to a scalar of type
int or a pointer to a vector of type int.

C conflates the concepts. They are now so thoroughly intermingled
that they can never be re-separated.

If it's a scalar it should never
be positively indexed as an array yet var[12345] will silently compile.

So let's explicitly define scalars as vectors of length 1:

#include <stdlib.h>

typedef unsigned char byte_t[1];

int main() {
byte_t *b=malloc(1);
(*b)[1]=123;
return 0;
}

Alas, we can *also* write:

b[j] = 123;

which in this case is valid if and only if i==0 and j==0 (and, of
course, b!=NULL).

$ gcc -std=c99 -Wall -Wextra array.c
$

This compiles without a single warning that the static indexing
is out of bounds.

I believe there are variants of gcc that will detect the out-of-bounds
"[1]" at compile time, and I am sure there are some that will detect
not only that, but also out-of-bound i and/or j at run-time with
the b[j] line. However, these are just particular (and very
clever) compilers (and no doubt the bounds-checking gcc needs
library help to make malloc() work). C compilers in general are
not required to diagnose this, and few do.

If you want other languages, you know where to find them.

 

[jjf]

You have again snipped the context. Perhaps I had to state the blindingly
obvious because the first time around you snipped my examples before
telling me they were confused. Now you're puzzled, wondering why I would
say something so obvious. I guess everything I say is both confused and
blindingly obvious.

That's certainly how it appears. If you have a point which isn't
blindingly obvious, you are hiding it very well. What point are you
trying to make?