* Format string bugs & race conditions @ 2004-10-16 9:28 Hans Van den Eynden 2004-10-16 13:26 ` Stephen Leake 2004-10-16 17:55 ` Jeffrey Carter 0 siblings, 2 replies; 14+ messages in thread From: Hans Van den Eynden @ 2004-10-16 9:28 UTC (permalink / raw) In C/C++ there is a major problem with "Format string bugs" & "race conditions". Can this appear in ada??? and if soo how?? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Format string bugs & race conditions 2004-10-16 9:28 Format string bugs & race conditions Hans Van den Eynden @ 2004-10-16 13:26 ` Stephen Leake 2004-10-16 15:09 ` Pascal Obry 2004-10-16 17:55 ` Jeffrey Carter 1 sibling, 1 reply; 14+ messages in thread From: Stephen Leake @ 2004-10-16 13:26 UTC (permalink / raw) To: comp.lang.ada 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Format string bugs & race conditions 2004-10-16 13:26 ` Stephen Leake @ 2004-10-16 15:09 ` Pascal Obry 0 siblings, 0 replies; 14+ messages in thread From: Pascal Obry @ 2004-10-16 15:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Format string bugs & race conditions 2004-10-16 9:28 Format string bugs & race conditions Hans Van den Eynden 2004-10-16 13:26 ` Stephen Leake @ 2004-10-16 17:55 ` Jeffrey Carter 2004-10-17 5:28 ` Benjamin Ketcham 1 sibling, 1 reply; 14+ messages in thread From: Jeffrey Carter @ 2004-10-16 17:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Format string bugs & race conditions 2004-10-16 17:55 ` Jeffrey Carter @ 2004-10-17 5:28 ` Benjamin Ketcham 2004-10-17 9:14 ` Martin Dowie ` (3 more replies) 0 siblings, 4 replies; 14+ messages in thread From: Benjamin Ketcham @ 2004-10-17 5:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Format string bugs & race conditions 2004-10-17 5:28 ` Benjamin Ketcham @ 2004-10-17 9:14 ` Martin Dowie 2004-10-17 19:18 ` Benjamin Ketcham 2004-10-17 12:28 ` Marius Amado Alves ` (2 subsequent siblings) 3 siblings, 1 reply; 14+ messages in thread From: Martin Dowie @ 2004-10-17 9:14 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Format string bugs & race conditions 2004-10-17 9:14 ` Martin Dowie @ 2004-10-17 19:18 ` Benjamin Ketcham 2004-10-17 22:41 ` Martin Dowie 2004-10-18 7:57 ` Ole-Hjalmar Kristensen 0 siblings, 2 replies; 14+ messages in thread From: Benjamin Ketcham @ 2004-10-17 19:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Format string bugs & race conditions 2004-10-17 19:18 ` Benjamin Ketcham @ 2004-10-17 22:41 ` Martin Dowie 2004-10-18 7:57 ` Ole-Hjalmar Kristensen 1 sibling, 0 replies; 14+ messages in thread From: Martin Dowie @ 2004-10-17 22:41 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Format string bugs & race conditions 2004-10-17 19:18 ` Benjamin Ketcham 2004-10-17 22:41 ` Martin Dowie @ 2004-10-18 7:57 ` Ole-Hjalmar Kristensen 2004-10-19 16:20 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 14+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-10-18 7:57 UTC (permalink / raw) >>>>> "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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Format string bugs & race conditions 2004-10-18 7:57 ` Ole-Hjalmar Kristensen @ 2004-10-19 16:20 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 14+ messages in thread From: Warren W. Gay VE3WWG @ 2004-10-19 16:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Format string bugs & race conditions 2004-10-17 5:28 ` Benjamin Ketcham 2004-10-17 9:14 ` Martin Dowie @ 2004-10-17 12:28 ` Marius Amado Alves 2004-10-17 17:28 ` Larry Kilgallen 2004-10-17 17:11 ` Larry Kilgallen 2004-10-18 0:24 ` Jeffrey Carter 3 siblings, 1 reply; 14+ messages in thread From: Marius Amado Alves @ 2004-10-17 12:28 UTC (permalink / raw) To: comp.lang.ada > /* 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 :-) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Format string bugs & race conditions 2004-10-17 12:28 ` Marius Amado Alves @ 2004-10-17 17:28 ` Larry Kilgallen 0 siblings, 0 replies; 14+ messages in thread From: Larry Kilgallen @ 2004-10-17 17:28 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Format string bugs & race conditions 2004-10-17 5:28 ` Benjamin Ketcham 2004-10-17 9:14 ` Martin Dowie 2004-10-17 12:28 ` Marius Amado Alves @ 2004-10-17 17:11 ` Larry Kilgallen 2004-10-18 0:24 ` Jeffrey Carter 3 siblings, 0 replies; 14+ messages in thread From: Larry Kilgallen @ 2004-10-17 17:11 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Format string bugs & race conditions 2004-10-17 5:28 ` Benjamin Ketcham ` (2 preceding siblings ...) 2004-10-17 17:11 ` Larry Kilgallen @ 2004-10-18 0:24 ` Jeffrey Carter 3 siblings, 0 replies; 14+ messages in thread From: Jeffrey Carter @ 2004-10-18 0:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2004-10-19 16:20 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-10-16 9:28 Format string bugs & race conditions Hans Van den Eynden 2004-10-16 13:26 ` Stephen Leake 2004-10-16 15:09 ` Pascal Obry 2004-10-16 17:55 ` Jeffrey Carter 2004-10-17 5:28 ` Benjamin Ketcham 2004-10-17 9:14 ` Martin Dowie 2004-10-17 19:18 ` Benjamin Ketcham 2004-10-17 22:41 ` Martin Dowie 2004-10-18 7:57 ` Ole-Hjalmar Kristensen 2004-10-19 16:20 ` Warren W. Gay VE3WWG 2004-10-17 12:28 ` Marius Amado Alves 2004-10-17 17:28 ` Larry Kilgallen 2004-10-17 17:11 ` Larry Kilgallen 2004-10-18 0:24 ` Jeffrey Carter
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox