Re: Fwd: confirm 9a85e83e9531356d37cfd8581573d167b99c16f8

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

Re: Fwd: confirm 9a85e83e9531356d37cfd8581573d167b99c16f8

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 bagg

Re: confirm 9a85e83e9531356d37cfd8581573d167b99c16f8

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,

Re: Fwd: confirm 9a85e83e9531356d37cfd8581573d167b99c16f8

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 prerequisi

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

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

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 expe

Re: Fwd: confirm 9a85e83e9531356d37cfd8581573d167b99c16f8

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 c

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

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

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

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 {

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

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.

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

"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; i

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

dstring key = "<"d; dstring str = "<盗墓笔记>"d; for(size_t i;i ta)// Should return false if(t != ta)// Should return false { // All returns true ?

Re: enum

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 u

Stilhaus Kitchens Reviews

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: Fwd: confirm 9a85e83e9531356d37cfd8581573d167b99c16f8

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 exis

Re: gdc 2.064.2 in next Ubuntu LTS

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 d

Re: enum

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 oursel

on interfacing w/C++

(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

Re: enum

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

Re: gdc 2.064.2 in next Ubuntu LTS

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

Re: gdc 2.064.2 in next Ubuntu LTS

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. >> >>

Re: gdc 2.064.2 in next Ubuntu LTS

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

Re: gdc 2.064.2 in next Ubuntu LTS

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 d

Re: enum

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 p

Re: Shared Library, that is when ?

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 mention

Re: Heartbleed and static analysis

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 reas

Re: Heartbleed and static analysis

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 l

Re: dec64 decimal floating point type

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 expe

Re: Heartbleed and static analysis

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 us

Re: Heartbleed and static analysis

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

Re: Heartbleed and static analysis

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

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.

Re: Heartbleed and static analysis

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

Re: Heartbleed and static analysis

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 whatev

Re: Heartbleed and static analysis

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 pro

Re: dec64 decimal floating point type

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

Re: Heartbleed and static analysis

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 th

Re: enum

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 ot

Re: enum

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

Re: The "@safe vs struct destructor" dilemma

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 f

Re: Heartbleed and static analysis

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 progra

Re: gdc 2.064.2 in next Ubuntu LTS

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

gdc 2.064.2 in next Ubuntu LTS

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 th

Re: Heartbleed and static analysis

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 n

Re: Shared Library, that is when ?

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 wi

Re: Has anybody tried calling D from Ruby?

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.std

Has anybody tried calling D from Ruby?

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 th

Re: Heartbleed and static analysis

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-critic

Re: Heartbleed and static analysis

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

Re: Heartbleed and static analysis

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 ma