On Fri, Jan 04, 2013 at 01:45:11PM +0530, Marc-André Laverdière
marcandre.laverdi...@gmail.com wrote:
/usr/include/clang/Basic/LLVM.h:20:10: fatal error:
'llvm/Support/Casting.h' file not found
Do you have llvm-devel (or equivalent) installed?
signature.asc
Description: Digital signature
On 30/12/12 15:41, Marc-André Laverdière wrote:
@Lubos. I started writing a plug-in. I have a problem with compiling,
however. It somehow doesn't find the headers on my system.
This is the autogen.sh I use (I tried with and without --includedir,
and --includedir=/usr/)
./autogen.sh CC=clang
Aaah, that is what was missing. I would've expected that to be
installed with the clang development packages as a dependency. Thanks!
Marc-André LAVERDIÈRE
Perseverance must finish its work so that you may be mature and complete,
not lacking anything. -James 1:4
On Sunday 30 of December 2012, Marc-André Laverdière wrote:
I know that C++ is an horrible monster to parse. My question was why
pick a tool over another.
Maybe the JavaCC or Antlr grammars are not very good. Maybe the
Phoenix framework doesn't work for some variants of C++ we care about.
On 30/12/12 15:41, Marc-André Laverdière wrote:
@Lubos. I started writing a plug-in. I have a problem with compiling,
however. It somehow doesn't find the headers on my system.
This is the autogen.sh I use (I tried with and without --includedir,
and --includedir=/usr/)
./autogen.sh CC=clang
@Michael. I am studying in a software reegineering lab - I do have a
small clue ;) We had a Masters' student who implemented his own C
grammar. 3 months of work for one bullet in one slide. No fun.
I know that C++ is an horrible monster to parse. My question was why
pick a tool over another.
Looking at it, it reminds me of JavaCC visitors - I was expecting
something a tad bit more complex.
Since we don't have flow analysis at that level, we may have some
erroneous results, but I'm guessing we'll have accuracy in the 90%
range.
Tell me, why Clang then? Is it because the JavaCC or
On 22/12/12 12:53, Marc-André Laverdière wrote:
Tell me, why Clang then? Is it because the JavaCC or Antlr grammars
weren't good enough?
uhm... have you ever tried to write a C++ parser? reinventing that
wheel takes man-years (or perhaps man-decades) of effort to get right...
this and the
On Saturday 15 of December 2012, Marc-André Laverdière wrote:
Sounds to me like a big learning curve is involved - which is going to
be very distracting from research activities.
Depends. It is something new to learn, but the API is rather intuitive.
If someone can give me link to a good
On Thu, 2012-12-13 at 14:00 +0100, Lubos Lunak wrote:
I think it shouldn't be that difficult to write a Clang plugin that finds
all
uses of SvStream::operator/ , checks whether the variable read to is
initalized [*] , and possibly it shouldn't be even that big deal to have it
rewrite
Sounds to me like a big learning curve is involved - which is going to
be very distracting from research activities.
If someone can give me link to a good tutorial that gives me a good
feeling about it I may bite.
(But I can still change code in the filters manually - the thing is
that mindless
That's the problem... what we don't know can be hurting us big time.
And since the tests are not very thorough, I can't have a good
confidence that things are not broken.
So, either we finish this patch and hope people will pick up those
cases along the way - a risky proposal but it has the
Hi Marc,
On Thu, 2012-12-13 at 06:10 -0500, Marc-André Laverdière wrote:
That's the problem... what we don't know can be hurting us big time.
And since the tests are not very thorough, I can't have a good
confidence that things are not broken.
Of course.
So, either we finish this
On Thu, 2012-12-13 at 09:40 +, Michael Meeks wrote:
Well - it is -thought- (but hard to prove) that this behaviour is
relied on by the code in a number of places:
I know of one (it could be the only one) place in
WW8ScannerBase::OpenPieceTable in sw/source/filter/ww8/ww8scan.cxx
On Thursday 13 of December 2012, Michael Meeks wrote:
Personally, I don't see a clean solution beyond reading each of the
call sites to those operators. If we want to take the risk of busting
things - personally I'd prefer zeroing the data: it has a much lower
risk/down-side as far as I
On 12/11/2012 11:11 AM, Michael Meeks wrote:
On Tue, 2012-12-11 at 09:39 +0100, Stephan Bergmann wrote:
On 12/10/2012 10:41 PM, Michael Meeks wrote:
On Mon, 2012-12-10 at 10:27 -0500, Marc-André Laverdière wrote:
I am doing some proactive hardening of the image filters these days,
and I have
On 11/12/12 15:57, Stephan Bergmann wrote:
Exceptions are certainly no silver bullet (semantically they are
~equivalent to encoding exception information in function return values
and explicitly handling those return values accordingly, so the endemic
bloat claim meets skepticism)
well in
On Mon, Dec 10, 2012 at 6:08 PM, Eike Rathke er...@redhat.com wrote:
Hi Norbert,
On Monday, 2012-12-10 17:38:34 -0600, Norbert Thiebaud wrote:
Am I thinking of something else or the current syntax is:
if( ! (*streammeh))
{
/* error */
}
...
iow the operator return a boolean that
On 12/10/2012 10:41 PM, Michael Meeks wrote:
On Mon, 2012-12-10 at 10:27 -0500, Marc-André Laverdière wrote:
I am doing some proactive hardening of the image filters these days,
and I have to say that there is a lot of code like this:
*stream meh;
Which is IMHO intrinsically broken;
On Tue, 2012-12-11 at 09:39 +0100, Stephan Bergmann wrote:
On 12/10/2012 10:41 PM, Michael Meeks wrote:
On Mon, 2012-12-10 at 10:27 -0500, Marc-André Laverdière wrote:
I am doing some proactive hardening of the image filters these days,
and I have to say that there is a lot of code like
Hello everyone,
I am doing some proactive hardening of the image filters these days,
and I have to say that there is a lot of code like this:
*stream meh;
if (! stream-good())
return sal_False;
It is very cluttered to do this for _every_ read.
A simpler way would be to have opt-in exception
Hi Marc,
On Mon, 2012-12-10 at 10:27 -0500, Marc-André Laverdière wrote:
I am doing some proactive hardening of the image filters these days,
and I have to say that there is a lot of code like this:
*stream meh;
Which is IMHO intrinsically broken; I'd prefer to see that as:
On Mon, Dec 10, 2012 at 3:41 PM, Michael Meeks michael.me...@suse.com wrote:
Hi Marc,
On Mon, 2012-12-10 at 10:27 -0500, Marc-André Laverdière wrote:
I am doing some proactive hardening of the image filters these days,
and I have to say that there is a lot of code like this:
*stream meh;
Hi Norbert,
On Monday, 2012-12-10 17:38:34 -0600, Norbert Thiebaud wrote:
Am I thinking of something else or the current syntax is:
if( ! (*streammeh))
{
/* error */
}
...
iow the operator return a boolean that indicate the sucess or
failure of the operation...
No, all overloads
24 matches
Mail list logo
