Re: Heartbleed and static analysis

[Paulo Pinto]

Am 13.04.2014 00:10, schrieb froglegs:

  Why do they write such important code in C to begin with? C is garbage
compared to C++.  With C++ they wouldn't need to drop down to raw
pointers and would never have these problems.

(of course D guys will say use D, but lets be real, D isn't ready for
many obvious reasons)


As much as I love to hate C, it won't go away that easily:

- Being married with UNIX and its culture;

- Except for Windows, Android hybrid and RTOS, UNIX is everywhere nowadays

- The macho attitude that pertains C culture that programmers make no errors


This is one of those things that only will go away with a few 
generations, but even the newer generations will need to maintain 
running UNIX systems, thus the circle of doom keeps turning around.


--
Paulo

Re: Heartbleed and static analysis

[Paulo Pinto]

Am 13.04.2014 00:38, schrieb H. S. Teoh:

On Sat, Apr 12, 2014 at 10:10:55PM +, froglegs wrote:

  Why do they write such important code in C to begin with? C is
garbage compared to C++.  With C++ they wouldn't need to drop down to
raw pointers and would never have these problems.

[...]


If you were to ask me 5-10 years ago which language was better, I'd say
C++. Today, I'm not so sure anymore. Both suck. And I'm not sure which
one sucks more -- 5 years ago I'd say C, but now I'm leaning towards
saying C++.

...


20 years ago I would have answered both are bad and Object Pascal/Delphi 
is the way.


Sadly Borland did lots of major screw ups and let the language momentum 
fade away.


C++ provides safer ways to code than C, but it requires competent 
programmers.


However both C and C++ require competent programmers above what the 
market is willing to pay, and on my area switching to C doesn't help 
improve the quality.


Every now and then, I feel nostalgic of not writing C++ or even with my
prejudices C code at work, but then I look at the quality of code that 
gets written in our outsourcing projects and get a relief not having to 
go back into that world.


--
Paulo

Re: Heartbleed and static analysis

[Paolo Invernizzi]

On Saturday, 12 April 2014 at 18:36:19 UTC, Marco Leise wrote:

Am Fri, 11 Apr 2014 09:59:45 +
schrieb "Chris" :

In a way it's scary how vulnerable software we rely on still 
is. I cannot claim that my software is immune to attacks, but 
where security is crucial, one would expect self-critical 
scrutiny rather than complacency. But we're all only human.


+1. My naive assumption was that something like SSH is
implemented once and then bugs are fixed, so it can only ever
become safer. I found it astounding that this library was
totally sane only 2 years ago. One innocent commit is all it
took and it can happen again for any software, any time.
If crackers keep their eyes open they _will_ find their next
backdoor.


I don't remember if this has been already posted here in the 
forum, but I think that this rant of Theo de Raadt about 
heartbleed is _very_ interesting.


http://article.gmane.org/gmane.os.openbsd.misc/211963

TBW, I agree with him: it's not a matter of scrutiny or a matter 
of being human, and the post clarify this very well.

Has anybody tried calling D from Ruby?

[Atila Neves]

The best I could manage was to use the C/C++ API and have that
call the linked in D code by hacking the automatically generated
Makefile. But at least that worked, up to a point. Even though I
linked in Phobos, it crashed when I called writeln (but
core.stdc.stdio.printf was ok).

Trying to use the C API directly from D didn't really work. I
tried dstep on ruby.h and it threw an exception. Ah, macros...

Atila

Re: Has anybody tried calling D from Ruby?

[Jacob Carlborg]

On 2014-04-13 11:20, Atila Neves wrote:

The best I could manage was to use the C/C++ API and have that
call the linked in D code by hacking the automatically generated
Makefile. But at least that worked, up to a point. Even though I
linked in Phobos, it crashed when I called writeln (but
core.stdc.stdio.printf was ok).


I have embedded Ruby in a D application. Called methods in both 
directions. I had no problem. Have a look at this mostly abandoned 
project [1]. The bindings where created from 1.9.1 (ABI version). Here 
[2] are the C bindings and here [3] are some wrappers.



Trying to use the C API directly from D didn't really work. I
tried dstep on ruby.h and it threw an exception. Ah, macros...


Please report an issue. It shouldn't be throwing an exception.

[1] https://github.com/jacob-carlborg/orbit
[2] https://github.com/jacob-carlborg/orbit/tree/master/ruby/c
[3] https://github.com/jacob-carlborg/orbit/tree/master/ruby/core

--
/Jacob Carlborg

Re: Shared Library, that is when ?

[Joakim]

On Saturday, 12 April 2014 at 00:53:27 UTC, bioifornatics wrote:

On Saturday, 12 April 2014 at 00:16:26 UTC, bachmeier wrote:

On Friday, 11 April 2014 at 23:15:13 UTC, bioifornatics wrote:

Dear,

I know vthat D community dev works hard. I would like to know
when provide shared Shared Library will become a priority ?
I know you could say do it ( i know … ) but my job is to 
package

tools. Sorry …
Partial shared lib give too many random bug as this one:
https://github.com/ldc-developers/ldc/issues/596#issuecomment-40141711

Please finish this feature.

Thanks

Kind regards


I use DMD to make shared libraries on Linux all the time. Is 
there a reason you have to use LDC?


Because LDC has a free license that is a nust have to be allowed
to put a package into fedora. ( I package for fedora)


This question belongs in the ldc forum then.  I don't know all 
about how well ldc works with shared libraries on linux, but the 
recent ldc 0.13.0 alpha updates druntime with some better linux 
shared library support.  The commit you mentioned using was 
probably from the older 2.063.2 trunk branch: have you tried the 
newer 2.064.2 branch?

Re: Heartbleed and static analysis

[Michel Fortin]

On 2014-04-13 08:55:53 +, "Paolo Invernizzi" 
 said:


I don't remember if this has been already posted here in the forum, but 
I think that this rant of Theo de Raadt about heartbleed is _very_ 
interesting.


http://article.gmane.org/gmane.os.openbsd.misc/211963

TBW, I agree with him: it's not a matter of scrutiny or a matter of 
being human, and the post clarify this very well.


Interesting. As far as I know, the D GC is also a wrapper around 
malloc, and it will not return memory using free when an object is 
deallocated. That rant could also apply to D.


--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca

gdc 2.064.2 in next Ubuntu LTS

[Iain Buclaw]

Hi,

The next Ubuntu LTS release will include gdc-4.8 using the D 
2.064.2 frontend, and I do not plan to push in any updates other 
than bug fixes.  This may be important to bear in mind, as there 
may be users who choose to use gdc (I hope they do) and may 
develop using this version of D for the next six months, two 
years, or maybe six years depending on how conservative they are.


Oh, and gdc should be coming to ARM in this release too.  :)

Regards
Iain.

Re: gdc 2.064.2 in next Ubuntu LTS

[Rikki Cattermole]

On Sunday, 13 April 2014 at 11:22:46 UTC, Iain Buclaw wrote:

Hi,

The next Ubuntu LTS release will include gdc-4.8 using the D 
2.064.2 frontend, and I do not plan to push in any updates 
other than bug fixes.  This may be important to bear in mind, 
as there may be users who choose to use gdc (I hope they do) 
and may develop using this version of D for the next six 
months, two years, or maybe six years depending on how 
conservative they are.


Oh, and gdc should be coming to ARM in this release too.  :)

Regards
Iain.


Oooo ARM. Any chance for a 'supported' devices(os/cpu) list?
I've heard some interesting things like ARM architecture being
easier than x86 and would love to get into it.

Re: Heartbleed and static analysis

[Dicebot]

On Sunday, 13 April 2014 at 08:55:47 UTC, Paulo Pinto wrote:
20 years ago I would have answered both are bad and Object 
Pascal/Delphi is the way.


Sadly Borland did lots of major screw ups and let the language 
momentum fade away.


Ironically, I have been using Pascal/Delphi at my first 
programming job. Switching later to C was a big relief - yes, it 
was less safe and sometimes awkward. But it did feel like a 
language designed by engineers, not academicians and that alone 
has boosted productivity a lot.

Re: The "@safe vs struct destructor" dilemma

[Dicebot]

On Sunday, 13 April 2014 at 01:30:59 UTC, Nick Sabalausky wrote:

// Note, I meant for trustedWrapperWhatever to be private
// and placed together with doStuff. Obviously not a public
// func provided by foo's author.
@trusted private auto trustedWrapperFoo(...) {...}


Still accessible by other functions in same module unless you 
keep each @trusted function in own module.



--

Then how could this possibly be any better?:

--
@system auto foo() {...}

@trusted void doStuff() {
...stuff...
foo();
...stuff...
}
--

The former contains extra safety checks (ie, for everything in 
"...stuff...") that the latter does not. The former is 
therefore better.


Because @system does not give any guarantees. It is expected by 
type system that calling such function can do anything horrible. 
@trusted, however, is expected to be 100% equivalent to @safe 
with only exception that its safety can't be verified by 
compiler. Any @trusted function from the type system point of 
view can be used in any context where @safe can be used.


It is you personal responsibility as a programmer to verify 100% 
safety of each @trusted function you write, otherwise anything 
can go wrong and writer will be only one to blame.

Re: enum

[Jonathan M Davis]

On Saturday, April 12, 2014 12:19:56 Walter Bright wrote:
> On 4/12/2014 5:59 AM, Jonathan M Davis wrote:
> > And what would the purpose by of giving them their own type?
> 
> We are *really* going around in circles here.

So, it would seem. Clearly, I have a very different viewpoint on what enums 
are supposed to be and do that either you or Andrei (though based on other 
comments in this thread, I don't seem to be alone).

- Jonathan M Davis

Re: enum

[Jonathan M Davis]

On Saturday, April 12, 2014 12:43:32 Andrei Alexandrescu wrote:
> On 4/12/14, 5:59 AM, Jonathan M Davis wrote:
> > If the enum
> > doesn't enumerate all of the values, then you're clearly going to be using
> > other values with it, meaning that any restrictions on setting a variable
> > to those other values is going to be a problem (as is currently the case
> > with enums - assignment and initialization are protected against
> > non-enumerated values). You'd just end up with a enum type which is
> > effectively an alias for the enum's base type except that assigning it
> > non-enumerated values requires casting, and you can overload a function
> > on the enumerated values vs the non- enumerated ones (or at  least,
> > non-enumerated ones which aren't cast to the enum type) by overloading a
> > function on the enum type and its base type - which would be highly
> > bug-prone IMHO.
> 
> Sorry, your speculations are mistaken. The pattern works well and we've
> been using it repeatedly and with good results since C++ introduced
> "enum class".

I would have expected that all of the required casting would be annoying and 
that overloading between the enum and its base type would be error-prone, 
because all you have to do is forget to cast when passing a literal, and you 
end up with the wrong overload being called. But I guess if you view casting 
to the enum type like a constructor, then it makes sense, and apparently, it's 
working for you.

Regardless, I'd never use an enum to partially enumerate values for a type, 
because I think that that violates the very concept of what an enumeration is. 
And I expect that enums get used so frequently in other ways primarily due to 
the fact that C's enums are so weakly typed. I'd use a struct for any case 
where I wanted a new type which didn't have a full enumeration of its values, 
and any constants would probably just be static variables or manifest 
constants on the struct.

So, I'm not at all interested in having D's enum not fully protect against 
having a variable of that enum type end up becoming a non-enumerated value, 
and I don't at all value the ability to have enums which aren't intended to 
enumerate all of their values. But clearly, not everyone agrees on that.

So, if we add final enum, and it properly protects against any operation on a 
variable of that enum type ever becoming a non-enumerated value without a 
cast, and it works with final switch, then great. I won't like what non-final 
enums do, and I'll never use them, but at least then we can have non-buggy 
behavior for enums which are intended to enumerate all of their values.

As it stands, I think that C++'s enum class are better than D's enums, because 
they actually protect against any operations (other than casts) giving the 
enum a non-enumerated value, and Ds enums don't  - though enum classes 
arguably go a bit far, because they don't provide implicit conversions to 
their base type, and you have to overload any operators on the type that you 
want to use. But I'd still rather have that than have to worry about enum 
variables becoming non-enumerated values like we currently have to worry about 
in D - and features like final switch just make it that much worse when an 
enum variable ends up with a non-enumerated value.

- Jonathan M Davis

Re: Heartbleed and static analysis

[Klaim - Joël Lamotte]

On Sun, Apr 13, 2014 at 12:38 AM, H. S. Teoh  wrote:

> C++ is better in theory, but not all that much better than C in
> practice. The design flaws of the language often makes it worse than C
> in terms of maintainability. At my day job, we switched a major project
> from C++ back to C, because the C++ codebase was over-engineered and
> full of abstractions that nobody understood, patched over multiple times
> by people who were reassigned to take the place of the original people
> who left, who didn't understand the original design but had unreasonable
> deadlines to meet, so as a result they just added hacks and workarounds
> to get their job done before they got fired. By the time a few years had
> passed, *nobody* understood what the system even does, and every new
> code change was a "blindly copy-n-paste from other parts of the code and
> pray it won't break something else" deal. It was bloated, slow, and
> riddled with bugs nobody dared to fix, because nobody understood what it
> does. Certain features were dependent on dtor side-effects, and other
> such pathological things, and it was maintenance hell.
>

I don't understand what is the C++ fault when the management of the project
forces people to
write shit. The same situation would have happen with any language and a
full rewrite by a fixed team
would have been better whatever the new language.
I've heard the same story with Java, C# and Python in the last few years.
Always management fault.

I'm not sure I understand the arguments against C++ in your examples, in
particular if you use D which have destructors and "magic" too.

Re: dec64 decimal floating point type

[Francesco Cattoglio]

On Saturday, 12 April 2014 at 21:48:15 UTC, Alix Pexton wrote:

http://dec64.org/

I recently discovered this while watching a presentation by 
Doug Crockford on YouTube.


I know that Dlang is not in the category of languages that this 
new numeric representation is aimed at, but Dlang might well be 
used to implement a VM or compiler for one that is.


I think it is ripe for implementation along the same lines as 
half floats.


The reference implementation is on github (linked from the 
above) and is marked as public domain but porting the assembler 
(or rather the macros) non-trivial with my skill-set.


Anyone else convinced or opposed?

Anyone with more assembler-foo willing to lend a hand to the 
porting effort?


A...


I don't quite see the point in this, when there is already a 
standard for floating point decimals 
http://en.wikipedia.org/wiki/Decimal64_floating-point_format
I really should take a deeper look at this, it might be more 
interesting that I am expecting.

Re: Heartbleed and static analysis

[Walter Bright]

On 4/13/2014 5:57 AM, Dicebot wrote:

Ironically, I have been using Pascal/Delphi at my first programming job.
Switching later to C was a big relief - yes, it was less safe and sometimes
awkward. But it did feel like a language designed by engineers, not academicians
and that alone has boosted productivity a lot.


I had the same feeling switching from Pascal to C. I was far more productive in 
C right off the bat. I never looked back, never wrote another line of Pascal.

Re: Heartbleed and static analysis

[Dicebot]

On Sunday, 13 April 2014 at 15:17:30 UTC, Klaim - Joël Lamotte 
wrote:
I don't understand what is the C++ fault when the management of 
the project

forces people to
write shit. The same situation would have happen with any 
language and a

full rewrite by a fixed team
would have been better whatever the new language.
I've heard the same story with Java, C# and Python in the last 
few years.

Always management fault.

I'm not sure I understand the arguments against C++ in your 
examples, in

particular if you use D which have destructors and "magic" too.


C++ fault is that it makes very easy even for experienced 
programmer to write faulty code and consequences of a mistake can 
be rather dire. C has similar issues but C is much smaller and 
simpler language which allows to keep all possible danger points 
in mind. I have yet to meet a single C++ programmer who can 
remember about all corner cases at the same time. I am not sure 
even Bjorne himself can.


D makes situation much better by refining base semantics to 
adhere "safe by default, fast when explicitly asked" principle 
(array bounds checks, default initialization of locals). It is 
still not 100% consistent but greatly reduces stress of the 
context comparing to C++.


I'd still prefer C++ over C for most projects but only if using 
very small well-defined  subset of C++ verified by static 
analysis tool continuously.

Re: Heartbleed and static analysis

[Walter Bright]

On 4/13/2014 4:04 AM, Michel Fortin wrote:

Interesting. As far as I know, the D GC is also a wrapper around malloc, and it
will not return memory using free when an object is deallocated. That rant could
also apply to D.


You're right in that a malloc debugger would be ineffective when the D GC is 
used. But the D GC offers its own memory debugging features. They can be turned 
on with version identifiers in the GC source.

Re: Heartbleed and static analysis

[Walter Bright]

On 4/13/2014 9:26 AM, Dicebot wrote:

C++ fault is that it makes very easy even for experienced programmer to write
faulty code and consequences of a mistake can be rather dire. C has similar
issues but C is much smaller and simpler language which allows to keep all
possible danger points in mind. I have yet to meet a single C++ programmer who
can remember about all corner cases at the same time. I am not sure even Bjorne
himself can.

D makes situation much better by refining base semantics to adhere "safe by
default, fast when explicitly asked" principle (array bounds checks, default
initialization of locals). It is still not 100% consistent but greatly reduces
stress of the context comparing to C++.

I'd still prefer C++ over C for most projects but only if using very small
well-defined  subset of C++ verified by static analysis tool continuously.


Interestingly, I've been seeing that what makes D code much more robust is a 
consequence of 'unittest' coupled with -cov.

Re: Heartbleed and static analysis

[Dicebot]

On Sunday, 13 April 2014 at 17:31:17 UTC, Walter Bright wrote:
Interestingly, I've been seeing that what makes D code much 
more robust is a consequence of 'unittest' coupled with -cov.


It is big deal breaker for personal projects and open-source 
collaboration. For big private projects agreeing on single 
testing framework and adding one of coverage analyzers to the CI 
is not that much of a problem. Convenient, but not a deal breaker 
over C++.


But being less afraid to actually write code because of more 
powerful type system and safer defaults - this is huge.


I think most important thing about built-in unittests is how this 
feature encourages to add tests when contributing to projects 
that don't currently have any real coverage. It becomes so easy 
that there is not reason to not do it and this help open-source a 
lot.

Re: Heartbleed and static analysis

[Andrej Mitrovic]

On Sunday, 13 April 2014 at 17:31:17 UTC, Walter Bright wrote:
Interestingly, I've been seeing that what makes D code much 
more robust is a consequence of 'unittest' coupled with -cov.


Built-in unittests are the best thing since jet engines.

Re: Heartbleed and static analysis

[Paulo Pinto]

Am 13.04.2014 14:57, schrieb Dicebot:

On Sunday, 13 April 2014 at 08:55:47 UTC, Paulo Pinto wrote:

20 years ago I would have answered both are bad and Object
Pascal/Delphi is the way.

Sadly Borland did lots of major screw ups and let the language
momentum fade away.


Ironically, I have been using Pascal/Delphi at my first programming job.
Switching later to C was a big relief - yes, it was less safe and
sometimes awkward. But it did feel like a language designed by
engineers, not academicians and that alone has boosted productivity a lot.


Different experiences I guess. I never felt C made me productive in any way.

Re: dec64 decimal floating point type

[Alix Pexton]

On 13/04/2014 4:29 PM, Francesco Cattoglio wrote:


I don't quite see the point in this, when there is already a standard
for floating point decimals
http://en.wikipedia.org/wiki/Decimal64_floating-point_format
I really should take a deeper look at this, it might be more interesting
that I am expecting.


The talk I watched only touched on the motivation for a new format very 
briefly, but the gist was that the existing offerings were too 
computationally expensive to emulate in software and hardware support is 
not forthcoming. My understanding is that this format is designed around 
what can be done efficiently with the instructions that are available in 
hardware today.


A...

Re: Heartbleed and static analysis

[Walter Bright]

On 4/13/2014 10:38 AM, Dicebot wrote:

I think most important thing about built-in unittests is how this feature
encourages to add tests when contributing to projects that don't currently have
any real coverage. It becomes so easy that there is not reason to not do it and
this help open-source a lot.


Exactly. You can do unittests with other languages, too, but having it be so 
convenient, and no arguments about which unittest tool, is a game changer. The 
built-in -cov is also a game changer.

Re: Heartbleed and static analysis

[Paulo Pinto]

Am 13.04.2014 20:40, schrieb Walter Bright:

On 4/13/2014 10:38 AM, Dicebot wrote:

I think most important thing about built-in unittests is how this feature
encourages to add tests when contributing to projects that don't
currently have
any real coverage. It becomes so easy that there is not reason to not
do it and
this help open-source a lot.


Exactly. You can do unittests with other languages, too, but having it
be so convenient, and no arguments about which unittest tool, is a game
changer. The built-in -cov is also a game changer.


Until one gets lousy management in the picture. :(

Sorry, just got a lousy week with developers deleting unit tests to 
"improve" their builds.


--
Paulo

Re: Shared Library, that is when ?

[David Nadlinger]

On Sunday, 13 April 2014 at 10:00:56 UTC, Joakim wrote:
This question belongs in the ldc forum then.  I don't know all 
about how well ldc works with shared libraries on linux, but 
the recent ldc 0.13.0 alpha updates druntime with some better 
linux shared library support.  The commit you mentioned using 
was probably from the older 2.063.2 trunk branch: have you 
tried the newer 2.064.2 branch?


Somebody needs to sit down and iron out the kinks in either case. 
The problem of shared library loading is complex enough that 
Martin's implementation likely won't "just work".


David

Re: enum

[Shammah Chancellor]

On 2014-04-08 19:08:46 +, Andrei Alexandrescu said:


The current design is loose enough to accommodate all of the above 
uses, probably too loose because it allows a bunch of nonsensical code 
to compile. There are several questions to ask ourselves:


Andrei


Can we step off the trying to prevent nonsensical code from compiling 
thing?   Anything that's turing complete will allow nonsensical code to 
run.   I'd rather have static analysis tools that issue warnings which 
are supressable.   The whole thing with @safe and shared makes a lot of 
sensical code NOT compile without atrocious workarounds.


-S.

Re: gdc 2.064.2 in next Ubuntu LTS

[Iain Buclaw]

On 13 April 2014 12:22, Iain Buclaw  wrote:
> Hi,
>
> The next Ubuntu LTS release will include gdc-4.8 using the D 2.064.2
> frontend, and I do not plan to push in any updates other than bug fixes.
> This may be important to bear in mind, as there may be users who choose to
> use gdc (I hope they do) and may develop using this version of D for the
> next six months, two years, or maybe six years depending on how conservative
> they are.
>

By way of example, I've been trying to use dub to track down some
ICE's however I don't even get that far as it seems that vibe.d has
broken backwards compatibility with 2.064.2.

Regards
Iain.

Re: gdc 2.064.2 in next Ubuntu LTS

[Dicebot]

On Sunday, 13 April 2014 at 21:22:53 UTC, Iain Buclaw wrote:
By way of example, I've been trying to use dub to track down 
some
ICE's however I don't even get that far as it seems that vibe.d 
has

broken backwards compatibility with 2.064.2.

Regards
Iain.


Usually vibe.d maintains compatibility with latest DMD frontend 
version and one before it. So either you are trying to use vibe.d 
master or can file 2.064.2 compatibility issue as a bug :)

Re: gdc 2.064.2 in next Ubuntu LTS

[Iain Buclaw]

On 13 April 2014 22:39, Dicebot  wrote:
> On Sunday, 13 April 2014 at 21:22:53 UTC, Iain Buclaw wrote:
>>
>> By way of example, I've been trying to use dub to track down some
>> ICE's however I don't even get that far as it seems that vibe.d has
>> broken backwards compatibility with 2.064.2.
>>
>> Regards
>> Iain.
>
>
> Usually vibe.d maintains compatibility with latest DMD frontend version and
> one before it. So either you are trying to use vibe.d master or can file
> 2.064.2 compatibility issue as a bug :)

Actually, it might be me!  GDC doesn't differentiate between warning
and deprecations in its diagnostics, so if -Werror is turned on, all
deprecations are errors by default.

Re: gdc 2.064.2 in next Ubuntu LTS

[Joseph Rushton Wakeling]

On 13/04/14 13:22, Iain Buclaw wrote:

The next Ubuntu LTS release will include gdc-4.8 using the D 2.064.2 frontend,
and I do not plan to push in any updates other than bug fixes.  This may be
important to bear in mind, as there may be users who choose to use gdc (I hope
they do) and may develop using this version of D for the next six months, two
years, or maybe six years depending on how conservative they are.

Oh, and gdc should be coming to ARM in this release too.  :)


Thanks and congratulations, Iain.  That's great news to hear. :-)

Re: enum

[Andrei Alexandrescu]

On 4/12/14, 8:15 PM, deadalnix wrote:

On Saturday, 12 April 2014 at 19:43:30 UTC, Andrei Alexandrescu wrote:

Sorry, your speculations are mistaken. The pattern works well and
we've been using it repeatedly and with good results since C++
introduced "enum class".



Can you provide a sample code so we understand what you are talking
about ? It do not seems to me that enum classes defeat Jonathan point,
but I may be wrong.


The UserID example is a good one. You need to cast a couple of times 
when doing I/O, then passing user IDs around is nice because no other 
integers can be passed instead.


Andrei

on interfacing w/C++

[Ellery Newcomer]

(Putting this out there because it sounds like I'm going to get 
scooped in the near future)


So last week I was dinking around with the idea of a library to 
support calling C++ functions. So I wrote some ct code to emulate 
g++ 4.8.2's mangling scheme, and wrote a bit more code to wrap 
it, and calling conventions seemed to work out, and this is what 
I got:


for the C++:

class X {
public:
int i;

X();
int y();
void z(int j);

static int abu(int j);
};

do this:

mixin CppClass!("X",
typeof(new class {
int i;
int y();
void z(int j);

static int abu(int j);
}));
mixin(X.Externs); // waa, issue 12575


it generates something like

struct X {
int i;
int y() {
return _ZN1X1yEv(&this);
}
void z(int j) {
_ZN1X1zEi(&this, j);
}
static int abu(int j) {
return _ZN1X3abuEi(j);
}
}
extern(C) int _ZN1X1yEv(X*);
extern(C) void _ZN1X1zEi(X*,int);
extern(C) int _ZN1X3abuEi(int);


And it all seems to work. pointer params, reference params, 
variadic params, operators, templates all seem within ready reach.


virtual functions are going to be difficult - I guess you'd have 
to have a complete and accurate list of all fields in the class 
and all its superclasses. And all virtual functions. But g++ 
inserts a vtable symbol for classes with virtual functions - does 
anyone know what the heck that is?


Same for constructing a C++ object from within D - you need a 
valid sizeof.


other compilers won't work as above, the mangling scheme used by 
eg DMC doesn't produce valid D identifiers. Is there a pragma or 
anything to get around this?


And I totally spaced on exceptions until I looked on this forum a 
few minutes ago.


So my plan is to get all these bits implemented, then build a 
tool to validate the C++ and D sides match up, then build a tool 
to generate the D side from C++ headers. And then start expanding 
the list of supported C++ compilers.


Does this sound like a reasonable project? The points of concern 
I am worried about most are:


safety associated with supporting virtual functions
if a c++ mangler is stateful, that would shut me down pretty 
quick.
it requires the C++ compiler/version be specified at a library 
level

exceptions probably won't work

Re: enum

[Andrei Alexandrescu]

On 4/13/14, 12:24 PM, Shammah Chancellor wrote:

On 2014-04-08 19:08:46 +, Andrei Alexandrescu said:


The current design is loose enough to accommodate all of the above
uses, probably too loose because it allows a bunch of nonsensical code
to compile. There are several questions to ask ourselves:

Andrei


Can we step off the trying to prevent nonsensical code from compiling
thing?


We shouldn't.


Anything that's turing complete will allow nonsensical code to
run.   I'd rather have static analysis tools that issue warnings which
are supressable.   The whole thing with @safe and shared makes a lot of
sensical code NOT compile without atrocious workarounds.


Yah, that's what makes type system design difficult.


Andrei

Re: gdc 2.064.2 in next Ubuntu LTS

[Andrei Alexandrescu]

On 4/13/14, 4:22 AM, Iain Buclaw wrote:

Hi,

The next Ubuntu LTS release will include gdc-4.8 using the D 2.064.2
frontend, and I do not plan to push in any updates other than bug
fixes.  This may be important to bear in mind, as there may be users who
choose to use gdc (I hope they do) and may develop using this version of
D for the next six months, two years, or maybe six years depending on
how conservative they are.

Oh, and gdc should be coming to ARM in this release too.  :)

Regards
Iain.


Fantastic, congratulations!! -- Andrei

Re: Fwd: confirm 9a85e83e9531356d37cfd8581573d167b99c16f8

[Manu]

On 13 April 2014 12:02, Adam D. Ruppe  wrote:

> On Saturday, 12 April 2014 at 21:18:26 UTC, Nick Sabalausky wrote:
>
>> Never storing or transmitting password in plain text is not only basic,
>> obvious and to be expected, but it is THE most basic, obvious and
>> to-be-expected principle that exists in computer security.
>>
>
> ... and it is also the most common way passwords are sent in internet
> protocols.
>
> * SMTP and HTTP will base64 encode it with their basic auth but that's it
>
> * web sites typically transmit it completely open
>
>
> There's SSL now that gets more traction, but if you expect a password NOT
> to be sent in something trivially converted to plain text, wake up an smell
> the RFC.
>

There's been a migration of responsible services to https, but even without
that, I consider that a different level of negligence.
The difference is, someone has to be actively monitoring me to capture my
password in flight; if I'm a deliberate target, they'll get me somehow
anyway.
This is passive, it's _storing_ a large number of users passwords all
together in one big plain-text blob. It's basically asking to be collected.
There's no transience, I'm compromised even if I'm not a target, and even
if I don't log on. My involvement is not required.

Stilhaus Kitchens Reviews

[sitcruth]

What a great forum this is. Full of fantastic tips and
information. So glad I found it.



[url=http://www.stilhausekitchens.co.uk]Stilhaus Kitchens
Reviews[/url]

Re: enum

[Ola Fosheim Grøstad]

On Sunday, 13 April 2014 at 13:50:14 UTC, Jonathan M Davis wrote:
Regardless, I'd never use an enum to partially enumerate values 
for a type,
because I think that that violates the very concept of what an 
enumeration is.


Then you cannot write forward compatible code without creating 
lots of unused enum values, but I guess that is a reasonable 
tradeoff.


And I expect that enums get used so frequently in other ways 
primarily due to

the fact that C's enums are so weakly typed.


No, it was recommended as a better way to create integer 
constants than #define. Older codebases use #define more.


Ola.

Where the error ? (!=) (<>)

[sdvcn]

dstring key = "<"d;
dstring str = "<盗墓笔记>"d;

for(size_t i;i ta)// Should return false
if(t != ta)// Should return false
{
// All returns true ?
bh = false;
i += key.length;
break;
};
}
}

"if(t <> ta)" No right to judge
"if(t != ta)" No right to judge

Bug? Please compile the code "DMD32 D Compiler v2.065"

[sdvcn]

"DMD32 D Compiler v2.065
Copyright (c) 1999-2013 by Digital Mars written by Walter Bright
Documentation: http://dlang.org/";

code:


import std.stdio;

int main(string[] argv)
{
bool  bh ;
int ll;
for(size_t n;n<99;n++)
{
int a= 5;
int b = 5;

auto r = (a != b);  // return r:false

if(a != b)
{
ll = 55;
bh = false;// Are executed at any time ??
//i+=
//break;
}
}

writeln("ll:",ll);
writeln("bh:",bh);
return 0;
}

return :
ll:0
bh:false

Re: Bug? Please compile the code "DMD32 D Compiler v2.065"

[Adam D. Ruppe]

On Monday, 14 April 2014 at 03:13:31 UTC, sdvcn wrote:

bh = false;// Are executed at any time ??


That's never executed, but bh is automatically initialized to 
false when you declare it which is why you get bh:false at the 
end.

Re: Bug? Please compile the code "DMD32 D Compiler v2.065"

[sdvcn]

On Monday, 14 April 2014 at 03:17:54 UTC, Adam D. Ruppe wrote:

On Monday, 14 April 2014 at 03:13:31 UTC, sdvcn wrote:

bh = false;// Are executed at any time ??


That's never executed, but bh is automatically initialized to 
false when you declare it which is why you get bh:false at the 
end.


sorry,I made a mistake should be

Re: Where the error ? (!=) (<>)

[sdvcn]

On Monday, 14 April 2014 at 02:38:17 UTC, sdvcn wrote:


dstring key = "<"d;
dstring str = "<盗墓笔记>"d;

for(size_t i;i ta)// Should return false
if(t != ta)// Should return false
{
// All returns true ?
bh = false;
i += key.length;
break;
};
}
}

"if(t <> ta)" No right to judge
"if(t != ta)" No right to judge



I made a mistake should be

Re: Fwd: confirm 9a85e83e9531356d37cfd8581573d167b99c16f8

[Ola Fosheim Grøstad]

On Saturday, 12 April 2014 at 16:41:09 UTC, Walter Bright wrote:
And a company whose only business goal is to keep passwords 
secure is probably harder
to hack into that companies which have a different focus and 
might not invest as

much into security.


"probably" doesn't work for me when the consequences of being 
wrong are so awful.


True, and by being a password business which people use for 
important passwords it becomes a primary target. So if there are 
weaknesses they are more likely to be found and expolitation 
skillfully hidden from detection...


Besides, the weakest link is your keyboard. You could be snooped 
by a radiation based scanner when you are outside you Faraday 
cage. Master passwords for anything more important than facebook 
is irresponsible IMHO.


But yeah, storing passwords in the clear is no good, because MOST 
people reuse passwords for services that are unimportant with the 
assumption that they are hashed before they are compared. This is 
a calculated risk. Man in the middle attacks are a bit less 
likely than site hacking (try a traceroute), and https can also 
suffer from those, so I think Manu is right about being upset. 
Storing passwords in the clear is a lot worse than clear 
transmission.

Re: Fwd: confirm 9a85e83e9531356d37cfd8581573d167b99c16f8

[Walter Bright]

On 4/13/2014 9:05 PM, "Ola Fosheim Grøstad" 
" wrote:

so I think Manu is right about being upset.


I agree. If a product has a password system in it, it is reasonable to expect it 
to have some basic level of security, despite what the disclaimer says.


I also think that it is reasonable to expect an knowledgeable user to use a 
different password for every account. After all, password security is only as 
good as the weakest system it is used on.

Re: Where the error ? (!=) (<>)

[Ali Çehreli]

On 04/13/2014 08:21 PM, sdvcn wrote:

> I made a mistake should be

Your message is truncated. Can you repost it to the D.learn newsgroup 
please.


Ali

Re: Fwd: confirm 9a85e83e9531356d37cfd8581573d167b99c16f8

[Ola Fosheim Grøstad]

On Monday, 14 April 2014 at 04:35:34 UTC, Walter Bright wrote:
I also think that it is reasonable to expect an knowledgeable 
user to use a different password for every account.


I don't think it is reasonable to assume that all users of D have 
to be that knowledgable, or to make it a prerequisite for 
participation.


After all, password security is only as good as the weakest 
system it is used on.


Yes, and under that assumption all passwords should be created by 
drawing letters from a box an memorized and NEVER be written down 
in any shape or form. And using a paper shredders is quite also 
insufficient for maculating, you should shred, burn and then stir 
the ashes. I know, I learned this in the army as a teletypist.


I don't practice it everywhere though... I think Manu's 
expectations were reasonable. I think it is reasonable to take 
some risk for hobbystuff, an unreasonable to unneccessarily 
increase the risk by storing in the clear for no good reason.

Re: confirm 9a85e83e9531356d37cfd8581573d167b99c16f8

[Iain Buclaw]

On 12 April 2014 22:28, Nick Sabalausky
 wrote:
> On 4/12/2014 7:41 AM, Iain Buclaw wrote:
>>
>>
>> http://privatekeycheck.com/
>>
>> :o)
>>
>
> LOL! An interesting way to check the security of a sysadmin, really. :)
>

Or to see if your sysadmin is a smart-ass...  In the 2 minutes I spent
looking, I don't think there's any other easter eggs apart from 'yes',
'nope' and 'maybe' ;-)

Re: Fwd: confirm 9a85e83e9531356d37cfd8581573d167b99c16f8

[Walter Bright]

On 4/13/2014 10:11 PM, "Ola Fosheim Grøstad" 
" wrote:

Yes, and under that assumption all passwords should be created by drawing
letters from a box an memorized and NEVER be written down in any shape or form.


Writing it on paper is not subject to hacking. Having your house burgled or 
black bagged is an entirely different problem. Hackers from a foreign country 
aren't going to do that, and the government is incapable of dragnet black 
bagging of residences.


I suspect that using the same password for multiple accounts is far more risky 
than using paper.

Re: Fwd: confirm 9a85e83e9531356d37cfd8581573d167b99c16f8

[Petru Vasile Avram]

On Sat, 12 Apr 2014 12:38:15 +0300, Manu  wrote:

On 12 April 2014 19:31, John Colvin   
wrote:



On Saturday, 12 April 2014 at 09:06:48 UTC, Manu wrote:


On 12 April 2014 17:56, Marco Nembrini 
wrote:

 On 12.04.2014 03:16, Manu wrote:


 On 12 April 2014 11:11, Brad Anderson 

> wrote:

On Saturday, 12 April 2014 at 01:09:45 UTC, Manu wrote:

This. Also, I have more than 1 computer (including a  
phone)...

what's the
solution there?


LastPass is cloud synced (including with phones).


... how does that work?




Encryption and decryption is only client-side so they only store an
encrypted database of your passwords.


I mean, how does it run on all of your devices, and integrate with all  
of

your software?



A variety of apps and plugins.



And for any software/services that don't support plugins?


Copy and paste.
--
Using Opera's mail client: http://www.opera.com/mail/

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com