Re: C bug of the day

[LLeweLLyn <llewelly.at@xmission.dot.com>]

James Rogers <jimmaureenrogers@att.net> writes:

 > "Balog Pal" <pasa@lib.hu> wrote in news:3ee8901a@andromeda.datanet.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.]
 >
 > Do you ever deal with C++ code written using C style primitives such
 > as arrays? I understand that such code still exists.

Yes, it does, and will continue to do so - std::vector<> handles dynamic
     memory allocation nicely, but if one must avoid dynamic memory
     allocation, one must either use an array, or download an
     apropriate array wrapper. Additionally, std::vector<> is for
     variable sized arrays, and not all arrays should be variable
     sized.

IMO the real solution to this is for more implementations to provide
     bounded pointers - unfortunately, that doesn't happen. What C++
     needs is a revolt against the old gaurd that fails to provide such
     things simply because they have always failed to provide such
     things.

 >
 >  >
 >  >> 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.
 >
 > I agree that pointer lifetime issues are a design issue. One of the
 > sometimes more difficult rules in Ada deals with pointer lifetime
 > issues. (In Ada they are called access variables, but the lifetime
 > issue applies here.) The language has very strict rules about access
 > value lifetimes. The compilers enforce those rules. The result is
 > a very low occurrance of dangling pointers.

In C++ one downloads, writes, or finds in the standard library a smart
     pointer that (via the compiler) enforces such rules. No, this is
     not as good as what Ada access types provide; though the
     functionality may be as good or better, the fact that standard
     library only provides one kind (an IMO auto_ptr is not a
     particularly good kind of smart pointer), is in practice a
     significant, but not insurmountable, problem in encouraging the
     use of safer smart pointers.

 >  >
 >  > 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.
 >
 > Again, what about C++ code written using C style primitives such as
 > strings and other forms of arrays?
 >
 > What C++ allows, and provides for "free" with the STL, is the
 > ability to wrap the C style primitives such as arrays in a class,
 > with all the bounds checking built into the class.
 >
 > This provides safety at the expense of some efficiency. Although
 > the STL is part of the language definition, it is not part of the
 > language syntax. A C++ compiler cannot optimize out bounds checks
 > from STL or other container classes.

I think you have some minor misunderstaings here. First, the ISO C++
     standard says nothing about bounds checking of standard library
     iterators, and if one is not careful about the bad habit of
     passing references to containers to functions, one can get some
     nasty surprises from iterator invalidation rules. If one misuses
     an iterator, either via a container operation that invalidates it,
     or via an arithmetic operation that takes it out of bounds, the
     ISO C++ standard says (essentially) 'the behavior is
     undefined'. This has obvious drawbacks.

In practice, several implementations provide a 'debug mode' behavior,
     which throws exceptions, or aborts with appropriate error
     messages, when one does inappropriate things with iterators, and a
     'release mode' behavior, where 'undefined behavior' is some
     compromise between best performance, and whatever the implementor
     found most convienient. One can usually use what amount to
     compiler flags to change modes, though since the standard library
     provider is sometimes not the same as the core language provider,
     these flags may be interesting. :-)

Second, while no compiler I know of does this, I believe it is
     possible to optimize bounds checking out of a bounds checked
     standard library implementation, though it likely requires
     extensive co-operation between standard library provider and
     compiler provider (again, sometimes not the same entity) to be
     practical.

 >
 >  > My guess is "we're cool guys not using lint". ;-o

In my experience this and related problems have everything to do with
     ignorance, and nothing to do with thinking 'we're cool ...'

I've said it before, and I'll say it again - ignorance is C++'s worst
     problem. Having Ada's safer defaults, checks, etc, would help, but
     not has much as an aggressive campaign against ignornace. (And in
     practice such a campaign would be necessary part of getting
     Ada-like safer defaults and checks in C++.)

 >  > 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?
 >
 > Do modern C++ compilers produce the level of diagnostic output available
 > from (or better than) lint?

For the cases of uinitialized variables, type checking, things that
     are not too hard to detect and almost certainly wrong, the answer
     is often yes - but for higher level tasks the answer is no.

 >
 >  >
 >  > Can you tune it to pick up most real problems while not producing 10
 >  > times
 >  > more noise?
 >
 > This has always been an issue with lint. Tuning the output to give
 > no false reports while still not missing any real problems is not
 > easy.
 >  >
 >  >> 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.
 >
 > I agree it is bad. I just did not think it was the most often encountered
 > problem.

I don't think it is the most often encountered problem either. I've
     worked in some places with awful coding habits, but everywhere
     I've been the compiler warning flags for uninitialised variables
     are used and heeded.

 >
 > Ada goes a bit further in this area than most C++ programs.
 > Ada allows you to define your own numeric types (as primitives, not
 > classes). You are allowed to define several characteristics about
 > these types.
 >
 > type My_Index is range 1..10;

That's possible in C++, but it isn't that easy - it could be, but
     neither the standard library (nor boost) provide ranged integers.

 >
 > The above line defines an integer type with a valid range of values
 > from 1 through 10 inclusive. Now, let's combine that definition with
 > an array type definition:
 >
 > type Nums is array (My_Index) of Float;
 >
 > This defines an array type indexed by the type My_Index. Each element
 > of the array is a Float.
 >
 > The compiler can now optimize out bounds checking for accessing
 > an array of Nums. The only index type allowed is type My_Index.
 > Every possible value of that type maps to an array element.
 >
 > Trying to assign an out of range value to a variable of My_Index
 > causes the program to raise the exception Constraint_Error at run
 > time.
[snip]

Hm. This sounds like the bounds checking is not being optimized out,
     but moved from the array to the index type. This seems an
     improvement - I suspect assigments to index variables are somewhat
     less common than using them in the array, but the compiler still
     can't get rid of all checks. (Yes this is still an improvement
     over the C++ situation w.r.t. to bounds checking.)

[synch stuff snipped]


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