From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,HEADER_SPAM autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fc772,b30bd69fa8f63cb2 X-Google-Attributes: gidfc772,public X-Google-Thread: 103376,b30bd69fa8f63cb2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-14 02:51:11 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!hammer.uoregon.edu!enews.sgi.com!news-out.spamkiller.net!propagator2-maxim!news-in-maxim.spamkiller.net!usc.edu!rpi!not-for-mail From: LLeweLLyn Newsgroups: comp.lang.ada,comp.lang.c++.moderated Subject: Re: C bug of the day Date: 14 Jun 2003 05:53:26 -0400 Organization: The Illusory Sorting Algorithm Sender: cppmods@netlab.cs.rpi.edu Message-ID: References: <1054751321.434656@master.nyc.kbcfp.com> <3ee8901a@andromeda.datanet.hu> NNTP-Posting-Host: netlab.cs.rpi.edu X-Original-Date: Fri, 13 Jun 2003 10:08:33 -0600 X-Submission-Address: c++-submit@netlab.cs.rpi.edu X-Auth: PGPMoose V1.1 PGP comp.lang.c++.moderated iQBVAwUAPurwkkHMCo9UcraBAQFQvwH9HT4HTDFUYDFWUktMbMAJtYN7NPUBkFX1 i8ROs8e1w3SNI5mXwl83ty/acLu3XMHPwJq49LNXTMtFdFRhLcyNZw== =ZZSO Xref: archiver1.google.com comp.lang.ada:39161 comp.lang.c++.moderated:68328 Date: 2003-06-14T05:53:26-04:00 List-Id: James Rogers writes: > "Balog Pal" wrote in news:3ee8901a@andromeda.datanet.hu: > > > "James Rogers" 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! ]