«

(Malcolm Dew-Jones) writes:
> Flash Gordon () wrote:
> : Paminu wrote:
> : > Is there no such a thing as an ArrayOutOfBounds exception in C?
>
> : No. Some implementations will trap some out of bounds accesses under
> : some circumstances, but it is not guaranteed and I'm not aware of any
> : that will catch all out of bounds accesses.
>
> You wouldn't want a compiler to catch all out of bounds errors. A common
> idiom for structures is
>
> typedef struct _something
> {
> struct _something * next;
> char data[1];
> } something ;

Leading underscores in identifiers. Ick. (I'm too lazy to check
whether this particular usage is a problem.)

> When used, an instance will be malloc'd with a size large enough to
> contain your data and then the data member can be accessed as
>
> a_something.data[i]
>
> The array index may commonly appear to be "out of bounds" according to the
> definition, but doesn't represent a problem.

It's a common idiom, known as the "struct hack", but strictly speaking
it invokes undefined behavior. A checking implementation could
legally forbid references to any element of a_something.data other
than a_something.data[0].

C99 added a "safe" version of the "struct hack", known as a "flexible
array member". For example:

struct something {
struct something *next;
char data[];
};

--
Keith Thompson (The_Other_Keith) kst- <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.

(Malcolm Dew-Jones) writes:

> Flash Gordon () wrote:
> : Paminu wrote:
> : > Is there no such a thing as an ArrayOutOfBounds exception in C?
>
> : No. Some implementations will trap some out of bounds accesses under
> : some circumstances, but it is not guaranteed and I'm not aware of any
> : that will catch all out of bounds accesses.
>
> You wouldn't want a compiler to catch all out of bounds errors. A common
> idiom for structures is
>
> typedef struct _something
> {
> struct _something * next;
> char data[1];
> } something ;

There's a FAQ that talks about this.

2.6: I came across some code that declared a structure like this:

struct name {
int namelen;
char namestr[1];
};

and then did some tricky allocation to make the namestr array
act like it had several elements. Is this legal or portable?

A: This technique is popular, although Dennis Ritchie has called it
"unwarranted chumminess with the C implementation." An official
interpretation has deemed that it is not strictly conforming
with the C Standard, although it does seem to work under all
known implementations. (Compilers which check array bounds
carefully might issue warnings.)

Another possibility is to declare the variable-size element very
large, rather than very small; in the case of the above example:

...
char namestr[MAXSIZE];

where MAXSIZE is larger than any name which will be stored.
However, it looks like this technique is disallowed by a strict
interpretation of the Standard as well. Furthermore, either of
these "chummy" structures must be used with care, since the
programmer knows more about their size than the compiler does.
(In particular, they can generally only be manipulated via
pointers.)

C9X will introduce the concept of a "flexible array member",
which will allow the size of an array to be omitted if it is
the last member in a structure, thus providing a well-defined
solution.

References: Rationale Sec. 3.5.4.2; C9X Sec. 6.5.2.1.

--
"The expression isn't unclear *at all* and only an expert could actually
have doubts about it"
--Dan Pop

Keith Thompson (kst-) wrote:
: (Malcolm Dew-Jones) writes:
: > Flash Gordon () wrote:
: > : Paminu wrote:
: > : > Is there no such a thing as an ArrayOutOfBounds exception in C?
: >
: > : No. Some implementations will trap some out of bounds accesses under
: > : some circumstances, but it is not guaranteed and I'm not aware of any
: > : that will catch all out of bounds accesses.
: >
: > You wouldn't want a compiler to catch all out of bounds errors. A common
: > idiom for structures is
: >
: > typedef struct _something
: > {
: > struct _something * next;
: > char data[1];
: > } something ;

: Leading underscores in identifiers. Ick. (I'm too lazy to check
: whether this particular usage is a problem.)

"problem"? perhaps that's something new. You (used to) need a name for
the struct but the typedef name is the name you will normally use. I
think I copied the style (underscore on the struct name) from Atari or
Macintosh code.


: > When used, an instance will be malloc'd with a size large enough to
: > contain your data and then the data member can be accessed as
: >
: > a_something.data[i]
: >
: > The array index may commonly appear to be "out of bounds" according to the
: > definition, but doesn't represent a problem.

: It's a common idiom, known as the "struct hack", but strictly speaking
: it invokes undefined behavior. A checking implementation could
: legally forbid references to any element of a_something.data other
: than a_something.data[0].

: C99 added a "safe" version of the "struct hack", known as a "flexible
: array member". For example:

: struct something {
: struct something *next;
: char data[];
: };

Shows how much I use C these days. Thats good to know. I guess I should
bone up on the latest standard (perhaps after learning python and JSP 2).


--

This programmer available for rent.

(Malcolm Dew-Jones) writes:

> Keith Thompson (kst-) wrote:
> : Leading underscores in identifiers. Ick. (I'm too lazy to check
> : whether this particular usage is a problem.)
>
> "problem"? perhaps that's something new. You (used to) need a name for
> the struct but the typedef name is the name you will normally use. I
> think I copied the style (underscore on the struct name) from Atari or
> Macintosh code.

Keith is trying to point out that most identifiers that begin
with an underscore are reserved, so that user code should not use
them. There are some exceptions, but it's really not worth it to
remember them; it's simpler to just never start an identifier
with an underscore.

You can always use a trailing underscore instead.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

Keith Thompson <kst-> wrote:
> (Malcolm Dew-Jones) writes:

>> typedef struct _something
>> {
>> struct _something * next;
>> char data[1];
>> } something ;
>
> Leading underscores in identifiers. Ick. (I'm too lazy to check
> whether this particular usage is a problem.)

I think it's always okay for members.

# -- All identifiers that begin with an underscore and
# either an uppercase letter or another underscore are
# always reserved for any use.
#
# -- All identifiers that begin with an underscore are
# always reserved for use as identifiers with file scope
# in both the ordinary and tag name spaces.

--
Stan Tobias
mailx `echo LID | sed s/[[:upper:]]//g`

Keith Thompson wrote:

> Paminu <> writes:
>> Is there no such a thing as an ArrayOutOfBounds exception in C?
>>
>> I just did:
>>
>> int main()
>> {
>> int a[4]; // a is an array that contains 4 integer.
>> a[5] = 999; // Thought this would give an error!
>> printf("a[5]: %d\n", a[5]);
>> return 1;
>> }
>>
>> When I run this program
>>
>> a[5]: 999
>>
>> gets printed.
>>
>> How is it possible to put something in a[5] when I have only specified
>> that a should contain 4 integers?
>
> This just came up recently.
>
> Accessing an array element beyond the bounds of the array invokes
> undefined behavior. This doesn't mean the compiler will detect the
> error; it specifically means it's not required to do so. Undefined
> behavior can do literally anything; the standard joke is that it can
> legally make demons fly out of your nose.
>
> In this case, you're probably just stepping on a memory location past
> the end of the array. If the implementation doesn't happen to be
> using ithat location for anything, it will most likely not create a
> visible error (unfortunately). If it does use it for something, you
> might clobber the function's return address or anything else.


Ok so I guess my application does not use this memory location since I
always get 999 printed (unless some mysterious coincidence is taken place).

S.Tobias wrote:
> Keith Thompson <kst-> wrote:
>
>> (Malcolm Dew-Jones) writes:
>
>>> typedef struct _something
^^^^^^^^^^
>>> {
>>> struct _something * next;
>>> char data[1];
>>> } something ;
>>
>>Leading underscores in identifiers. Ick. (I'm too lazy to check
>>whether this particular usage is a problem.)
>
> I think it's always okay for members.

Maybe, but this was not a member, it was a tag.

> # -- All identifiers that begin with an underscore and
> # either an uppercase letter or another underscore are
> # always reserved for any use.
> #
> # -- All identifiers that begin with an underscore are
> # always reserved for use as identifiers with file scope
> # in both the ordinary and tag name spaces.

So if it was at file scope, which is likely since it looks like the
typedef for a linked list, it does fall foul of this.

As Keith said, it is simplest to just avoid all leading underscores and,
IMHO, it was a mistake for the standard to make the rules this complex.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

(Malcolm Dew-Jones) writes:
> Keith Thompson (kst-) wrote:
> : (Malcolm Dew-Jones) writes:
[...]
> : > You wouldn't want a compiler to catch all out of bounds errors. A common
> : > idiom for structures is
> : >
> : > typedef struct _something
> : > {
> : > struct _something * next;
> : > char data[1];
> : > } something ;
>
> : Leading underscores in identifiers. Ick. (I'm too lazy to check
> : whether this particular usage is a problem.)
>
> "problem"? perhaps that's something new. You (used to) need a name for
> the struct but the typedef name is the name you will normally use. I
> think I copied the style (underscore on the struct name) from Atari or
> Macintosh code.

Others have explained the problem with leading underscores.

In addition to that, there's really no need for the typedef. The
struct tag is all you need. For example (using C99 syntax for the
flexible array member):

struct something {
struct something *next;
char data[];
};

struct something s;
struct something *p;

The typedef can save you a few keystrokes (which is *not* necessarily)
a good thing). It also hides the fact that the type is a struct,
something that you don't usually want to hide (though there are
exceptions).

This is a matter of style, and not everyone agrees.

--
Keith Thompson (The_Other_Keith) kst- <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.