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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,892f841b317b302e X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!sn-xit-04!sn-xit-12!sn-xit-08!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: Benjamin Ketcham Newsgroups: comp.lang.ada Subject: Re: Format string bugs & race conditions Date: Sun, 17 Oct 2004 19:18:03 -0000 Organization: Ye 'Ol Disorganized NNTPCache groupie Message-ID: <1098040682.977030@yasure> References: <1c2f5137.0410160128.7ef88436@posting.google.com> <1097990937.246146@yasure> User-Agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (Linux/2.4.20-29.8.progeny.8 (i686)) Cache-Post-Path: yasure!unknown@cascadia.drizzle.com X-Cache: nntpcache 2.4.0b5 (see http://www.nntpcache.org/) X-Complaints-To: abuse@supernews.com Xref: g2news1.google.com comp.lang.ada:5374 Date: 2004-10-17T19:18:03+00:00 List-Id: Martin Dowie wrote: > "Benjamin Ketcham" wrote in message > news:1097990937.246146@yasure... >> Jeffrey Carter wrote: >>> Hans Van den Eynden wrote: >>> >>>> In C/C++ there is a major problem with "Format string bugs" & "race >>>> conditions". Can this appear in ada??? and if soo how?? >>> >>> How can you have race conditions in a sequential language? >> >> Easy: have more than one process/thread accessing the same resources. > > I think you missed Jeff's (non-too subtle) dig at C/C++ as they don't > support > concurrency /within/ the language standard (unlike Ada) but instead rely on > libraries, possibly competing libraries at that. Uh, no, I didn't miss it. I think maybe you missed my point that race conditions are (often) a consequence of bad/nonexistant design, which can occur in any language. In the real world, race conditions (and higher-level forms of deadlock, which the language cannot even *theoretically* protect against in some cases) are often a natural consequence and danger of the territory. Everyone thinks they understand these issues so well, everyone can rattle on at length about "priority inversion", yet after millions are spent and spaceships are sent out there, we *still* find that the same kinds of bugs crop up. It's difficult material to keep on top of when projects get big, and support from the language only goes so far. Indeed, if we want to discuss the issue of whether to put tasking into the language or not, I'll note that it's often hard for a language like Ada to know *which* of (possibly several) OS constructs is the best underlying foundation for the (single) language tasking model. E.g., in Linux and other POSIX systems: should we use processes? Kernel threads? User threads? Pros and cons to all -- but the point is, the *language implementors* have to make a choice, and can do little more than hope that their choice will suit most users. I note that some people have been forced to ignore the Ada tasking facilities, and implement tasking outside the language, just like with C/C++, in order to have more control over the implementation. I consider tasking difficult to separate from issues of process management; and that in turn is difficult to separate from dependence on the OS. I.e., it's not always a great idea to build this into the language, any more than it'd be to build in graphical I/O. In both cases, many people would be happy to have the things built-in, and many would find uses for the built-in constructs, but others will find deficiencies and will have to go outside the language. --Benjamin