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
> anno
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 fo
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
> "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 sp
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 simp
"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
