bearophile wrote:
> Then in C++ the syntax of final class is not nice:
> class __attribute__((user("final"))) MyClass {
To be pedantic, C++ does not have final classes. That's a compiler
extension.
Ali
Fri, 12 Feb 2010 12:07:16 -0500, bearophile wrote:
> /**
> * Helper function: returns true if a class is marked with the "final"
> attribute. */
> function isFinal(c) {
> if (!c.attributes)
> return false;
> for each (let a in c.attributes)
> if (a.name == 'user' && a.value == 'final
I've just found a nice article about this topic, "LCA: Static analysis with GCC
plugins", by Jonathan Corbet:
http://lwn.net/Articles/370717/
Beside allowing plug-ins, they have done something else to GCC:
>The ability to attach attributes to objects in the compiled code makes it easy
>to pass h
Thu, 11 Feb 2010 16:20:55 -0500, bearophile wrote:
> dennis luehring:
>> but how should the plugin-system work?
>
> I am ignorant still about type systems. But see something about
> pluggable type systems: http://lambda-the-ultimate.org/node/1311
In some educational Compiler Done Right (tm) proj
dennis luehring:
> but how should the plugin-system work?
I am ignorant still about type systems. But see something about pluggable type
systems:
http://lambda-the-ultimate.org/node/1311
>what do the LLVM-guys think about plugin like that<
Chris Lattner, the boss of the LLVM project, has told
Walter Bright, el 10 de febrero a las 14:28 me escribiste:
> Leandro Lucarella wrote:
> >This supposedly "safe" program under Mac OS X 10.6 doesn't give any error
> >neither at compile time nor at runtime, yet it isn't memory-safe at all as
> >it corrupts some part of the memory space.
>
> @safe i
Michel Fortin wrote:
On 2010-02-10 22:54:40 -0500, Ary Borenszweig said:
Ary Borenszweig wrote:
Michel Fortin wrote:
unittest {
NonNullable!Object o;
Here o is null.
Sorry, just read the class comments. But if this can't be implemented
without compiler support... then it's not of mu
There's another solution: to make D2/D3 itself flexible enough that you can implement
your own simple "extensions" to the type system, so you
>can actually implement not-nullable references by default. This isn't
impossible (there are many papers about this,
>it can be done in Scheme, etc).
"e
Ary Borenszweig:
>But if this can't be implemented without compiler support... then it's not of
>much use. :-(<
There's another solution: to make D2/D3 itself flexible enough that you can
implement your own simple "extensions" to the type system, so you can actually
implement not-nullable refe
Wed, 10 Feb 2010 23:11:54 -0800, Walter Bright wrote:
> Nick Sabalausky wrote:
>> I was assuming he meant cost of implementing that feature, but maybe
>> you're right...?
>
> I meant the cost to the user.
The fact is that some of the references in a correct program are non-
nullable. If the prog
Nick Sabalausky wrote:
I was assuming he meant cost of implementing that feature, but maybe you're
right...?
I meant the cost to the user.
"bearophile" wrote in message
news:hkv7u7$1a3...@digitalmars.com...
> Walter Bright:
>
> [about non-nullable types]
>> It's a benefit/cost issue. There are no bug-preventing features that are
>> without cost, the idea is to maximize the ratio.
>
> It surely has a cost (you can see it in the Cyclo
On 2010-02-10 22:54:40 -0500, Ary Borenszweig said:
Ary Borenszweig wrote:
Michel Fortin wrote:
unittest {
NonNullable!Object o;
Here o is null.
Sorry, just read the class comments. But if this can't be implemented
without compiler support... then it's not of much use. :-(
To recap
Ary Borenszweig wrote:
Michel Fortin wrote:
unittest {
NonNullable!Object o;
Here o is null.
Sorry, just read the class comments. But if this can't be implemented
without compiler support... then it's not of much use. :-(
Michel Fortin wrote:
unittest {
NonNullable!Object o;
Here o is null.
NonNullable!ClassInfo o2 = o.classinfo;
NonNullable!TypeInfo o3;
//NonNullable!Object o4 = o2; // FIXME: polymorphic NonNullable
o = new Object;
o = o2;
try {
o = o3; // should throw
On 2010-02-10 17:29:09 -0500, Walter Bright said:
retard wrote:
What exactly is the cost here? The non-nullability invariant can be
checked on compile time. It incurs no runtime overhead. Also the
notation can be quite terse, as we have seen in Other Languages(tm).
If you want, you can crea
retard wrote:
What exactly is the cost here? The non-nullability invariant can be
checked on compile time. It incurs no runtime overhead. Also the notation
can be quite terse, as we have seen in Other Languages(tm).
If you want, you can create a template NonNullable that wraps an
existing typ
Leandro Lucarella wrote:
This supposedly "safe" program under Mac OS X 10.6 doesn't give any error
neither at compile time nor at runtime, yet it isn't memory-safe at all as
it corrupts some part of the memory space.
@safe is in its infancy, and I expect there to be some gaps. We'll get
them
Walter Bright, el 10 de febrero a las 11:33 me escribiste:
> retard wrote:
> >Tue, 09 Feb 2010 18:49:31 -0800, Walter Bright wrote:
> >
> >>D has moved a lot towards supplying by default a lot of what Coverity
> >>claims to do. By making such an expensive tool irrelevant for D, we can
> >>make D mu
Wed, 10 Feb 2010 12:47:41 -0800, Walter Bright wrote:
> Nick Sabalausky wrote:
>> "Walter Bright" wrote in message
>> news:hkv1mg$s6...@digitalmars.com...
>>> retard wrote:
Tue, 09 Feb 2010 18:49:31 -0800, Walter Bright wrote:
> D has moved a lot towards supplying by default a lot o
Walter Bright:
[about non-nullable types]
> It's a benefit/cost issue. There are no bug-preventing features that are
> without cost, the idea is to maximize the ratio.
It surely has a cost (you can see it in the Cyclone language: it's safe but
quite fussy, so the costs for the programmer can be
"retard" wrote in message
news:hkv5op$s4...@digitalmars.com...
> Wed, 10 Feb 2010 15:29:06 -0500, Nick Sabalausky wrote:
>
>> "Walter Bright" wrote in message
>> news:hkv1mg$s6...@digitalmars.com...
>>>
>>> Yes, there have been a couple long threads about that. Dereferencing a
>>> null pointer i
Nick Sabalausky wrote:
"Walter Bright" wrote in message
news:hkv1mg$s6...@digitalmars.com...
retard wrote:
Tue, 09 Feb 2010 18:49:31 -0800, Walter Bright wrote:
D has moved a lot towards supplying by default a lot of what Coverity
claims to do. By making such an expensive tool irrelevant for
Wed, 10 Feb 2010 15:29:06 -0500, Nick Sabalausky wrote:
> "Walter Bright" wrote in message
> news:hkv1mg$s6...@digitalmars.com...
>> retard wrote:
>>> Tue, 09 Feb 2010 18:49:31 -0800, Walter Bright wrote:
>>>
D has moved a lot towards supplying by default a lot of what Coverity
claims t
"Walter Bright" wrote in message
news:hkv1mg$s6...@digitalmars.com...
> retard wrote:
>> Tue, 09 Feb 2010 18:49:31 -0800, Walter Bright wrote:
>>
>>> D has moved a lot towards supplying by default a lot of what Coverity
>>> claims to do. By making such an expensive tool irrelevant for D, we can
>
retard wrote:
Tue, 09 Feb 2010 18:49:31 -0800, Walter Bright wrote:
D has moved a lot towards supplying by default a lot of what Coverity
claims to do. By making such an expensive tool irrelevant for D, we can
make D much more cost effective.
D doesn't provide non-nullable types
Yes, there
Tue, 09 Feb 2010 18:49:31 -0800, Walter Bright wrote:
> D has moved a lot towards supplying by default a lot of what Coverity
> claims to do. By making such an expensive tool irrelevant for D, we can
> make D much more cost effective.
D doesn't provide non-nullable types and local refs can still
Walter Bright wrote:
bearophile wrote:
But there are many C++ programmers that don't use exceptions, for
example they are not allowed in Google C++ code:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions
So surely not 100% of D code will use exceptions. That's why I ha
"Michel Fortin" wrote in message
news:hkt3gq$19p...@digitalmars.com...
> On 2010-02-09 19:26:05 -0500, bearophile said:
>
>> Walter Bright:
>>> I don't know why Google proscribes exceptions,
>>
>> If you look at that link, and you click on the arrow, you will see a nice
>> list of pro-cons :-)
Brad Roberts wrote:
Nice black and white world you are acting like you live in there Walter.
I know you know better, so why do you pretend otherwise?
First off, yes, if you program in C style, despite using D, your code is
vulnerable to many of the problems that Coverity detects.
You're ass
On Tue, 9 Feb 2010, Walter Bright wrote:
> @safe guarantees memory safety, so these are non-issues in D.
>
> Using @safe makes these non-issues.
>
> As you say, exceptions solve these problems.
>
> It is a mistake to rely on the GC to free resources other than memory.
> Properly, either RAII or
On 2010-02-09 19:26:05 -0500, bearophile said:
Walter Bright:
I don't know why Google proscribes exceptions,
If you look at that link, and you click on the arrow, you will see a
nice list of pro-cons :-)
And below the pro-cons it says they avoid exceptions because they have
a lot of exce
Walter Bright:
> I don't know why Google proscribes exceptions,
If you look at that link, and you click on the arrow, you will see a nice list
of pro-cons :-)
Bye,
bearophile
sybrandy wrote:
- Use Before Test: here the bugs are in the code paths of the
try-except.
Not sure what this means.
If I remember correctly from when I had an opportunity to look at these
types of tools, this is a case where, in C or C++, you have a variable
that may be uninitialized or set
bearophile wrote:
But there are many C++ programmers that don't use exceptions, for
example they are not allowed in Google C++ code:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions
So surely not 100% of D code will use exceptions. That's why I have
said that D avoids
- Use Before Test: here the bugs are in the code paths of the try-except.
Not sure what this means.
If I remember correctly from when I had an opportunity to look at these
types of tools, this is a case where, in C or C++, you have a variable
that may be uninitialized or set to NULL, but you
Walter Bright:
>@safe guarantees memory safety, so these are non-issues in D.<
I think people want to use D instead of Java/C# for (when necessary) its lower
level features, because if they don't need that extra little percentage of
performance they probably want to use Java/C# in the first pla
bearophile wrote:
Regarding D code:
- Use After Free: probably less common in D code, because
dellocations are done by the GC.
> - Buffer Overflows: less common in D
code because of array bound tests at runtime, and because some string
operations/functions are safer.
@safe guarantees memory
Walter Bright:
>I just think that Coverity doesn't have much use for D code, because what it
>checks for is already covered by the language.<
I have taken a look at this report about bugs found by this tool in open source
code:
http://scan.coverity.com/report/Coverity_White_Paper-Scan_Open_Sour
On 02/09/2010 02:18 PM, Walter Bright wrote:
bearophile wrote:
Walter Bright:
From what I can infer from their various statements, the primary
thing it does is pair functions that must be paired, like
malloc/free, lock/unlock, fopen/fclose, etc.
I have never used their program, and probably I
bearophile wrote:
Walter Bright:
From what I can infer from their various statements, the primary
thing it does is pair functions that must be paired, like
malloc/free, lock/unlock, fopen/fclose, etc.
I have never used their program, and probably I will never buy it,
but I have seen it used tw
Walter Bright:
> From what I can infer from their various statements, the primary thing
> it does is pair functions that must be paired, like malloc/free,
> lock/unlock, fopen/fclose, etc.
I have never used their program, and probably I will never buy it, but I have
seen it used two times on t
Walter Bright wrote:
Coverity's business model seems to be based on being very vague about
what their software actually does,
Found some stuff on the Cert web site:
https://www.securecoding.cert.org/confluence/display/seccode/Coverity+Prevent
bearophile wrote:
Rarely I have found a so fun description of a software, how they can
(barely?) make it a commercial product, the problems they find. The
program is a bug finding tool, for C, C++, Java, C#:
http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-later/fulltext
Rarely I have found a so fun description of a software, how they can (barely?)
make it a commercial product, the problems they find. The program is a bug
finding tool, for C, C++, Java, C#:
http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-later/fulltext
I think it's an inte
45 matches
Mail list logo
