Re: Format string bugs & race conditions

[Benjamin Ketcham <bketcham@drizzle.com>]

Martin Dowie <martin.dowie@btopenworld.com> wrote:
> "Benjamin Ketcham" <bketcham@drizzle.com> wrote in message 
> news:1097990937.246146@yasure...
>> Jeffrey Carter <spam@spam.com> 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