OSDev.org

Thought you guys might be interested in this: http://www.cs.utah.edu/~regehr/papers/e ... eprint.pdf.

A paper from 2008 is not quite up to date with current compilers and standards, but still interesting to read and certainly good to know. One should keep this in mind when searching for bugs with volatile variables, and double check the compiler output in that case.

XenOS wrote:A paper from 2008 is not quite up to date with current compilers and standards, but still interesting to read and certainly good to know. One should keep this in mind when searching for bugs with volatile variables, and double check the compiler output in that case.

Would you care to elaborate on how exactly it's not up to date?

alexfru wrote:

XenOS wrote:...

Would you care to elaborate on how exactly it's not up to date?

Check the versions of the compilers used in the paper vs. current versions of the same compilers.

XenOS is right that it's something we need to look out for in specific circumstances (code not doing what we expect with volatile variables) but this is not likely to cause many bugs after *6* years of updates to compilers.

- Monk

XenOS wrote:A paper from 2008 is not quite up to date with current compilers and standards, but still interesting to read and certainly good to know. One should keep this in mind when searching for bugs with volatile variables, and double check the compiler output in that case.

Volatile wasn't exactly new in '08. It was in the original K&R C released in 1978. If the bugs hadn't been fixed in the 30 years previous, they likely weren't fixed in the 6 years following. That is, unless this paper brought the bugs to compiler devs' attention. But even then, I would guess the reason they lasted 30 years probably had something to do with the difficulty in fixing them, which would increase the likelihood they still aren't fixed.

You have to admit, it's pretty astounding that after 30 years of development (of the technology/methods, not the compilers themselves), not a single compiler got it right.

tjmonk15 wrote:

alexfru wrote:

XenOS wrote:...

Would you care to elaborate on how exactly it's not up to date?

Check the versions of the compilers used in the paper vs. current versions of the same compilers.

Compiler versions aren't of much relevance, they aren't definitive. The main question is about what has changed in the language standard(s) and which version of the standard which compiler supports. Since 2008 there's been only one standard update (C++03 -> C++11 and C99 -> C11). It would be nice to hear not just that the paper is somewhat outdated, but how, it shouldn't be a huge difference (a paragraph perhaps, maybe a little more?), right?

Compiler versions aren't of much relevance

Then you didn't properly read what the paper said itself:

because, as of this writing, no release incorporates fixes to all of the bugs we reported. (...) Our experiment is ongoing and we expect that within the
foreseeable future, LLVM - GCC will be effectively free of volatile and functional bugs for the programs emitted by randprog.

alexfru wrote:Compiler versions aren't of much relevance, they aren't definitive.

Oh but they are. Upgrading is a cost/benefit question for many non-hobby projects.

alexfru wrote: The main question is about what has changed in the language standard(s) and which version of the standard which compiler supports. Since 2008 there's been only one standard update (C++03 -> C++11 and C99 -> C11).

Standards are fairly meaningless unless they're adopted. I use ANSI C so C99 and C11 have absolutely no meaning to me and I'm not alone.
As someone who has implemented an ISO standard compliant programming language, I'll say that standards are created for many reasons, many of which are non-technical.

tjmonk15 wrote:

alexfru wrote:Would you care to elaborate on how exactly it's not up to date?

Check the versions of the compilers used in the paper vs. current versions of the same compilers.

Exactly. Those compiler versions are really outdated. And even if these bugs existed for 30 years, they were discovered, pointed out in this article and reported:

Combuster wrote:

Compiler versions aren't of much relevance

Then you didn't properly read what the paper said itself:

because, as of this writing, no release incorporates fixes to all of the bugs we reported. (...) Our experiment is ongoing and we expect that within the
foreseeable future, LLVM - GCC will be effectively free of volatile and functional bugs for the programs emitted by randprog.

bwat wrote:Standards are fairly meaningless unless they're adopted. I use ANSI C so C99 and C11 have absolutely no meaning to me and I'm not alone.

Wow.

ANSI is just the American standards institute. The International Standards Organisation (ISO) produces documents called ISO9899 and ISO14882, which describe C and C++ in their international variants which have been the norm since 1989. That's where C99 and C11 come from - C99 is short for ISO9899:1999 and C11 is short for ISO9899:2011.

That's a pretty ignorant stance to have. Try to at least think outside of the US-centered box that you currently live in.

Hi,

Candy wrote:

bwat wrote:Standards are fairly meaningless unless they're adopted. I use ANSI C so C99 and C11 have absolutely no meaning to me and I'm not alone.

ANSI is just the American standards institute. The International Standards Organisation (ISO) produces documents called ISO9899 and ISO14882, which describe C and C++ in their international variants which have been the norm since 1989. That's where C99 and C11 come from - C99 is short for ISO9899:1999 and C11 is short for ISO9899:2011.

That's a pretty ignorant stance to have. Try to at least think outside of the US-centered box that you currently live in.

It has nothing to do with geography or standard bodies (e.g. ANSI vs. ISO); and everything to do with history. Basically; bwat prefers "old" and doesn't like "new" (and doesn't care about which standard body was responsible for "old").

Note that I'm mostly the same. I mostly learnt C from "The C Programming Language (second edition)", and haven't really bothered learning anything that was added to C since (excluding my flagrant abuse of "//" for single line comments).

Maybe one day they're release a third edition of this book, and programmers will start learning C11 (and ignore all versions of C created after that)..


Cheers,

Brendan