By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,234 Members | 1,941 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,234 IT Pros & Developers. It's quick & easy.

Inflexible array members

P: n/a
Hi all,

One cannot return a pointer to an array type in C because C has no first
class array types. But one can return a pointer to a struct containing an
incomplete array via the illegal but widely supported zero array struct
hack:

#include <stdlib.h>

typedef struct byte_vector_t byte_vector_t;

struct byte_vector_t {
unsigned char byte[0];
};

int main() {
byte_vector_t *byte_vector=malloc(10);
byte_vector->byte[9]=42;
return 0;
}

It is frequently stated that flexible array members are a substitute for
the zero array struct hack. Let's see (by compiling file array.c below
with GNU C):

#include <stdlib.h>

typedef struct byte_vector_t byte_vector_t;

struct byte_vector_t {
unsigned char byte[];
};

int main() {
byte_vector_t *byte_vector=malloc(10);
byte_vector->byte[9]=42;
return 0;
}

$ gcc -std=c99 array.c
array.c:6: error: flexible array member in otherwise empty struct

GCC refuses to compile this code because C99 states (6.7.2.1,
paragraph 2):

A structure or union shall not contain a member with incomplete or
function type (hence, a structure shall not contain an instance of
itself, but may contain a pointer to an instance of itself), except
that the last member of a structure with more than one named member may
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
have incomplete array type; such a structure (and any union containing,
possibly recursively, a member that is such a structure) shall not be a
member of a structure or an element of an array.

This restriction is repeated in paragraph 16.

The struct types are intended to serve as self-documenting code and stop
me from incorrectly indexing a pointer to a single value (and vice versa).
Typedefs also lead to self-documenting code but provide no additional
compile-time type safety.

Is this restriction upon flexible array members sensible? The core syntax
and semantics are better because one should not index past the elements of
an array (and a zero sized array has no elements). Is there a standard way
I can maintain the extra type safety of structs with an incomplete array
member without having to pad those structs with a non-zero sized header?

Many thanks,
Adam
Jul 8 '06 #1
Share this Question
Share on Google+
26 Replies


P: n/a
Adam Warner wrote:
Hi all,

One cannot return a pointer to an array type in C because C has no first
class array types.
Sure you can. Typically, you won't really want to, but it's possible.

typedef char array[10];
array *f(void) {
/* ... */
}

You can also write it without a typedef as

char (*f(void))[10] {
/* ... */
}

You can also leave out the size.

typedef char array[];
array *f(void) {
/* ... */
}

or

char (*f(void))[] {
/* ... */
}

The rest of your message seems irrelevant after that.

Jul 8 '06 #2

P: n/a
On Sat, 08 Jul 2006 00:32:05 -0700, Harald van Dijk wrote:
Adam Warner wrote:
>Hi all,

One cannot return a pointer to an array type in C because C has no first
class array types.

Sure you can. Typically, you won't really want to, but it's possible.

typedef char array[10];
array *f(void) {
/* ... */
}

You can also write it without a typedef as

char (*f(void))[10] {
/* ... */
}

You can also leave out the size.

typedef char array[];
array *f(void) {
/* ... */
}

or

char (*f(void))[] {
/* ... */
}
Excellent! Thank you for the correction.

#include <stdint.h>
#include <stdlib.h>

typedef uint8_t octet_vector_t[];

int main() {
octet_vector_t *vector=malloc(10);
(*vector)[9]=42;
return 0;
}

Please let me known if there's a way to avoid the explicit dereferencing
syntax for every array access.

Regards,
Adam
Jul 8 '06 #3

P: n/a
Adam Warner wrote:
On Sat, 08 Jul 2006 00:32:05 -0700, Harald van Dijk wrote:
Adam Warner wrote:
Hi all,

One cannot return a pointer to an array type in C because C has no first
class array types.
Sure you can. Typically, you won't really want to, but it's possible.

Excellent! Thank you for the correction.

Please let me known if there's a way to avoid the explicit dereferencing
syntax for every array access.
"Typically, you won't really want to." If you use a pointer to an
array's first element instead of one to the whole array, which is what
most functions accepting or returning arrays do, you won't have that
problem. Is there a reason that is not an option for you?

Jul 8 '06 #4

P: n/a
Harald van Dijk wrote:
Adam Warner wrote:
On Sat, 08 Jul 2006 00:32:05 -0700, Harald van Dijk wrote:
Adam Warner wrote:
>Hi all,
>>
>One cannot return a pointer to an array type in C because C has no first
>class array types.
>
Sure you can. Typically, you won't really want to, but it's possible.
Excellent! Thank you for the correction.

Please let me known if there's a way to avoid the explicit dereferencing
syntax for every array access.

"Typically, you won't really want to." If you use a pointer to an
array's first element instead of one to the whole array, which is what
most functions accepting or returning arrays do, you won't have that
problem. Is there a reason that is not an option for you?
To clarify, I mean with typedefs.

Jul 8 '06 #5

P: n/a
On Sat, 08 Jul 2006 03:22:24 -0700, Harald van Dijk wrote:
Harald van Dijk wrote:
>Adam Warner wrote:
On Sat, 08 Jul 2006 00:32:05 -0700, Harald van Dijk wrote:
Adam Warner wrote:
Hi all,

One cannot return a pointer to an array type in C because C has no first
class array types.

Sure you can. Typically, you won't really want to, but it's possible.

Excellent! Thank you for the correction.

Please let me known if there's a way to avoid the explicit dereferencing
syntax for every array access.

"Typically, you won't really want to." If you use a pointer to an
array's first element instead of one to the whole array, which is what
most functions accepting or returning arrays do, you won't have that
problem. Is there a reason that is not an option for you?

To clarify, I mean with typedefs.
From my perspective a type system should distinguish between a scalar and
a vector and not permit one to be misused as the other without an explicit
type cast (though a scalar can be abstracted as the first element of a
vector of length 1).

The declaration "int *var;" is conceptually a pointer to a scalar of type
int or a pointer to a vector of type int. 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;
}

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

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

There is a solution: If every scalar is defined within a struct then the
scalar cannot be mistaken for an array of scalars. This does have
implications for inefficient ABIs that return all structs, no matter how
small, via pointers to memory.

Regards,
Adam
Jul 8 '06 #6

P: n/a
Adam Warner wrote:
From my perspective a type system should distinguish between a scalar and
a vector and not permit one to be misused as the other without an explicit
type cast (though a scalar can be abstracted as the first element of a
vector of length 1).
Ah, sorry, I don't think that's possible in standard C. Pointer
arithmetic is allowed for any pointer to a complete object type,
there's no way around that other than by not using a complete object
type, which is not an appropriate solution in most cases.

Jul 8 '06 #7

P: n/a
Adam Warner posted:

Excellent!

Here's a recent thread about declarations which might interest you:
http://groups.google.ie/group/comp.l...454781f0d9831/
f0276049c354479f?hl=en#f0276049c354479f
--

Frederick Gotham
Jul 8 '06 #8

P: n/a
On Sat, 08 Jul 2006 23:42:22 +1200, in comp.lang.c , Adam Warner
<us****@consulting.net.nzwrote:
>The declaration "int *var;" is conceptually a pointer to a scalar of type
int or a pointer to a vector of type int.
Er, no its not. Its conceptually a pointer to a block of memory
containing objects of type int.

Its not a pointer to a vector of anything.
>If it's a scalar it should never be positively indexed as an array yet var[12345] will silently compile.
Sure, because what it points to is a block of memory.

(snip example of array bounds overrun)
>This compiles without a single warning that the static indexing is out of
bounds.
So? Its the programmer's responsibility not to break the rules.
>There is a solution:
Indeed there are many. There is however a penalty, often quite a
severe one.

--
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
Jul 8 '06 #9

P: n/a
On Sat, 08 Jul 2006 17:02:25 +0100, Mark McIntyre wrote:
(snip example of array bounds overrun)
Here's that code example again:

#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
$
>>This compiles without a single warning that the static indexing is out
of bounds.

So? Its the programmer's responsibility not to break the rules.
Here we have an explicit type definition that byte_t is an unsigned char
array of length 1 and you don't even care about silent compilation of a
STATICALLY OBVIOUS buffer overrun.

Third parties suffer from programmers unintentionally breaking rules.
C programming is like having a car with the speedometer removed and a gas
pedal that keeps getting stuck. Yet drivers of these cars are mystified
why others don't want them on the road.

Regards,
Adam
Jul 8 '06 #10

P: n/a
Adam Warner said:

<snip>
Here we have an explicit type definition that byte_t is an unsigned char
array of length 1 and you don't even care about silent compilation of a
STATICALLY OBVIOUS buffer overrun.
The compiler is under no obligation to compile it silently. It is free to
issue a diagnostic message. QoI issue.
Third parties suffer from programmers unintentionally breaking rules.
Yes indeed. That's because too many programmers haven't a clue what they're
doing.
C programming is like having a car with the speedometer removed and a gas
pedal that keeps getting stuck.
Like Formula 1 cars, you mean? They don't have speedometers. Whilst the gas
pedal doesn't actually stick as such, you could be forgiven for thinking
so. They can really go some, can't they?
Yet drivers of these cars are mystified why others don't want them on the
road.
When you need to get from A to B in a tearing hurry, you need a fast car
/and/ a safe driver. If you are employing programmers who need to be told
by the compiler not to write to the second byte in a single-byte array, I
suggest you fire them and get someone bright instead.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jul 8 '06 #11

P: n/a
On Sat, 08 Jul 2006 19:59:37 +0000, Richard Heathfield wrote:
Adam Warner said:

<snip>
>Here we have an explicit type definition that byte_t is an unsigned char
array of length 1 and you don't even care about silent compilation of a
STATICALLY OBVIOUS buffer overrun.

The compiler is under no obligation to compile it silently. It is free to
issue a diagnostic message. QoI issue.
>Third parties suffer from programmers unintentionally breaking rules.

Yes indeed. That's because too many programmers haven't a clue what they're
doing.
I suggest there is dysfunction in the programming community and low
quality of implementation is a symptom. I hope you enjoyed my
light-hearted analogy.
>C programming is like having a car with the speedometer removed and a gas
pedal that keeps getting stuck.

Like Formula 1 cars, you mean? They don't have speedometers. Whilst the gas
pedal doesn't actually stick as such, you could be forgiven for thinking
so. They can really go some, can't they?
>Yet drivers of these cars are mystified why others don't want them on the
road.

When you need to get from A to B in a tearing hurry, you need a fast car
/and/ a safe driver. If you are employing programmers who need to be told
by the compiler not to write to the second byte in a single-byte array, I
suggest you fire them and get someone bright instead.
Thank you for proving my point. Formula 1 cars are not permitted upon
public highways.

Regards,
Adam

PS: A programming language that incorporates levels of compilation safety
can be safer by default but just as fast (and dangerous) when you are in a
tearing hurry.
Jul 8 '06 #12

P: n/a
Adam Warner <us****@consulting.net.nzwrites:
[...]
From my perspective a type system should distinguish between a scalar and
a vector and not permit one to be misused as the other without an explicit
type cast (though a scalar can be abstracted as the first element of a
vector of length 1).

The declaration "int *var;" is conceptually a pointer to a scalar of type
int or a pointer to a vector of type int. If it's a scalar it should never
be positively indexed as an array yet var[12345] will silently compile.
I'm afraid you must be talking about some language other than C.

In C, array indexing is defined in terms of pointer arithmetic; x[y]
is merely a shorthand for (*x+y).

You might not like it, but it's a fundamental feature of the language.

See section 6 of the comp.lang.c FAQ, <http://www.c-faq.com/>, for
more information.

--
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.
Jul 8 '06 #13

P: n/a
Adam Warner said:
On Sat, 08 Jul 2006 19:59:37 +0000, Richard Heathfield wrote:
>Adam Warner said:
>>Third parties suffer from programmers unintentionally breaking rules.

Yes indeed. That's because too many programmers haven't a clue what
they're doing.

I suggest there is dysfunction in the programming community and low
quality of implementation is a symptom.
Yes, that's true - but the quality of implementation of C compilers tends to
be extremely good. The fact that a compiler does not diagnose something it
is not required to diagnose does not indicate that it is a poor
implementation.
I hope you enjoyed my light-hearted analogy.
Sure, but remember that analogies are only illustrations of a point. They
cannot /prove/ a point. If they could, two people could prove opposite
points simply by choosing conflicting analogies. As Bjarne Stroustrup once
said, "proof by analogy is fraud".

<snip>
>>
When you need to get from A to B in a tearing hurry, you need a fast car
/and/ a safe driver. If you are employing programmers who need to be told
by the compiler not to write to the second byte in a single-byte array, I
suggest you fire them and get someone bright instead.

Thank you for proving my point. Formula 1 cars are not permitted upon
public highways.
"Proof by analogy is fraud." - Bjarne Stroustrup.

Computers are not public highways.
PS: A programming language that incorporates levels of compilation safety
can be safer by default but just as fast (and dangerous) when you are in a
tearing hurry.
You are confusing the language with implementations of that language.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jul 8 '06 #14

P: n/a
On Sat, 08 Jul 2006 21:09:58 +0000, Richard Heathfield wrote:
>PS: A programming language that incorporates levels of compilation
safety can be safer by default but just as fast (and dangerous) when
you are in a tearing hurry.

You are confusing the language with implementations of that language.
BTW I'm not. Java is an example of a language definition where array
bounds checking is mandated. One cannot disable array bounds checking and
be programming within the semantics of Java the language. For example one
must be able to traverse an array using an otherwise infinite index count
by catching an array index out of bounds exception when the array is
referenced out of range.

Common Lisp is an example of a language that incorporates levels of
compilation safety. There is a concept of safe code. Extra run time checks
are performed upon safe code to help ensure the integrity of the virtual
machine. Correct code will run with the same semantics at any level of
safety, including the disabling of bounds checking. Furthermore the
compilation settings can be locally tuned. For example, once one is sure
that a critical inner loop is correct, safety can be lowered for that
particular region of code.
<http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_s.htm#safe>
<http://www.lispworks.com/documentation/HyperSpec/Body/d_optimi.htm#optimize>

C the language does not incorporate the concept of safe code nor the
localisation of unsafe code. It is no accident implementations eschew code
safety.

Regards,
Adam
Jul 8 '06 #15

P: n/a
Keith Thompson wrote:
Adam Warner <us****@consulting.net.nzwrites:
[...]
>From my perspective a type system should distinguish between a scalar and
a vector and not permit one to be misused as the other without an explicit
type cast (though a scalar can be abstracted as the first element of a
vector of length 1).

The declaration "int *var;" is conceptually a pointer to a scalar of type
int or a pointer to a vector of type int. If it's a scalar it should never
be positively indexed as an array yet var[12345] will silently compile.

I'm afraid you must be talking about some language other than C.

In C, array indexing is defined in terms of pointer arithmetic; x[y]
is merely a shorthand for (*x+y).

You might not like it, but it's a fundamental feature of the language.

See section 6 of the comp.lang.c FAQ, <http://www.c-faq.com/>, for
more information.
Not (*x+y) but *(x+y) and the difference is non-trivial.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Jul 8 '06 #16

P: n/a
Joe Wright <jo********@comcast.netwrites:
Keith Thompson wrote:
>Adam Warner <us****@consulting.net.nzwrites:
[...]
>>From my perspective a type system should distinguish between a scalar and
a vector and not permit one to be misused as the other without an explicit
type cast (though a scalar can be abstracted as the first element of a
vector of length 1).

The declaration "int *var;" is conceptually a pointer to a scalar of type
int or a pointer to a vector of type int. If it's a scalar it should never
be positively indexed as an array yet var[12345] will silently compile.
I'm afraid you must be talking about some language other than C.
In C, array indexing is defined in terms of pointer arithmetic; x[y]
is merely a shorthand for (*x+y).
You might not like it, but it's a fundamental feature of the
language.
See section 6 of the comp.lang.c FAQ, <http://www.c-faq.com/>, for
more information.
Not (*x+y) but *(x+y) and the difference is non-trivial.
Oops. You're right, of course. It was a typo; thank you for catching
it.

--
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.
Jul 8 '06 #17

P: n/a
Adam Warner said:
On Sat, 08 Jul 2006 21:09:58 +0000, Richard Heathfield wrote:
>>PS: A programming language that incorporates levels of compilation
safety can be safer by default but just as fast (and dangerous) when
you are in a tearing hurry.

You are confusing the language with implementations of that language.

BTW I'm not.
In C terms, you are.

<OT stuff snipped>

C the language does not incorporate the concept of safe code nor the
localisation of unsafe code. It is no accident implementations eschew code
safety.
That's the programmer's job. Code safety is far too important to be left to
the compiler. Programmers should take responsibility for ensuring their
code is safe.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jul 8 '06 #18

P: n/a
On Sun, 09 Jul 2006 10:09:06 +1200, in comp.lang.c , Adam Warner
<us****@consulting.net.nzwrote:
>On Sat, 08 Jul 2006 21:09:58 +0000, Richard Heathfield wrote:
>You are confusing the language with implementations of that language.

BTW I'm not.
I'm afraid you are. Worse, you confuse your examples. First you
mention a language which has no levels of compliation safety, and
mandates bounds-checking. Thats fine, but its a different language,
and pays a penalty for these features. Then you mention a language in
which some implementations permit you to mark code as safe. Thats fine
too, but its an implementation feature. Again thats fine, but again
there's a penalty.
>C the language does not incorporate the concept of safe code nor the
localisation of unsafe code.
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.
>It is no accident implementations eschew code safety
Not merely a nonsqeuitur, but a troll.
--
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
Jul 8 '06 #19

P: n/a
On Sat, 08 Jul 2006 23:55:42 +0100, Mark McIntyre wrote:
On Sun, 09 Jul 2006 10:09:06 +1200, in comp.lang.c , Adam Warner
<us****@consulting.net.nzwrote:
>>On Sat, 08 Jul 2006 21:09:58 +0000, Richard Heathfield wrote:
>>You are confusing the language with implementations of that language.

BTW I'm not.
Both you and Richard are snipping too much context. I responded to
Richard's response to my postscript:

PS: A programming language that incorporates levels of compilation
safety can be safer by default but just as fast (and dangerous) when
you are in a tearing hurry.
I'm afraid you are. Worse, you confuse your examples. First you
mention a language which has no levels of compliation safety, and
mandates bounds-checking. Thats fine, but its a different language,
and pays a penalty for these features.
Exactly! Point 1: I am not confusing a language with implementations
of that language because the Java Language Specification mandates bounds
checking semantics:
<http://java.sun.com/docs/books/jls/third_edition/html/arrays.html#10.4>

All array accesses are checked at run time; an attempt to use an index
that is less than zero or greater than or equal to the length of the
array causes an ArrayIndexOutOfBoundsException to be thrown.

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

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.
Then you mention a language in which some implementations permit you to
mark code as safe. Thats fine too, but its an implementation feature.
Again thats fine, but again there's a penalty.
The notion of safe and hence unsafe code is also part of the language
specification I cited. I am not confused about the difference between a
programming language specification and the implementation of a programming
language.
>>C the language does not incorporate the concept of safe code nor the
localisation of unsafe code.

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.
>>It is no accident implementations eschew code safety

Not merely a nonsqeuitur, but a troll.
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.

Indifference to code safety is a signal to implementers. Future
standardisation as a distillation of industry best practice will be
affected if there is no emphasis upon development of implementation
extensions that enhance code safety.

Regards,
Adam
Jul 9 '06 #20

P: n/a
Adam Warner said:
On Sat, 08 Jul 2006 23:55:42 +0100, Mark McIntyre wrote:
>On Sun, 09 Jul 2006 10:09:06 +1200, in comp.lang.c , Adam Warner
<us****@consulting.net.nzwrote:
>>>On Sat, 08 Jul 2006 21:09:58 +0000, Richard Heathfield wrote:

You are confusing the language with implementations of that language.

BTW I'm not.

Both you and Richard are snipping too much context.
I disagree.

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

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jul 9 '06 #21

P: n/a
On Sun, 09 Jul 2006 13:05:31 +1200, in comp.lang.c , Adam Warner
<us****@consulting.net.nzwrote:

(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?
>>>It is no accident implementations eschew code safety

Not merely a nonsqeuitur, but a troll.

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
Jul 9 '06 #22

P: n/a
Richard Heathfield wrote:
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
Jul 9 '06 #23

P: n/a
On Sun, 09 Jul 2006 11:32:49 +0100, Mark McIntyre wrote:
On Sun, 09 Jul 2006 13:05:31 +1200, in comp.lang.c , Adam Warner
<us****@consulting.net.nzwrote:

(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?
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.
>>Point 2: You were supposed to realise there is a penalty to be paid for
this feature.

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.
>>>>It is no accident implementations eschew code safety

Not merely a nonsqeuitur, but a troll.

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

>>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.
Jul 9 '06 #24

P: n/a
On Mon, 10 Jul 2006 00:49:25 +1200, in comp.lang.c , Adam Warner
<us****@consulting.net.nzwrote:
>On Sun, 09 Jul 2006 11:32:49 +0100, Mark McIntyre wrote:
>On Sun, 09 Jul 2006 13:05:31 +1200, in comp.lang.c , Adam Warner
<us****@consulting.net.nzwrote:

(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?

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
Jul 9 '06 #25

P: n/a
In article <pa****************************@consulting.net.n z>
Adam Warner <us****@consulting.net.nzwrote:
>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[i] 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[i][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[i][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. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Jul 10 '06 #26

P: n/a
jjf

Adam Warner wrote:
On Sun, 09 Jul 2006 11:32:49 +0100, Mark McIntyre wrote:
On Sun, 09 Jul 2006 13:05:31 +1200, in comp.lang.c , Adam Warner
<us****@consulting.net.nzwrote:

(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?

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?

Jul 10 '06 #27

This discussion thread is closed

Replies have been disabled for this discussion.