Format string bugs & race conditions

Format string bugs & race conditions

[Hans Van den Eynden]

In C/C++ there is a major problem with "Format string bugs" & "race
conditions". Can this appear in ada??? and if soo how??

Re: Format string bugs & race conditions

[Stephen Leake]

onsbomma@hotmail.com (Hans Van den Eynden) writes:

> In C/C++ there is a major problem with "Format string bugs" & "race
> conditions". Can this appear in ada??? and if soo how??

I'll take a wild guess at the problems you mean.

"Format string bugs"; I'll assume you mean the format strings in
printf and similar functions. No, that doesn't happen in standard Ada.
You can, of course, write your own functions that have such bugs.

"race conditions"; this is a general term for problems that arise when
independent threads or processes are not properly synchronized. Yes,
that can happen in Ada, but since the Ada language defines threads, it
is eaiser to avoid race conditions.

-- 
-- Stephe

Re: Format string bugs & race conditions

[Pascal Obry]

Stephen Leake <stephen_leake@acm.org> writes:

> "race conditions"; this is a general term for problems that arise when
> independent threads or processes are not properly synchronized. Yes,
> that can happen in Ada, but since the Ada language defines threads, it
> is eaiser to avoid race conditions.

Especially since Ada95 which offers support for protected record.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Format string bugs & race conditions

[Jeffrey Carter]

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?

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail
09

Re: Format string bugs & race conditions

[Benjamin Ketcham]

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.
Same as with a "non-sequential language".
Note that while the language may have no concept of concurrency,
as with C, it can still be used to write an OS or thread library
which does implement (simulated) concurrency.  And once you
have that, it's a quick slip down the slope to:

/*  If lockfile already exists, wait until it goes away.  */
while((p = fopen("lockfile", "r"))) {
    fclose(p);
    sleep(1);
}
/*  (race)  */
p = fopen("lockfile", "w");
/*  Access the stuff which lockfile is supposed to protect from
 *  multiple access.  But of course it doesn't.  */
fclose(p);
remove("lockfile");

Ada just makes it easier to implement this bug within a single
instance of the executable.

--Benjamin

Re: Format string bugs & race conditions

[Martin Dowie]

"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.

Cheers

-- Martin

Re: Format string bugs & race conditions

[Marius Amado Alves]

> /*  If lockfile already exists, wait until it goes away.  */
> while((p = fopen("lockfile", "r"))) {
>     fclose(p);
>     sleep(1);
> }
> /*  (race)  */
> p = fopen("lockfile", "w");
> /*  Access the stuff which lockfile is supposed to protect from
>  *  multiple access.  But of course it doesn't.  */
> fclose(p);
> remove("lockfile");
> 
> Ada just makes it easier to implement this bug within a single
> instance of the executable.

No. Using files for locks is equally easy to implement and equally buggy 
in any language. But in Ada you would implement a lock as a protected 
object and be safe from race conditions by definition.

Regarding format strings my experience confirms that the C approach is 
buggy and Ada is not. In Ada you can format even better than in C and 
very safely even without leaving the standard. Resources include: Put 
and Get procedures for all scalar types, all bases; actual format 
strings, COBOL picture strings, in Annex F; the 'Image attribute, handy 
for quick instrumentation. Happy formating :-)

Re: Format string bugs & race conditions

[Larry Kilgallen]

In article <1097990937.246146@yasure>, Benjamin Ketcham <bketcham@drizzle.com> writes:
> 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.
> Same as with a "non-sequential language".
> Note that while the language may have no concept of concurrency,
> as with C, it can still be used to write an OS or thread library
> which does implement (simulated) concurrency.

On a multiprocessor system that concurrency might not just be simulated.

Re: Format string bugs & race conditions

[Larry Kilgallen]

In article <mailman.13.1098016133.10401.comp.lang.ada@ada-france.org>, Marius Amado Alves <amado.alves@netcabo.pt> writes:
>> /*  If lockfile already exists, wait until it goes away.  */
>> while((p = fopen("lockfile", "r"))) {
>>     fclose(p);
>>     sleep(1);
>> }
>> /*  (race)  */
>> p = fopen("lockfile", "w");
>> /*  Access the stuff which lockfile is supposed to protect from
>>  *  multiple access.  But of course it doesn't.  */
>> fclose(p);
>> remove("lockfile");
>> 
>> Ada just makes it easier to implement this bug within a single
>> instance of the executable.
> 
> No. Using files for locks is equally easy to implement and equally buggy 
> in any language.

And that might be "not buggy at all", depending on _how_ you use files.

Regardless of programming language*, when one calls the VMS system
service SYS$CREATE with the FAB$V_CIF option a status code of
RMS$_CREATED indicates that the file was created by this process.
If not, it is time to try again for the example above.  Of course
opening a file is a costly synchronization mechanism which should
only be used in cases where the cost will be dwarfed by the cost
of the operation being protected.

      *	As usual Ada programmers use slightly different symbol names
	since Ada does not allow "$" in symbols.

Re: Format string bugs & race conditions

[Benjamin Ketcham]

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

Re: Format string bugs & race conditions

[Martin Dowie]

"Benjamin Ketcham" <bketcham@drizzle.com> wrote in message 
news:1098040682.977030@yasure...
>>>> 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.

Cool - but I'm not sure that was Jeff's point...




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.778 / Virus Database: 525 - Release Date: 15/10/2004 

Re: Format string bugs & race conditions

[Jeffrey Carter]

Benjamin Ketcham wrote:

> Jeffrey Carter <spam@spam.com> wrote:
> 
>>How can you have race conditions in a sequential language?
> 
> Easy: have more than one process/thread accessing the same resources.
> Same as with a "non-sequential language".
> Note that while the language may have no concept of concurrency,
> as with C, it can still be used to write an OS or thread library
> which does implement (simulated) concurrency.  And once you
> have that, it's a quick slip down the slope to:

Then you're not talking about C/++, but about C/++ with some threading 
library. Since threading libraries differ, we'd have to know which 
library you're using, and be familiar with that library to answer your 
question.

-- 
Jeff Carter
"C++ is like jamming a helicopter inside a Miata
and expecting some sort of improvement."
Drew Olbrich
51

Re: Format string bugs & race conditions

[Ole-Hjalmar Kristensen]

>>>>> "BK" == Benjamin Ketcham <bketcham@drizzle.com> writes:

<snip>

    BK> I consider tasking difficult to separate from issues of process
    BK> management; and that in turn is difficult to separate from dependence
    BK> on the OS.  I.e., it's not always a great idea to build this into
    BK> the language, any more than it'd be to build in graphical I/O.
    BK> In both cases, many people would be happy to have the things built-in,
    BK> and many would find uses for the built-in constructs, but others will
    BK> find deficiencies and will have to go outside the language.

    BK> --Benjamin

Actually, having tasking built-in is an excellent idea. It gives you a
much higher probability that programs which use tasking actually will
be portable. And if you have access to the source of the tasking run
time, or it has a published interface, you can always reimplement the
tasking run-time to suit your needs. If you don't like the language's
tasking *model*, that's a bit tougher. In this case some languages
(including Ada, see annex D.10) let you have access to more primitive
operations which can be used to roll your own.

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: Format string bugs & race conditions

[Warren W. Gay VE3WWG]

Ole-Hjalmar Kristensen wrote:
>>>>>>"BK" == Benjamin Ketcham <bketcham@drizzle.com> writes:
> <snip>
> 
>     BK> I consider tasking difficult to separate from issues of process
>     BK> management; and that in turn is difficult to separate from dependence
>     BK> on the OS.  I.e., it's not always a great idea to build this into
>     BK> the language, any more than it'd be to build in graphical I/O.
>     BK> In both cases, many people would be happy to have the things built-in,
>     BK> and many would find uses for the built-in constructs, but others will
>     BK> find deficiencies and will have to go outside the language.
> 
>     BK> --Benjamin
> 
> Actually, having tasking built-in is an excellent idea. It gives you a
> much higher probability that programs which use tasking actually will
> be portable. And if you have access to the source of the tasking run
> time, or it has a published interface, you can always reimplement the
> tasking run-time to suit your needs. If you don't like the language's
> tasking *model*, that's a bit tougher. In this case some languages
> (including Ada, see annex D.10) let you have access to more primitive
> operations which can be used to roll your own.

The downside of this, is that it is a bigger pain to get a compiler
implementation going on a new platform. Anyone got GNAT working for
plan 9 yet? ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg