On Fri, Jan 26, 2018 at 04:36:18AM -0700, Jonathan M Davis via Digitalmars-d
wrote:
> On Thursday, January 25, 2018 17:20:21 H. S. Teoh via Digitalmars-d wrote:
> > On Fri, Jan 26, 2018 at 01:08:10AM +, Mike Franklin via Digitalmars-d
> wrote:
> > > On Wednesday, 24 January 2018 at 09:35:44
On Thursday, January 25, 2018 17:20:21 H. S. Teoh via Digitalmars-d wrote:
> On Fri, Jan 26, 2018 at 01:08:10AM +, Mike Franklin via Digitalmars-d
wrote:
> > On Wednesday, 24 January 2018 at 09:35:44 UTC, lobo wrote:
> > > And I'm broken after using D, going back to C++ is awful and Rust
> >
On Fri, Jan 26, 2018 at 01:08:10AM +, Mike Franklin via Digitalmars-d wrote:
> On Wednesday, 24 January 2018 at 09:35:44 UTC, lobo wrote:
>
> > And I'm broken after using D, going back to C++ is awful and Rust
> > just has too much friction to be enjoyable.
>
> Yep, I know exactly what you
On Wednesday, 24 January 2018 at 09:35:44 UTC, lobo wrote:
And I'm broken after using D, going back to C++ is awful and
Rust just has too much friction to be enjoyable.
Yep, I know exactly what you mean.
On 1/24/18 9:46 PM, Walter Bright wrote:
On 1/23/2018 7:22 PM, Jonathan M Davis wrote:
We need to do that anyway for the overly large
objects (and unfortunately don't last I heard).
I put a limit in at one time for struct/class sizes to prevent this
issue, but got a lot of pushback on it and
On Wednesday, January 24, 2018 18:46:38 Walter Bright via Digitalmars-d
wrote:
> On 1/23/2018 7:22 PM, Jonathan M Davis wrote:
> > We need to do that anyway for the overly large
> > objects (and unfortunately don't last I heard).
>
> I put a limit in at one time for struct/class sizes to prevent
On 1/24/2018 9:04 PM, Mike Franklin wrote:
On Thursday, 25 January 2018 at 04:59:55 UTC, Mike Franklin wrote:
Yes, ROM is at address 0. Address 0 contains the initial stack pointer. So
you read address 0, dereference it, and then do your damage.
This is from the "what were they thinking"
On Thursday, 25 January 2018 at 04:59:55 UTC, Mike Franklin wrote:
Yes, ROM is at address 0. Address 0 contains the initial stack
pointer. So you read address 0, dereference it, and then do
your damage.
Keep in mind too that the ROM, on these devices, is actually
reprogrammable from the
On Thursday, 25 January 2018 at 04:45:34 UTC, Walter Bright wrote:
This implies a ROM must be located there. Else how do initial
values get there?
Yes, ROM is at address 0. Address 0 contains the initial stack
pointer. So you read address 0, dereference it, and then do your
damage.
Mike
On Thursday, 25 January 2018 at 04:45:34 UTC, Walter Bright wrote:
This implies a ROM must be located there. Else how do initial
values get there?
I'm not sure what you mean. When you upload your firmware to the
MCU, it writes the initial stack pointer to address 0x00 and the
address of
On 1/24/2018 8:31 PM, Mike Franklin wrote:
On Thursday, 25 January 2018 at 04:01:47 UTC, Mike Franklin wrote:
"The initial stack pointer and the address of the reset handler must be
located at 0x0 and 0x4 respectively."
On Thursday, 25 January 2018 at 04:01:47 UTC, Mike Franklin wrote:
"The initial stack pointer and the address of the reset handler
must be located at 0x0 and 0x4 respectively."
(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0497a/CHDBIJJE.html)
Sorry! Wrong link. Try this
On Thursday, 25 January 2018 at 02:41:53 UTC, Walter Bright wrote:
Ok, but are these devices with 0 being a valid address?
It seems weird to me that any sane modern CPU design that can
access megabytes of memory would have 0 be a valid address.
Yes, 0 is a valid address and typically
On 1/23/2018 7:22 PM, Jonathan M Davis wrote:
We need to do that anyway for the overly large
objects (and unfortunately don't last I heard).
I put a limit in at one time for struct/class sizes to prevent this issue, but
got a lot of pushback on it and it was reverted.
Perhaps we can revisit
On 1/23/2018 6:28 PM, Mike Franklin wrote:
I think you need to get involved in programming microcontrollers again because
the landscape has changed drastically. The microcontrollers I use now are more
powerful than PCs of the 90's.
Ok, but are these devices with 0 being a valid address?
It
On Wednesday, January 24, 2018 21:24:16 Seb via Digitalmars-d wrote:
> On Wednesday, 24 January 2018 at 19:12:50 UTC, Steven
>
> Schveighoffer wrote:
> > While I understand your argument, the truth is that avoiding
> > null dereferencing *statically* has to be built into the
> > language from the
On Wednesday, 24 January 2018 at 19:12:50 UTC, Steven
Schveighoffer wrote:
While I understand your argument, the truth is that avoiding
null dereferencing *statically* has to be built into the
language from the beginning. As D is already too far along to
retrofit this, your 2 options are:
a)
On 1/23/18 9:28 PM, Mike Franklin wrote:
On Wednesday, 24 January 2018 at 01:44:51 UTC, Walter Bright wrote:
Microcontroller code tends to be small and so it's unlikely that
you'll need to worry about it.
I think you need to get involved in programming microcontrollers again
because the
On Wednesday, 24 January 2018 at 09:35:44 UTC, lobo wrote:
The last memory corruption issue we had in non-critcal was 4yrs
ago, in older C++ code. Memory corruption really is becoming a
thing of the past in modern C++.
If you write everything from scratch with safety-oriented design?
On Wednesday, 24 January 2018 at 04:15:27 UTC, Mike Franklin
wrote:
On Wednesday, 24 January 2018 at 03:46:41 UTC, lobo wrote:
Well if your embedded device has all that on it you should be
sitting on an OS with proper memory management support.
I don't see how the OS can help if the
On Wednesday, 24 January 2018 at 03:46:41 UTC, lobo wrote:
Well if your embedded device has all that on it you should be
sitting on an OS with proper memory management support.
I don't see how the OS can help if the underlying hardware
doesn't have an MMU. That being said, admittedly, the
On Wednesday, 24 January 2018 at 02:28:12 UTC, Mike Franklin
wrote:
On Wednesday, 24 January 2018 at 01:44:51 UTC, Walter Bright
wrote:
Microcontroller code tends to be small and so it's unlikely
that you'll need to worry about it.
I think you need to get involved in programming
On Wednesday, January 24, 2018 02:28:12 Mike Franklin via Digitalmars-d
wrote:
> On Wednesday, 24 January 2018 at 01:44:51 UTC, Walter Bright
>
> wrote:
> > Microcontroller code tends to be small and so it's unlikely
> > that you'll need to worry about it.
>
> I think you need to get involved in
On Wednesday, 24 January 2018 at 01:44:51 UTC, Walter Bright
wrote:
Microcontroller code tends to be small and so it's unlikely
that you'll need to worry about it.
I think you need to get involved in programming microcontrollers
again because the landscape has changed drastically. The
On 1/23/2018 4:42 PM, Mike Franklin wrote:
That's what kindof ticks me off about this "null is memory safe" argument; it
seems to be only applicable to a specific platform and environment.
It's an extremely useful argument, though, as modern computers have virtual
memory systems that map 0 to
On Tuesday, 23 January 2018 at 21:53:24 UTC, Steven Schveighoffer
wrote:
[1] Note: the reason they are safe is because they generally
result in a segfault, which doesn't harm any memory. This is
very much a user-space POV, and doesn't take into account
kernel-space where null dereferences
On Tuesday, 23 January 2018 at 21:53:24 UTC, Steven Schveighoffer
wrote:
Interestingly, `destroy` is an unsafe operation for classes.
Because it's calling a @system function, rt_finalize. This
function calls whatever is in the destructor, and because it
works on Object level, it has no
On 1/22/18 11:11 PM, Mike Franklin wrote:
On Tuesday, 23 January 2018 at 02:25:57 UTC, Mike Franklin wrote:
Should `destroy` be `@system` so it can't be called in `@safe` code,
or should the compiler be smart enough to figure out the flow control
and throw an error?
Interestingly, `destroy`
On Monday, 22 January 2018 at 23:30:16 UTC, Aedt wrote:
I was asked in Reddit
(https://www.reddit.com/r/learnprogramming/comments/7ru82l/i_was_thinking_of_using_d_haxe_or_another/) how would D handle the following similar D code. I'm surprised that both dmd and ldc provides no warnings even with
On 01/23/2018 03:38 AM, Mike Franklin wrote:
import std.stdio;
void main() @safe
{
string foo = "foo";
string* ls0;
string* p1, p2;
ls0 =
p1 = ls0;
ls0.destroy();
p2 = ls0;
writeln(p2.length);
}
Compile with `-dip1000`
Error: program killed by signal
On Tuesday, 23 January 2018 at 02:25:57 UTC, Mike Franklin wrote:
Should `destroy` be `@system` so it can't be called in `@safe`
code, or should the compiler be smart enough to figure out the
flow control and throw an error?
Interestingly, `destroy` is an unsafe operation for classes.
On Tuesday, 23 January 2018 at 02:38:42 UTC, Mike Franklin wrote:
So that's bad. But it looks like a bug in `-dip1000`
https://issues.dlang.org/show_bug.cgi?id=18283
On Tuesday, 23 January 2018 at 02:25:57 UTC, Mike Franklin wrote:
Not sure how to precisely define the problem here. Should
`destroy` be `@system` so it can't be called in `@safe` code,
or should the compiler be smart enough to figure out the flow
control and throw an error?
Mike
The
On Tuesday, 23 January 2018 at 02:25:57 UTC, Mike Franklin wrote:
Due to the aforementioned bugs in my prior posts, I couldn't
even make an example to demonstrate in @safe code, so I
modified the example slightly in an effort to reproduce the
same problem.
import std.stdio;
void main()
On Tuesday, 23 January 2018 at 01:08:19 UTC, ag0aep6g wrote:
The real question is about this line:
p2 = ls[0];
That's an out-of-bounds access, and the compiler does not catch
this statically. Instead, it inserts bounds-checking code that
crashes the program safely with an `Error`.
On Tuesday, 23 January 2018 at 01:08:19 UTC, ag0aep6g wrote:
The real question is about this line:
p2 = ls[0];
That's an out-of-bounds access, and the compiler does not catch
this statically. Instead, it inserts bounds-checking code that
crashes the program safely with an `Error`.
In
On Tuesday, 23 January 2018 at 01:08:19 UTC, ag0aep6g wrote:
If you add `@safe`, the compiler rejects this line:
ls ~=
But that line would only be problematic if the pointer would
leave the scope of the function. It doesn't, so this is
actually safe. But the compiler isn't smart enough
On 01/23/2018 01:20 AM, Mike Franklin wrote:
I would be surprised if
the compiler allowed you to do something like this in `@safe` code.
You might get surprised then, if you expect the compiler to reject code
like that statically.
If you add `@safe`, the compiler rejects this line:
ls
On Tuesday, 23 January 2018 at 00:20:45 UTC, Mike Franklin wrote:
On Monday, 22 January 2018 at 23:30:16 UTC, Aedt wrote:
[...]
D is not memory safe by default (unfortunately), so it's not
surprising to me that you can do this in `@system` code. I
would be surprised if the compiler allowed
On Monday, 22 January 2018 at 23:30:16 UTC, Aedt wrote:
I was asked in Reddit
(https://www.reddit.com/r/learnprogramming/comments/7ru82l/i_was_thinking_of_using_d_haxe_or_another/) how would D handle the following similar D code. I'm surprised that both dmd and ldc provides no warnings even with
I was asked in Reddit
(https://www.reddit.com/r/learnprogramming/comments/7ru82l/i_was_thinking_of_using_d_haxe_or_another/) how would D handle the following similar D code. I'm surprised that both dmd and ldc provides no warnings even with -w argument passed.
import std.stdio;
void main()
{
41 matches
Mail list logo
