|C compiler warning messages? email@example.com (1997-04-06)|
|Re: C compiler warning messages? firstname.lastname@example.org (1997-04-07)|
|Re: C compiler warning messages? morris@CAM.ORG (1997-04-08)|
|Re: C compiler warning messages? email@example.com (David Chase) (1997-04-11)|
|Re: C compiler warning messages? firstname.lastname@example.org (1997-04-16)|
|Re: C compiler warning messages? morris@CAM.ORG (Morris Bernstein) (1997-04-16)|
|Re: C compiler warning messages? email@example.com (1997-04-18)|
|From:||firstname.lastname@example.org (Joshua Levy)|
|Date:||16 Apr 1997 00:07:52 -0400|
|Keywords:||storage, errors, practice|
email@example.com (John Roberts) writes:
> However, in general, it seems to me that the C compiler should
> of given me a warning about returning a pointer to a string
> about to go out of scope.
John (the moderator) adds:
> GCC 2.x does indeed produce a warning.
GCC does produce a warning for the exact code John Roberts provided,
but not for the slightly more complex case below. Although it is not
a compiler, PREfix (a product from Intrinsa) will find the error.
(Note that this example is a little more complicated, because I want
it to cover the case brought up by Morris Bernstein, as well):
$ cat -n f.c
1 char *foo(int arg)
3 char bar, *baz ;
5 baz = bar ;
6 if (arg) baz = "foo" ;
7 return baz ;
$ gcc -Wall -c f.c
$ prefix -c f.c
f.c, line 7 : warning (16): exports pointer to local 'bar'
problem occurs in function 'foo'
The technology behind PREfix is software component simulation:
it simulates each function individually, looking for NULL pointers,
leaking memory, returning stack memory, etc. This is analagous
to the simulation done by computer chip makers, to ensure that
"first silicon" actually works.
Morris Bernstein also points out:
> At the end of the conditional, all the compiler can determine is
> that pstr *might* point to stack-allocated memory.
True, but isn't this enough? The fact that the pointer might point
at stack allocated memory is surely a bug: the only question is if
there is a good enought test case (or unlucky enough customer) to
> In general, the kind of defect detection you're interested in is
> very difficult to do at compile time. You're much better off
> using a C interpreter like Saber C (are they still around?). The
> interpreter can much more easily check such conditions at run time.
I agree that an interpreter will work better than a data flow based
tool (example: compilers), but I think that simulation might be
better than either. An interpreter would only find errors once the
program is run, and only if there is a test suite which shows off
the problem. Simulation does not require that the program be run,
and is not limited by the quality of the test suite.
You can find more information at our web site: http://www.intrinsa.com
Or by sending email to firstname.lastname@example.org
Return to the
Search the comp.compilers archives again.