Is this valid?

A

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;
}
 
R

Robert Gamble

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
 
A

Anonymous 7843

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

Martin Ambuhl

AC said:
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;
}
 
M

Mark

Martin Ambuhl said:
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
 
C

Chris Croughton

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
 
K

Keith Thompson

Mark said:
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.
 
M

Mark

Keith Thompson said:
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
 
K

Keith Thompson

Mark said:
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.
 
L

Lawrence Kirby

*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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top