On 7/6/2014 1:00 AM, Rikki Cattermole wrote:
On 6/07/2014 6:06 a.m., Nick Sabalausky wrote:
Also, DAuth encourages passwords to be stored in a special structure:
https://github.com/Abscissa/DAuth/blob/master/src/dauth/core.d#L311
which attempts to zero-out the password from memory as early
On Sun, 2014-07-06 at 01:36 +, Andy Smith via Digitalmars-d wrote:
> On Saturday, 5 July 2014 at 20:54:25 UTC, H. S. Teoh via
> Digitalmars-d wrote:
> > On Sat, Jul 05, 2014 at 06:00:40PM +0100, Russel Winder via
> > Digitalmars-d wrote:
> >> SCons 2.3.2 has been released which has the revampe
On 6/07/2014 6:06 a.m., Nick Sabalausky wrote:
On 7/5/2014 8:23 AM, Kagamin wrote:
There was a study, showing that most security vulnerabilities are caused
by client code rather than cryptographic library code.
Interesting. Link?
For example, how
would you prevent client code from generatin
On Friday, 4 July 2014 at 17:05:32 UTC, David Nadlinger wrote:
On Friday, 4 July 2014 at 14:47:12 UTC, Chris Cain wrote:
Is there a way to lock the GC currently?
There are critical regions in core.thread. While in such a
region, your thread will never be suspended, effectively also
precludin
On 07/06/2014 05:19 AM, Wanderer wrote:
On Saturday, 5 July 2014 at 16:03:17 UTC, Dmitry Olshansky wrote:
...
Pointers are perfectly fine as long as there is no pointer arithmetic.
Wrong. Merely holding a pointer (i.e. a physical address) is unsafe
already. Non-deep serialization, or any other
On Saturday, 5 July 2014 at 16:03:17 UTC, Dmitry Olshansky wrote:
There are trade-offs. The world is not black and white and I
don't follow 'one rule everywhere'.
This is not a trade-off at all. You suggested to keep database
records linearly, with space gaps between records to support
"tiny
On 7/5/2014 6:54 PM, deadalnix wrote:
On Sunday, 6 July 2014 at 00:18:19 UTC, Walter Bright wrote:
On 7/5/2014 12:33 PM, deadalnix wrote:
I used to think that. A few years ago, I looked into OpenSSL, noticed several
horrors. Several of them mentioned here:
https://www.youtube.com/watch?v=GnBbh
On Sunday, 6 July 2014 at 00:18:19 UTC, Walter Bright wrote:
On 7/5/2014 12:33 PM, deadalnix wrote:
I used to think that. A few years ago, I looked into OpenSSL,
noticed several
horrors. Several of them mentioned here:
https://www.youtube.com/watch?v=GnBbhXBDmwU
I had the same reasoning: cryt
On Saturday, 5 July 2014 at 23:45:47 UTC, Xinok wrote:
If you don't trust OpenSSL, nobody said you have to use it.
There are plenty of alternatives available. The fact still
remains, implementing your own crypto is a very bad idea.
It seems to be the consensus. In the meantime, people like M
On Saturday, 5 July 2014 at 20:54:25 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Sat, Jul 05, 2014 at 06:00:40PM +0100, Russel Winder via
Digitalmars-d wrote:
SCons 2.3.2 has been released which has the revamped D tooling.
I appreciate Dub is becoming the build system of choice for
new D
proje
On 7/5/2014 12:33 PM, deadalnix wrote:
I used to think that. A few years ago, I looked into OpenSSL, noticed several
horrors. Several of them mentioned here:
https://www.youtube.com/watch?v=GnBbhXBDmwU
I had the same reasoning: crytpo is hard and these guys know much more than I
do.
They don'
On Saturday, 5 July 2014 at 19:33:31 UTC, deadalnix wrote:
I used to think that. A few years ago, I looked into OpenSSL,
noticed several horrors. Several of them mentioned here:
https://www.youtube.com/watch?v=GnBbhXBDmwU
I had the same reasoning: crytpo is hard and these guys know
much more
05-Jul-2014 23:33, deadalnix пишет:
On Sunday, 29 June 2014 at 07:19:49 UTC, Adam Wilson wrote:
On Sat, 28 Jun 2014 23:08:51 -0700, Charles
wrote:
Is there a native D crypto library like Crypto++?
No. And for good reason. Building a cryptography library is an
extremely dificult proposition.
Timon Gehr:
I'd have preferred separate issues for unrelated cases.
Take a look at the report date, Timon: 2010-03-11, in the
meantime I have learnt a thing or two regarding reporting
compiler bugs :-)
Bye,
bearophile
On 07/06/2014 12:39 AM, bearophile wrote:
Look at this Issue https://d.puremagic.com/issues/show_bug.cgi?id=3934
for some humorous examples fit more for the Monty Python and the Flying
Circus than a serious language.
While there are some oddities there, many (most?) reports in that issue
are
Paul D Anderson:
The fourth (with multiple 'const' suffixed) does not generate
an error. This looks like a bug to me. Is it?
The situation with accepting or not accepting those tags attached
to functions is a terrible mess since several years, at
ridiculous levels. Fixing that mess will caus
The getValueX functions below differ only in the number and
placing of the keyword 'const'.
The compiler rejects the first (with 'const const' prefix), as
expected (Error: redundant storage class 'const').
The second (with prefix 'const', suffix 'const') is accepted. It
looks strange but is
On 7/5/2014 5:10 PM, Walter Bright wrote:
On 6/29/2014 1:12 AM, Brad Roberts via Digitalmars-d wrote:
A safe rule of thumb with crypto code / libraries: If the thought of
writing
that type of code doesn't scare you for at least a dozen or so
reasons, you
don't know enough to tread in that playg
On 6/29/2014 1:12 AM, Brad Roberts via Digitalmars-d wrote:
A safe rule of thumb with crypto code / libraries: If the thought of writing
that type of code doesn't scare you for at least a dozen or so reasons, you
don't know enough to tread in that playground. Or you're one of the damned few
peo
On Sat, Jul 05, 2014 at 06:00:40PM +0100, Russel Winder via Digitalmars-d wrote:
> SCons 2.3.2 has been released which has the revamped D tooling.
>
> I appreciate Dub is becoming the build system of choice for new D
> projects, so I will maintain the D support in SCons but definitely in
> "mainte
On Sunday, 29 June 2014 at 18:47:56 UTC, Xinok wrote:
Proper cryptographic libraries are written in such a way to
mitigate these types of attacks. It's a complex field of study
and something best left to the experts.
Current crypto libs, aren't capable of doing bound checking
properly, that s
On Sunday, 29 June 2014 at 07:19:49 UTC, Adam Wilson wrote:
On Sat, 28 Jun 2014 23:08:51 -0700, Charles
wrote:
Is there a native D crypto library like Crypto++?
No. And for good reason. Building a cryptography library is an
extremely dificult proposition. Even after you've completed the
b
On Sunday, 29 June 2014 at 07:19:49 UTC, Adam Wilson wrote:
On Sat, 28 Jun 2014 23:08:51 -0700, Charles
wrote:
Is there a native D crypto library like Crypto++?
No. And for good reason. Building a cryptography library is an
extremely dificult proposition. Even after you've completed the
b
On 07/05/2014 07:07 PM, Daniel Murphy wrote:
"Wanderer" wrote in message news:jbvbufgyhbjrkpukr...@forum.dlang.org...
For pair of integers, you can use long and sort an array of longs.
Awesome, now your sort order depends on processor endianness!
?
k=i<<32|j, i=k>>>32, j=k&(1L<<32)-1.
On 7/5/2014 8:23 AM, Kagamin wrote:
There was a study, showing that most security vulnerabilities are caused
by client code rather than cryptographic library code.
Interesting. Link?
For example, how
would you prevent client code from generating weak encryption keys or
from using weak algori
"Wanderer" wrote in message news:jbvbufgyhbjrkpukr...@forum.dlang.org...
For pair of integers, you can use long and sort an array of longs.
Awesome, now your sort order depends on processor endianness!
Storing structs in contiguous memory is sometimes better for some things.
The fact that s
SCons 2.3.2 has been released which has the revamped D tooling.
I appreciate Dub is becoming the build system of choice for new D
projects, so I will maintain the D support in SCons but definitely in
"maintenance mode" rather than "development mode".
--
Russel.
==
On Saturday, 5 July 2014 at 16:24:28 UTC, Iain Buclaw via
Digitalmars-d wrote:
Right, it's a quirk of the CPU.
It's a precision quirk of floating point that has to be defined,
and different CPUs follow different definitions. Within IEEE754
it can of course also differ, since it does not preve
On Friday, 4 July 2014 at 21:15:00 UTC, Chris Cain wrote:
On Friday, 4 July 2014 at 21:09:05 UTC, Remo wrote:
By "C++ style memory management" I do not mean naked
new/delete or malloc/free.
What I mean is RAII, smart pointers and destructor's.
What is the proper replacement for std::unique_ptr
On Friday, 4 July 2014 at 19:46:40 UTC, Remo wrote:
On Friday, 4 July 2014 at 16:16:35 UTC, Meta wrote:
With @nogc and the -vgc compiler switch, I think it would
fairly easy now to do C-style memory management and know that
there are no hidden GC allocations in your program. Whether
you would
On 5 July 2014 16:13, via Digitalmars-d wrote:
> On Saturday, 5 July 2014 at 15:09:28 UTC, Iain Buclaw via Digitalmars-d
> wrote:
>>
>> This is a library problem, not a language problem. In this case
>> std.math uses real everywhere when perhaps it shouldn't.
>
>
> If x/y leads to a division by z
05-Jul-2014 19:08, Wanderer пишет:
On Saturday, 5 July 2014 at 14:20:33 UTC, Dmitry Olshansky wrote:
Provision some extra space in each record. DBs do this all the time,
regardless of layout.
Which means waste of space you complained about just below.
There are trade-offs. The world is not b
On Saturday, 5 July 2014 at 15:28:00 UTC, bearophile wrote:
There is already Delight and FeepingCreature has created a
D-like language. If you fork D you will have lot of fun :-)
Thanks :)
Both Delight and FeepingCreature appears to be alive. I guess
that is a good sign.
[（1, 2, 3), (4, 5, 6), (7, 8, 9)]
Good idea.
And shoud easy to be used by foreach.
Frank
Ola Fosheim Grøstad:
No, I meant forking D.
There is already Delight and FeepingCreature has created a D-like
language. If you fork D you will have lot of fun :-) Keep us
updated.
Bye,
bearophile
Kitchen Design Lancashire in my mind are the best value kitchens
by far.
[url=http://www.lancashireinteriorhomedesigns.co.uk/]Kitchen
Design Lancashire Reviews[/url]
On Saturday, 5 July 2014 at 15:09:28 UTC, Iain Buclaw via
Digitalmars-d wrote:
This is a library problem, not a language problem. In this case
std.math uses real everywhere when perhaps it shouldn't.
If x/y leads to a division by zero trap when it should not, then
it isn't a library problem.
On 5 July 2014 15:20, via Digitalmars-d wrote:
> On Saturday, 5 July 2014 at 13:16:28 UTC, Paolo Invernizzi wrote:
>>
>> I agree, but keep this is mind: a business model is not carved in stone,
>> it keeps changing, as the market is not a static thing.
>
>
> Ok, but for the virtual world side I am
On Saturday, 5 July 2014 at 14:20:33 UTC, Dmitry Olshansky wrote:
Provision some extra space in each record. DBs do this all the
time, regardless of layout.
Which means waste of space you complained about just below.
Besides, you understand this is not a solution: one byte more
than that rese
On Sat, 2014-07-05 at 11:46 +, ponce via Digitalmars-d wrote:
> On Saturday, 5 July 2014 at 06:43:31 UTC, Russel Winder via
> Digitalmars-d wrote:
> >
> > All the C++ folk are saying that with C++14 is you are using
> > any heap at
> > all you are more than likely doing it wrong. Modern C++ i
On Saturday, 5 July 2014 at 13:16:28 UTC, Paolo Invernizzi wrote:
I agree, but keep this is mind: a business model is not carved
in stone, it keeps changing, as the market is not a static
thing.
Ok, but for the virtual world side I am more driven by (artistic)
model needs than the business si
05-Jul-2014 18:02, Wanderer пишет:
On Friday, 4 July 2014 at 12:18:54 UTC, Daniel Murphy wrote:
Yes they do. http://en.wikipedia.org/wiki/Database_index#Clustered
You can obviously only do that for one index.
Ugh, and what happens in such hypothetical database if you update its
first row so i
On Friday, 4 July 2014 at 12:18:54 UTC, Daniel Murphy wrote:
Yes they do.
http://en.wikipedia.org/wiki/Database_index#Clustered
You can obviously only do that for one index.
Ugh, and what happens in such hypothetical database if you update
its first row so it becomes 1 byte longer than befo
On Saturday, 5 July 2014 at 11:14:40 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 5 July 2014 at 09:39:10 UTC, Paolo Invernizzi
wrote:
Again, outside, in the real business world, reality is a little
different: take this monster, look, no C++!
http://www.robg3d.com/2014/01/why-ccp-is-still-using
On Sunday, 29 June 2014 at 19:25:30 UTC, Chris Cain wrote:
Of course, following all of those suggestions isn't trivial to
begin with. Technically, you're right, but because what you
said isn't easy to follow to begin with, it doesn't support the
argument of "you can implement a crypto algorithm
On Saturday, 5 July 2014 at 06:43:31 UTC, Russel Winder via
Digitalmars-d wrote:
All the C++ folk are saying that with C++14 is you are using
any heap at
all you are more than likely doing it wrong. Modern C++ idiom
is for
completely new/delete free code.
Minor nitpick, it is indeed devoid
The beta works great this far, just sharing some few initial
surprises.
1) The lookup rules for namespaces seem overly permissive:
extern (C++, A.B.C):
void cpp() { }
All these work:
A.cpp
B.cpp
C.cpp
A.B.cpp
B.C.cpp
A.B.C.cpp
2) We have std.traits.functionLinkage, but no corresponding trait
On Saturday, 5 July 2014 at 09:39:10 UTC, Paolo Invernizzi wrote:
Again, outside, in the real business world, reality is a little
different: take this monster, look, no C++!
http://www.robg3d.com/2014/01/why-ccp-is-still-using-python-2/
http://www.pcgamer.com/2013/06/15/eve-online/
I don't pla
On Friday, 4 July 2014 at 21:49:33 UTC, Ola Fosheim Grøstad wrote:
On Friday, 4 July 2014 at 21:08:27 UTC, Walter Bright wrote:
Sadly, this also implies that there are no computer languages
you believe in. You set an impossible standard. How can you
possibly say you prefer C++, a classic desig
On Saturday, 5 July 2014 at 06:48:23 UTC, Russel Winder via
Digitalmars-d wrote:
That should, of course, have read Python 3.4!
Most of my code has to run on App Engine, so I stick to whatever
version Google use for all my Python stuff. They had Guido do
their db-api a couple of years back so
Chris Cain:
http://dlang.org/phobos/std_typecons.html#.Unique
I'd like to read a little tutorial for the usage of that Unuque
in D.
Bye,
bearophile
51 matches
Mail list logo
