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
http://asimplediscipleslife.blogsp
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 CXX=c
On Fri, Jan 04, 2013 at 01:45:11PM +0530, Marc-André Laverdière
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 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 CXX=c
@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.
Maybe
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 fa
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 Antl
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 t
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 wo
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
> rewri
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
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
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
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 advant
Hi Marc,
On Thu, 2012-12-13 at 02:09 -0500, Marc-André Laverdière wrote:
> I feel that this behavior of SvStream not to change the parameter in
> case of a broken stream should be changed. I am not sure why that is
> there.
Well - it is -thought- (but hard to prove) that this behaviour is
My reply was accidentally sent to Michael Stahl only. Ooops.
I feel that this behavior of SvStream not to change the parameter in
case of a broken stream should be changed. I am not sure why that is
there.
I have a partial change to that that I am attaching for review. I am
not getting the logic
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)
wel
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 t
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
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 Mon, Dec 10, 2012 at 6:08 PM, Eike Rathke 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( ! (*stream>>meh))
>> {
>> /* error */
>> }
>> ...
>>
>> iow the >> operator return a boolea
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( ! (*stream>>meh))
> {
> /* error */
> }
> ...
>
> iow the >> operator return a boolean that indicate the sucess or
> failure of the >> operation...
No
On Mon, Dec 10, 2012 at 3:41 PM, Michael Meeks 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 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:
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 excepti
26 matches
Mail list logo
