How to fix compiler warning

[Dave Stafford]

I have a macro that I use across the board for freeing ram. I'd like to
clean up my code so I don't get these warnings.

#define sfree(x) _internal_sfree ((void **)&x)
#define _internal_sfree (x) ({ if(x && *x) { free(*x); *x=NULL; } })

void main() {
char *x = (char *) malloc(10);
int *y = (int *) malloc(10);

sfree(x);
sfree(y);
}

results in:

warning: dereferencing type-punned pointer will break strict-aliasing
rules

[Philip Potter]

Ian Collins wrote:

Philip Potter wrote:

>Ben Bacarisse wrote:

>>Philip Potter <pg*@see.sig.in validwrites:

Ian Collins wrote:
Which still leaves the question why cast to void** and why test for
NULL?
>
How about:
>
#define sfree(x) _internal_sfree (&x)
#define _internal_sfree (x) { free(*x); *x=NULL; }
Surely you should check that x!=NULL before calling *any* function
on *x?
That is not really a problem -- the x in _internal_sfree is always of
the form &... [Obviously this is only true if it is not invoked
directly, but there is no practical way to avoid problems if internal
helper macros are invoked by user code.]

Yes of course, I should have seen that before!

See what happens when "function like" macros have lower case names :)

How would it be any different if they were real functions?

--
Philip Potter pgp <atdoc.ic.ac. uk

[Keith Thompson]

Philip Potter <pg*@see.sig.in validwrites:

Ian Collins wrote:

>Philip Potter wrote:

>>Ben Bacarisse wrote:
Philip Potter <pg*@see.sig.in validwrites:

Ian Collins wrote:
>Which still leaves the question why cast to void** and why test for
>NULL?
>>
>How about:
>>
>#define sfree(x) _internal_sfree (&x)
>#define _internal_sfree (x) { free(*x); *x=NULL; }
Surely you should check that x!=NULL before calling *any* function
on *x?
That is not really a problem -- the x in _internal_sfree is always of
the form &... [Obviously this is only true if it is not invoked
directly, but there is no practical way to avoid problems if internal
helper macros are invoked by user code.]
Yes of course, I should have seen that before!

See what happens when "function like" macros have lower case names :)

How would it be any different if they were real functions?

The sfree() macro takes the address of its argument. If a function
did that, it would get the address of the parameter, a local object,
not the address of the object you pass to it.

--
Keith Thompson (The_Other_Keit h) 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Ian Collins said:

Dave Stafford wrote:

>void main() {

If you didn't get a warning for this, crank up the warning level!

Whilst it's wrong (except on some freestanding implementations ), it
isn't a syntax error or a constraint violation. Implementations need
not diagnose it (although some choose to do so).

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[pete]

Richard Heathfield wrote:

>
Ian Collins said:

Dave Stafford wrote:

void main() {

If you didn't get a warning for this, crank up the warning level!

Whilst it's wrong (except on some freestanding implementations ), it
isn't a syntax error or a constraint violation. Implementations need
not diagnose it (although some choose to do so).

I don't see void main() as being as more or less correct
on freestanding implementations which define void main(),
than it is on hosted implementations which define void main().

--
pete

[Ian Collins]

pete wrote:

Richard Heathfield wrote:

>Ian Collins said:

>>Dave Stafford wrote:

void main() {
If you didn't get a warning for this, crank up the warning level!

Whilst it's wrong (except on some freestanding implementations ), it
isn't a syntax error or a constraint violation. Implementations need
not diagnose it (although some choose to do so).

I don't see void main() as being as more or less correct
on freestanding implementations which define void main(),
than it is on hosted implementations which define void main().

Section 5.1.2.2.1 of the standard does.

--
Ian Collins.

[Christopher Benson-Manica]

[comp.lang.c] Richard Heathfield <rj*@see.sig.in validwrote:

Ian Collins said:

>If you didn't get a warning for this, crank up the warning level!

Whilst it's wrong (except on some freestanding implementations ), it
isn't a syntax error or a constraint violation. Implementations need
not diagnose it (although some choose to do so).

I would think that an implementation worth its salt would provide a
warning level at which it did issue a diagnostic for void main(). Are
there any major implementations which cannot be coerced into doing so?

--
C. Benson Manica | I appreciate all corrections, polite or otherwise.
cbmanica(at)gma il.com |
----------------------| I do not currently read any posts posted through
sdf.lonestar.or g | Google groups, due to rampant unchecked spam.

[Richard Heathfield]

Christopher Benson-Manica said:

[comp.lang.c] Richard Heathfield <rj*@see.sig.in validwrote:

>Ian Collins said:

>>If you didn't get a warning for this, crank up the warning level!

>Whilst it's wrong (except on some freestanding implementations ), it
isn't a syntax error or a constraint violation. Implementations need
not diagnose it (although some choose to do so).

I would think that an implementation worth its salt would provide a
warning level at which it did issue a diagnostic for void main(). Are
there any major implementations which cannot be coerced into doing so?

Borland can, and gcc can. Last time I checked, which was VS6, Microsoft
couldn't.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Fr************@ googlemail.com said:

On Aug 25, 12:45 pm, Richard Heathfield <[e-mail].i nvalidwrote:

>[...] C90 implementations must provide int main(int, char
**) and correct C90 programs must use int main(int char **) - not to
do so renders the behaviour of the program undefined.

I believe you are mistaken - in both C90 and C99, main can also take
no parameters. (It must still return an int of course.)

Whoops! Yes, of course it can instead take no parameters. Would you
believe me if I told you I knew that really? :-)

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

Ian Collins <ia******@hotma il.comwrites:

pete wrote:

[...]

>I don't see void main() as being as more or less correct
on freestanding implementations which define void main(),
than it is on hosted implementations which define void main().

Section 5.1.2.2.1 of the standard does.

It says that main shall be defined as 'int main(void)', or as
'int main(int argc, char *argv[])', "or in some other
implementation-defined manner".

So 'void main(void)' is "correct" on an implementation (either hosted
for freestanding) that supports it.

By contrast, 'int main(void)' is correct on any hosted implementation
(and may or may not be correct on a given freestanding
implementation) .

I was going to say which one of you I agree with, but the disagreement
is over words, not over what those words refer to, so I won't bother.

--
Keith Thompson (The_Other_Keit h) 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Christopher Benson-Manica wrote:

>
I would think that an implementation worth its salt would provide a
warning level at which it did issue a diagnostic for void main(). Are
there any major implementations which cannot be coerced into doing so?

I added a warning for
void main(void)
{
}

since lcc-win32 got into an obscure bug...

C99 mandates that main should return zero even if the programmer
doesn't explicitly write a return statement.

If you declare main as a void function however,
the compiler would try to make a void function return zero
as result!!!

A user warned me about this: the compiler crashed when it
saw

void main(void)
{}

I fixed it by ignoring the void statement. And added a
warning with a higher warning level.