Inflexible array members

[Adam Warner]

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=ma lloc(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=ma lloc(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

[Harald van Dijk]

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.

[Adam Warner]

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

[Harald van Dijk]

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?

[Harald van Dijk]

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.

[Adam Warner]

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

[Harald van Dijk]

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.

[Frederick Gotham]

Adam Warner posted:

Excellent!

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

Frederick Gotham

[Mark McIntyre]

On Sat, 08 Jul 2006 23:42:22 +1200, in comp.lang.c , Adam Warner
<us****@consult ing.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

[Adam Warner]

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