On Thursday, 27 July 2017 at 23:52:27 UTC, H. S. Teoh wrote:
On Thu, Jul 27, 2017 at 09:32:12PM +, Moritz Maxeiner via
Digitalmars-d wrote:
[...]
Yes, and therefore "you already have much bigger things to
worry about than D services hanging". That you're ignorant of
the compromise does
On Thu, Jul 27, 2017 at 09:32:12PM +, Moritz Maxeiner via Digitalmars-d
wrote:
> On Thursday, 27 July 2017 at 20:48:51 UTC, H. S. Teoh wrote:
[...]
> > If someone malicious has root access to your server, you already
> > have much bigger things to worry about than D services hanging. :-D
>
>
On Thursday, July 27, 2017 13:48:51 H. S. Teoh via Digitalmars-d wrote:
> On Thu, Jul 27, 2017 at 07:50:52PM +, Moritz Maxeiner via Digitalmars-
d wrote:
> > On Thursday, 27 July 2017 at 18:46:16 UTC, Jonathan M Davis wrote:
> [...]
>
> > > I see no problem whatsoever requiring that the platfor
Am Thu, 27 Jul 2017 17:59:41 +
schrieb Adrian Matoga :
> On Thursday, 27 July 2017 at 17:43:17 UTC, H. S. Teoh wrote:
> > On Thu, Jul 27, 2017 at 05:33:22PM +, Adrian Matoga via
> > Digitalmars-d wrote: [...]
> >> Why can't we just make the compiler insert null checks in
> >> @safe cod
On Thursday, 27 July 2017 at 20:48:51 UTC, H. S. Teoh wrote:
On Thu, Jul 27, 2017 at 07:50:52PM +, Moritz Maxeiner via
Digitalmars-d wrote:
On Thursday, 27 July 2017 at 18:46:16 UTC, Jonathan M Davis
wrote:
[...]
> I see no problem whatsoever requiring that the platform
> segfaults when yo
On Thu, Jul 27, 2017 at 07:50:52PM +, Moritz Maxeiner via Digitalmars-d
wrote:
> On Thursday, 27 July 2017 at 18:46:16 UTC, Jonathan M Davis wrote:
[...]
> > I see no problem whatsoever requiring that the platform segfaults
> > when you dereference null. Anything even vaguely modern will do
>
On Thursday, 27 July 2017 at 20:09:46 UTC, Steven Schveighoffer
wrote:
Well, let's not forget that the services should not be
dereferencing null. It's still a bug in the code.
Of course, but statistically speaking, all software is buggy so
it's not an unreasonable assumption on the attackers
On 7/27/17 3:50 PM, Moritz Maxeiner wrote:
On Thursday, 27 July 2017 at 18:46:16 UTC, Jonathan M Davis wrote:
On Thursday, July 27, 2017 11:03:02 Steven Schveighoffer via
Digitalmars-d wrote:
A possibility:
"@safe D does not support platforms or processes where dereferencing
a null pointer do
On Thursday, 27 July 2017 at 18:46:16 UTC, Jonathan M Davis wrote:
On Thursday, July 27, 2017 11:03:02 Steven Schveighoffer via
Digitalmars-d wrote:
A possibility:
"@safe D does not support platforms or processes where
dereferencing a null pointer does not crash the program. In
such situation
On Thursday, 27 July 2017 at 17:52:09 UTC, H. S. Teoh wrote:
On Thu, Jul 27, 2017 at 11:03:02AM -0400, Steven Schveighoffer
via Digitalmars-d wrote: [...]
However, there do exist places where dereferencing null may
NOT cause a segmentation fault. For example, see this post by
Moritz Maxeiner:
On 7/27/17 2:46 PM, Jonathan M Davis via Digitalmars-d wrote:
However, one issue that has been brought up from time to time and AFAIK has
never really been addressed is that apparently if an object is large enough,
when you access one of its members when the pointer is null, you won't get a
segf
On Thursday, July 27, 2017 11:03:02 Steven Schveighoffer via Digitalmars-d
wrote:
> A possibility:
>
> "@safe D does not support platforms or processes where dereferencing a
> null pointer does not crash the program. In such situations,
> dereferencing null is not defined, and @safe code will not
On 7/27/17 2:09 PM, Steven Schveighoffer wrote:
there's nothing in the spec to require it. And it does seem apparent
that we handle this situation.
that we *should* handle this situation.
-Steve
On 7/27/17 1:52 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Jul 27, 2017 at 11:03:02AM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
However, there do exist places where dereferencing null may NOT cause
a segmentation fault. For example, see this post by Moritz Maxeiner:
https:
On 7/27/17 1:33 PM, Adrian Matoga wrote:
Why can't we just make the compiler insert null checks in @safe code? We
can afford bounds checking even in @system -O -release. C++ can afford
null check upon executing an std::function. The pointer would most
likely be in a register anyway, and the c
On Thu, Jul 27, 2017 at 11:03:02AM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
> However, there do exist places where dereferencing null may NOT cause
> a segmentation fault. For example, see this post by Moritz Maxeiner:
> https://forum.dlang.org/post/udkdqogtrvanhbotd...@forum.dla
On Thursday, 27 July 2017 at 17:43:17 UTC, H. S. Teoh wrote:
On Thu, Jul 27, 2017 at 05:33:22PM +, Adrian Matoga via
Digitalmars-d wrote: [...]
Why can't we just make the compiler insert null checks in
@safe code?
Because not inserting null checks is a sacred cow we inherited
from the C/C
On Thu, Jul 27, 2017 at 05:33:22PM +, Adrian Matoga via Digitalmars-d wrote:
[...]
> Why can't we just make the compiler insert null checks in @safe code?
Because not inserting null checks is a sacred cow we inherited from the
C/C++ days of POOP (premature optimization oriented programming), a
On Thursday, 27 July 2017 at 15:03:02 UTC, Steven Schveighoffer
wrote:
Inside the thread for adding @safe/@trusted attributes to OS
functions, it has come to light that @safe has conflicting
rules.
For the definition of safe, it says:
"Safe functions are functions that are statically checked
Inside the thread for adding @safe/@trusted attributes to OS functions,
it has come to light that @safe has conflicting rules.
For the definition of safe, it says:
"Safe functions are functions that are statically checked to exhibit no
possibility of undefined behavior."
In the definition of
20 matches
Mail list logo
