Re: C compiler warning messages?

David Chase <chase@naturalbridge.com>
11 Apr 1997 00:07:28 -0400

          From comp.compilers

Related articles
C compiler warning messages? johnr@ims.com (1997-04-06)
Re: C compiler warning messages? trt@duke.cs.duke.edu (1997-04-07)
Re: C compiler warning messages? morris@CAM.ORG (1997-04-08)
Re: C compiler warning messages? chase@naturalbridge.com (David Chase) (1997-04-11)
Re: C compiler warning messages? joshua@intrinsa.com (1997-04-16)
Re: C compiler warning messages? morris@CAM.ORG (Morris Bernstein) (1997-04-16)
Re: C compiler warning messages? oz@ds9.rnd.border.com (1997-04-18)
| List of all articles for this month |

From: David Chase <chase@naturalbridge.com>
Newsgroups: comp.compilers
Date: 11 Apr 1997 00:07:28 -0400
Organization: Natural Bridge LLC
References: 97-04-042 97-04-059
Keywords: C, debug, design

Morris Bernstein wrote:


> At the end of the conditional, all the compiler can determine is that
> pstr *might* point to stack-allocated memory. Even more difficult:
> pstr = foo(&stack_array[0]);
> To detect the *potential* error, a compiler has to be able to solve
> the interprocederal points-to problem, which is highly nontrivial.


My solution to this problem is simply to program in a language where
such gaffes are forbidden; Java, Modula-3, Scheme, and ML are all fine
choices. For some reason, most other people don't see the obvious
superiority of these solutions, and they program in other languages
like C and C++. I quit worrying about trying to educate people out of
shooting themselves in the foot, and have spent the last few years
either increasing performance of the firearms ("now with faster
bullets"), or building better diagnostic equipment ("that there is a
hole in your foot").


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


> [It's certainly useful to warn about returning a direct reference to an auto
> variable, which is an error 99+% of the time. Saber C is indeed still around,
> now it's called Code Center and the vendor is called Centerline. -John]


Code Center is probably still available, but they sell a newer product
called "C++ Expert", which also handles C just fine. I ran your
trickier example through the demo server that CenterLine has on the
web (http://lumiere.centerline.com:9000, when the machine isn't
crashed), and it did a pretty good job of complaining about it and
pointing out the offending line (this is running in batch mode, of
course).


======================================================================
CenterLine C++Expert, Version 1.2 Beta 1
Run-Time Check for a.out started.
"f1.c", line 10: Warning: [ReturningBadPointer]
Invalid pointer <Pointer to Popped Stack fun`rstr> returned from
function.
Here is the stack trace:
                  8 char rstr[20];
                  9 strcpy(rstr, "1");
==> 10 return ick((char *)&rstr[0]);
                11 }
                12 int main()
--- Traceback ---
fun, at "f1.c":10
main, at "f1.c":14
$start, in crt0.o




"f1.c", line 14: Warning: [PassingBadPointer]
Invalid pointer <Pointer to Popped Stack &<exited function>`<unknown
variable>> passed as second argument to function.
Here is the stack trace:
                12 int main()
                13 {
==> 14 printf("%s\n", fun());
                15 }
                16
--- Traceback ---
main, at "f1.c":14
$start, in crt0.o




Comment: [ExecutionSummary]
RunTimeDiagnostic
Execution of: /demo_2/a.out
      Errors: 0
      Warnings: 2
      Cautions: 0
      Leaks: 0
      Bytes leaked: 0
      Execution time: 1 second


1


Successful run
======================================================================


David Chase
(a former CenterLine employee, who worked on this very product, and
wrote the demo server, too.)
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.