Ken,
Thanks a lot for your feedback. Somehow your email fell through the
cracks and I didn't notice it until a colleague of mine reminded me.
Sorry for my delay in replying.
Here are my answers to your questions.
All the examples seem to be C++ oriented; is it, in fact, a goal for the
This looks like interesting work, and I hope something like this gets
folded into a release soon. A few things occurred to me when reading
the writeup at google (sorry, I haven't started looking through the
code much yet):
All the examples seem to be C++ oriented; is it, in fact, a goal
Tom,
Thanks a lot for pointing us to the sparse annotations. We will take a
look and see what its support looks like.
Le-chun
On Sun, Jun 15, 2008 at 2:43 PM, Tom Tromey [EMAIL PROTECTED] wrote:
Le-Chun == Le-Chun Wu [EMAIL PROTECTED] writes:
Le-Chun Here is the design doc for the proposed
Le-Chun == Le-Chun Wu [EMAIL PROTECTED] writes:
Le-Chun Here is the design doc for the proposed annotations:
Le-Chun http://docs.google.com/Doc?id=ddqtfwhb_0c49t6zgr
I am curious to know how this compares to the kind of lock checking
implemented in sparse, and in particular whether sparse
You are right that our current proposal/implementation doesn't handle
indirect function calls. (And we didn't try to do any pointer/alias
analysis for variables either in our first implementation .) But the
analysis will not be disabled completely if it encounters an indirect
function call. It
Hi,
We have been working on creating program annotations for C/C++ (in GCC
attributes) to help developers document locks and how they need to be
used to safely read and write shared variables in multi-threaded code.
We've also implemented a new GCC pass that uses the annotations to
identify and
Le-Chun Wu [EMAIL PROTECTED] writes:
Please let me know if you have any feedback/comments/questions on the
proposed annotations and the GCC implementation.
I was surprised that there was no consideration of C indirect function
calls in your design document. e.g. I would have expect some way
to
