Is this valid?

[AC]

Is the following code valid?

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

typedef struct
{
int a;
char s[];
} test_struct;

int main(void)
{
test_struct *t;
t = malloc( sizeof *t + 4);
strcpy(t->s,"oye");
printf("%s\n",t->s);
return 0;
}

[clayne]

For C90: no.

[Robert Gamble]

On Fri, 10 Jun 2005 12:34:08 -0400, AC wrote:

Is the following code valid?

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

typedef struct
{
int a;
char s[];
} test_struct;

int main(void)
{
test_struct *t;
t = malloc( sizeof *t + 4);
strcpy(t->s,"oye");
printf("%s\n",t->s);
return 0;
}

I don't see any problems with it. The flexible array feature is not
standardized until C99 although many implementations supported it in some
form prior to that (but that would, of course, not be portable).

Robert Gamble

[Anonymous 7843]

In article <d8**********@license1.unx.sas.com>, AC <te**@test.test> wrote:

Is the following code valid?

typedef struct
{
int a;
char s[];
} test_struct;

If you change the declaration of s to char s[1] the
trick will work more often, i.e. nearly always.

It is technically outside the bounds of c89 though.

Search for "struct hack" using your favorite search engine
if you would like more information.
--
7842++

[Martin Ambuhl]

AC wrote:

Is the following code valid?
It is not valid C89 (C90); it is valid C99.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

typedef struct
{
int a;
char s[];
} test_struct;

int main(void)
{
test_struct *t;
t = malloc( sizeof *t + 4);
strcpy(t->s,"oye");
printf("%s\n",t->s);
return 0;
}

[Christopher Benson-Manica]

AC <te**@test.test> wrote:

Is the following code valid? (snip "struct hack" code)

FAQ 2.6 may be of interest:

http://www.eskimo.com/~scs/C-faq/q2.6.html

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Mark]

"Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:oU*****************@newsread1.news.atl.earthl ink.net...

AC wrote:

Is the following code valid?

It is not valid C89 (C90); it is valid C99.

*May* be valid C99... depends on return from malloc() which is not checked.

Quick question:
cfaq question 7.24 (relating to whether allocated memory must be freed prior
to exit)
references a section 7.10.3.2 no longer existant (AFAICT) in the current
standard...
So what's the official take? Answer remains the same but unsubstantiated?

Mark

[Chris Croughton]

On Fri, 10 Jun 2005 19:20:00 GMT, Mark
<so***@localbar.com> wrote:

Quick question:
cfaq question 7.24 (relating to whether allocated memory must be freed
prior to exit) references a section 7.10.3.2 no longer existant
(AFAICT) in the current standard... So what's the official take?
Answer remains the same but unsubstantiated?

Using a reference to a nonexistent object results in undefined behaviour
<g>.

Chris C

[Keith Thompson]

"Mark" <so***@localbar.com> writes:
[...]

Quick question:
cfaq question 7.24 (relating to whether allocated memory must be
freed prior to exit) references a section 7.10.3.2 no longer
existant (AFAICT) in the current standard... So what's the official
take? Answer remains the same but unsubstantiated?

In C90, 7.10.3.2 describes the "free" function. The corresponding
section in C99 is 7.20.3.2.

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

[Mark]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Mark" <so***@localbar.com> writes:
[...]

Quick question:
cfaq question 7.24 (relating to whether allocated memory must be
freed prior to exit) references a section 7.10.3.2 no longer
existant (AFAICT) in the current standard... So what's the official
take? Answer remains the same but unsubstantiated?

In C90, 7.10.3.2 describes the "free" function. The corresponding
section in C99 is 7.20.3.2.

Ah... they must have modified the description substantially then.
I see nothing in the standard which would suggest free() is optional
and it seems the previously quoted text 'quality of implementation issue'
was removed from C99.

Mark

[Keith Thompson]

"Mark" <so***@localbar.com> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Mark" <so***@localbar.com> writes:
[...]

Quick question:
cfaq question 7.24 (relating to whether allocated memory must be
freed prior to exit) references a section 7.10.3.2 no longer
existant (AFAICT) in the current standard... So what's the official
take? Answer remains the same but unsubstantiated?

In C90, 7.10.3.2 describes the "free" function. The corresponding
section in C99 is 7.20.3.2.

Ah... they must have modified the description substantially then.
I see nothing in the standard which would suggest free() is optional
and it seems the previously quoted text 'quality of implementation issue'
was removed from C99.

No, there was no significant change in the wording from C90 to C99.
(I don't think there was any change, but I'm too lazy to compare it.)

The phrase "quality of implementation issue" in the FAQ is not a quote
from the standard. Basically, once the program terminates the
standard doesn't care what happens next.

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

[Lawrence Kirby]

On Fri, 10 Jun 2005 19:20:00 +0000, Mark wrote:

"Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:oU*****************@newsread1.news.atl.earthl ink.net...

AC wrote:

Is the following code valid?

It is not valid C89 (C90); it is valid C99.

*May* be valid C99... depends on return from malloc() which is not checked.

Quick question:
cfaq question 7.24 (relating to whether allocated memory must be freed prior
to exit)
references a section 7.10.3.2 no longer existant (AFAICT) in the current
standard...
So what's the official take? Answer remains the same but unsubstantiated?

The C language has never required you to free memory before the program
terminates - strictly conforming programs do not need to do this.

The standard is concerned about the behaviour of a program while it is
executing up to the point it generates a termination status. What happens
after it terminates is of no concern to the standard. In particular it has
nothing to say about the reclamation of any of the resources that the
program used. That includes memory allocated for code, automatic objects,
static objects, allocated objects that have been freed, allocated objects
that have not been freed, and anything else that the implementation uses
to support the execution of the program.

Whether these things are reclaimed or not is therefore an implementation
issue. You may take a view that freed objects are more likely to be
reclaimed than unfreed ones, but there's nothing in the standard to
support that view, and very little evidence from real-world
implementations either. The fact is that a implementation that doesn't
reclaim fully will have resource leak and therefore stability issues
that are rarely if ever acceptable.

Perhaps a more solid reason for freeing memory before the program
terminates is to help debugging tools such as memory leak detectors.

Lawrence