Re: C bug of the day

["Balog Pal" <pasa@lib.hu>]

"James Rogers" <jimmaureenrogers@att.net> wrote in message
news:Xns9397C17B49692jimmaureenrogers@204.127.36.1...

> Interesting. Do you think the fundamental safety problem in C code
> is ininitialized integers?

Not "the" bat a very seriously fundamental problem I find in practice.

> What about memory leaks

Memleaks: I find not a problem in C++.  (it is in C)   [user shall not
handle memory in C++, containers and self-managing classes can solve
that
problem.]

> de-referencing
> null pointers, and array bounds violations?

null pointers: not really. Dangling pointers is a problem. But it is not
a
coding-level problem but more generic, object lifetime problem on the
design
level.

Array bounds: C, not C++. As normally in C++ we use containers, and
those do
bounts checks in debug build, that's enough to cath the typos/offby1
goofing. Generally.

Uninited variables are more than a nuisance, they pick up memory trash,
and
make the execution non-deterministic.   You can easily end up with all
your
tests passing, and still a broken problem that will hit you picking up
another memory pattern.

> The lint tool was able to identify uninitialized variables nearly
> thirty years ago. Of course, lint is not part of the C language,
> but it is one of those tools that has been used to try to improve
> the quality of C code for decades. With the common availability of
> lint for so many years, why is do uninitialized variables still
> occur in C?

My guess is "we're cool guys not using lint". ;-o
btw lint will pick every case of uninited variable I guess, how you tell
it
to pass those you actually want uninited?

> The reason is that many programmers neglect to use tools such as
> lint, which support my point. Programmers are frequently lazy.

Well, if it was part of the package -- I still don't know whether I used
it
or not. (More probably yes.)  with C++ it's quite a crude tool, isn't
it?

Can you tune it to pick up most real problems while not producing 10
times
more noise?

> A language that requires extra work to achieve safety will
> frequently be used to create unsafe programs. This is not
> because it is impossible to create safe programs with the language.
> It is because doing so requires extra work.

Sure, that's why the other poster claimed the uninitialised is a bad
default
behavior.

> On the other hand, a language that requires extra work to remove
> built in safety features will frequently be used to create safe
> programs. This is not because it is impossible to create unsafe
> programs with the language. It is because doing so requires extra
> work.

And that is not so symmetric unfortunately.  Most safety you must reach
at
the design level. The level of language features may be too far away
from
that to know what is safe, or what is reasonable.  [sometimes even
design
falls on face, like the syncronised stuff in the first java containers.]


Paul



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]