On 2/3/2017 4:10 AM, Atila Neves wrote:
Right, but we're talking about finding memory corruption bugs _before_ they
manifest themselves. As I mentioned in my other reply, if you have memory
corruption bugs in common cross-platform code, valgrind and asan will (nearly
always) catch them. You don't
On Thursday, 2 February 2017 at 20:37:32 UTC, Random D user wrote:
What if d had a -safe-defaults switch? It should be ok, since
safe is stricter than unsafe right?
Yes, we need this because module-level '@safe:' doesn't allow
inferrence of @system.
This way old/existing code would compile f
On Thursday, 2 February 2017 at 20:50:58 UTC, Walter Bright wrote:
On 2/2/2017 6:19 AM, Atila Neves wrote:
Also, unless you're testing possible bugs in compiler backends
or the C standard
library, it mostly doesn't matter. Compile on regular
x86/Linux and run
valgrind/asan there.
I've often
On Thursday, 2 February 2017 at 16:44:26 UTC, Chris Wright wrote:
On Thu, 02 Feb 2017 14:19:02 +, Atila Neves wrote:
Also, unless you're testing possible bugs in compiler backends
or the C standard library, it mostly doesn't matter. Compile
on regular x86/Linux and run valgrind/asan there.
On 2/2/2017 12:37 PM, Random D user wrote:
I prefer flexible (fun), fast and debuggable (debugger/printing friendly) code.
It seems that neither @safe or const are part of it. (I'm not writing life and
death safety critical code anyway).
One nice feature of D is you don't have to use const, @sa
On 2/2/2017 8:44 AM, Chris Wright wrote:
Assuming you're writing cross-platform code. How common is that?
Exactly. That's why Valgrind is not a substitute for a language that offers
memory safety features.
On 2/2/2017 6:19 AM, Atila Neves wrote:
Also, unless you're testing possible bugs in compiler backends or the C standard
library, it mostly doesn't matter. Compile on regular x86/Linux and run
valgrind/asan there.
I've often been able to flush out difficult bugs by compiling on another
platfor
On Wednesday, 1 February 2017 at 23:49:29 UTC, H. S. Teoh wrote:
We would love to change the defaults, but unfortunately that
boat has already sailed a long time ago.
What if d had a -safe-defaults switch? It should be ok, since
safe is stricter than unsafe right?
This way old/existing code
On Thu, 02 Feb 2017 14:19:02 +, Atila Neves wrote:
> Also, unless you're testing possible bugs in compiler backends or the C
> standard library, it mostly doesn't matter. Compile on regular x86/Linux
> and run valgrind/asan there.
Assuming you're writing cross-platform code. How common is that
On Thursday, 2 February 2017 at 09:28:15 UTC, Walter Bright wrote:
I seem to recall Valgrind wasn't on OSX, either, at one point.
Maybe that has since been corrected.
It nominally works on 10.10, if I recall correctly, but not to
the same standard as on Linux.
For C/C++, a combination of the
On Thursday, 2 February 2017 at 09:28:15 UTC, Walter Bright wrote:
On 2/2/2017 1:21 AM, Claude wrote:
On Wednesday, 1 February 2017 at 21:16:30 UTC, Walter Bright
wrote:
6. Valgrind isn't available on all platforms, like Windows,
embedded systems,
phones (?), etc.
You can use valgrind on emb
On 2/2/2017 1:21 AM, Claude wrote:
On Wednesday, 1 February 2017 at 21:16:30 UTC, Walter Bright wrote:
6. Valgrind isn't available on all platforms, like Windows, embedded systems,
phones (?), etc.
You can use valgrind on embedded systems as long as they run a GNU/Linux OS.
I've used valgrind
On Wednesday, 1 February 2017 at 23:49:29 UTC, H. S. Teoh wrote:
On Wed, Feb 01, 2017 at 11:49:25PM +, Mike via
We would love to change the defaults, but unfortunately that
boat has already sailed a long time ago. If we could do it all
over again, I'm sure a lot of defaults would be the o
On Wednesday, 1 February 2017 at 21:16:30 UTC, Walter Bright
wrote:
6. Valgrind isn't available on all platforms, like Windows,
embedded systems, phones (?), etc.
You can use valgrind on embedded systems as long as they run a
GNU/Linux OS. I've used valgrind successfully many times on ARM
arc
On 2/1/2017 10:23 PM, Tobias Müller wrote:
Walter Bright wrote:
What part of the signature guarantees non-overlap?
Mutable references cannot overlap in Rust, at least in safe code.
I didn't know that bit, thanks for the info.
On 2/1/2017 10:11 PM, Tobias Müller wrote:
Apart from that, the entire point of building a safe wrapper around an
unsafe FFI function is to exploit additional knowledge that is not present
in the C declaration, but only in documentation. It's not relevant if that
wrapper is built into the languag
Walter Bright wrote:
> On 2/1/2017 9:28 AM, Michael Howell wrote:
>> unsafe fn copy_nonoverlapping_ref(src: &T, dest: &mut T, len: usize) {
>> std::ptr::copy_nonoverlapping(src, dest, len)
>> }
>>
>> Again, it doesn't guarantee no side effects, it may guarantee that src isn't
>> mutated, it does
Walter Bright wrote:
> On 2/1/2017 9:22 AM, Tobias Müller wrote:
>> You wouldn't use memcpy but just assign the slices.
>
> I clearly made a mistake in this example. I wanted to show how a compiler
> learns
> things from the declaration by using a very familiar declaration. But it
> keeps
> g
On Wednesday, 1 February 2017 at 23:49:29 UTC, H. S. Teoh wrote:
On Wed, Feb 01, 2017 at 11:49:25PM +, Mike via
Digitalmars-d wrote:
On Wednesday, 1 February 2017 at 21:47:58 UTC, Adam D. Ruppe
wrote:
> (actually in the real world, it won't since nobody will care
> enough
> to write `pure p
On Wed, Feb 01, 2017 at 11:49:25PM +, Mike via Digitalmars-d wrote:
> On Wednesday, 1 February 2017 at 21:47:58 UTC, Adam D. Ruppe wrote:
> > (actually in the real world, it won't since nobody will care enough
> > to write `pure public return const(T) hi(return scope T t) nothrow
> > @nogc @saf
On Wednesday, 1 February 2017 at 21:47:58 UTC, Adam D. Ruppe
wrote:
(actually in the real world, it won't since nobody will care
enough to write `pure public return const(T) hi(return scope T
t) nothrow @nogc @safe @noincompetence @a_million_other_things
{ return t; }`)
I found all the attrib
On 2/1/2017 1:47 PM, Adam D. Ruppe wrote:
At the rate D is going, pretty soon the entire function body will be retold in
the signature. What's the point when it is obvious that in practice, we can
actually analyze the content and get BETTER coverage anyway?
It already does this for templates an
On Wednesday, 1 February 2017 at 21:31:33 UTC, Walter Bright
wrote:
What part of the signature guarantees non-overlap?
At the rate D is going, pretty soon the entire function body will
be retold in the signature. What's the point when it is obvious
that in practice, we can actually analyze th
On 2/1/2017 9:22 AM, Tobias Müller wrote:
You wouldn't use memcpy but just assign the slices.
I clearly made a mistake in this example. I wanted to show how a compiler learns
things from the declaration by using a very familiar declaration. But it keeps
getting diverted into what people (and
On 2/1/2017 9:56 AM, Michael Howell wrote:
Oops, forgot the "restrict" keyword. It is there in the C and D versions.
D doesn't have the 'restrict' annotation.
On 2/1/2017 9:28 AM, Michael Howell wrote:
unsafe fn copy_nonoverlapping_ref(src: &T, dest: &mut T, len: usize) {
std::ptr::copy_nonoverlapping(src, dest, len)
}
Again, it doesn't guarantee no side effects, it may guarantee that src isn't
mutated, it does guarantee that they aren't stored away
On 2/1/2017 9:28 AM, Michael Howell wrote:
> This function signature *does* guarantee that src and self don't overlap,
unlike
the C and D versions. Personally, I think that's at least as important as
whether the function's pure or not.
The overlap is handled in C with the 'restrict' annotation
On 2/1/2017 6:39 AM, Cody Laeder wrote:
The _traditional_ C-like memcpy [3] in the stdlib. It is unsafe, and carries no
side effects for the src buffer. It enforces type safety, but it cannot enforce
memory safety as you can blow past the allocation side on your dst buffer (hence
why it is unsafe
On 2/1/2017 12:38 PM, Richard Delorme wrote:
Right, if defined in another file, the compiler will not emit any warning.
However other tools can detect this kind of error. For instance, valgrind works
great in this example, directly on the executable:
$ valgrind --track-origins=yes mymemcpy
[...]
On 2/1/2017 8:12 AM, Chris Wright wrote:
OTOH I haven't seen anyone distribute a D library with .di files
druntime uses a lot of header-only imports, including for D code. (The gc, for
example, is not presented as source code to the compiler.)
On 2/1/2017 2:05 AM, Richard Delorme wrote:
On Tuesday, 31 January 2017 at 23:30:04 UTC, Walter Bright wrote:
On 1/31/2017 3:00 PM, Richard Delorme wrote:
The thing about memcpy is compilers build in a LOT of information about it
that simply is not there in the declaration. I suggest retrying yo
On Wednesday, 1 February 2017 at 10:20:45 UTC, Patrick Schluter
wrote:
On Wednesday, 1 February 2017 at 10:05:49 UTC, Richard Delorme
wrote:
//-8<---
#include
#include
void* mymemcpy(void* restrict dest, const void* restrict src,
size_
On Wednesday, 1 February 2017 at 17:28:28 UTC, Michael Howell
wrote:
This function signature *does* guarantee that src and self
don't overlap, unlike the C and D versions. Personally, I think
that's at least as important as whether the function's pure or
not.
Oops, forgot the "restrict" keywo
Tobias Müller wrote:
> Walter Bright
> But if you still wanted a memcpy it would probably look like this:
>
> fn memcpy<'a, T>(dest: &'a mut [T], src: &[T]) -> &'a mut [T]
No, sorry:
fn memcpy<'a, T: Copy>(dest: &'a mut [T], src: &[T]) -> &'a mut [T]
And mutable references can never alias, y
On Wednesday, 1 February 2017 at 14:39:15 UTC, Cody Laeder wrote:
[4] https://gist.github.com/1f34331b2cae6ba9e624c5f9f4f2a458
That example code won't even typecheck, and the minimal fix (make
dest a slice) leaves it unsafe (T needs to be Copy). If you just
want to quick bang out code like th
Walter Bright wrote:
> I'm not very familiar with Rust. Can you post what a Rust declaration for
> memcpy
> would look like with all the guarantees?
You wouldn't use memcpy but just assign the slices. Assignment is always
just memcpy in Rust because of move-semantics:
a[m1..n1] = b[m2..n2];
I
On Tuesday, 31 January 2017 at 18:21:02 UTC, Jack Stouffer wrote:
On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright
wrote:
2. The return value is derived from s1.
4. Copies of s1 or s2 are not saved.
Actually I didn't know either of those things from looking at
the signature because
On Wed, 01 Feb 2017 10:20:45 +, Patrick Schluter wrote:
> You have to define the mymemcpy() in another source file and only put
> the prototype in this module. If the compiler sees the code it can do
> the complete data flow analyses. With only the declaration it can't and
> that is Walter's po
On Wednesday, 1 February 2017 at 08:17:45 UTC, Walter Bright
wrote:
I'm not very familiar with Rust. Can you post what a Rust
declaration for memcpy would look like with all the guarantees?
The memcpy you have linked [1] is just a wrapper around the LLVM
intrinsic [2] function. This is not sta
On Wednesday, 1 February 2017 at 10:05:49 UTC, Richard Delorme
wrote:
On Tuesday, 31 January 2017 at 23:30:04 UTC, Walter Bright
wrote:
On 1/31/2017 3:00 PM, Richard Delorme wrote:
The thing about memcpy is compilers build in a LOT of
information about it that simply is not there in the
declar
On Tuesday, 31 January 2017 at 23:30:04 UTC, Walter Bright wrote:
On 1/31/2017 3:00 PM, Richard Delorme wrote:
The thing about memcpy is compilers build in a LOT of
information about it that simply is not there in the
declaration. I suggest retrying your example for gcc/clang, but
use your own
On 1/31/2017 10:43 PM, Tobias Müller wrote:
Using an FFI function to compare D vs Rust doesn't tell you much. Foreign
functions are usually not used directly in Rust, they are used to build
safe wrappers that will give you *all* possible guarantees, including type
safety.
As a consequence it's no
Walter Bright wrote:
> Rust says https://doc.rust-lang.org/1.14.0/libc/fn.memcpy.html:
>
> pub unsafe extern fn memcpy(dest: *mut c_void,
> src: *const c_void,
> n: size_t)
> -> *mut c_void
>
>
> [...]
> The R
On Tuesday, 31 January 2017 at 23:42:43 UTC, Walter Bright wrote:
On 1/31/2017 11:32 AM, Nordlöw wrote:
On Tuesday, 31 January 2017 at 19:26:51 UTC, Walter Bright
wrote:
This "as if" thing enables the designer of a function API to
set the desired
relationships even if the implementation is doin
On 1/31/2017 11:32 AM, Nordlöw wrote:
On Tuesday, 31 January 2017 at 19:26:51 UTC, Walter Bright wrote:
This "as if" thing enables the designer of a function API to set the desired
relationships even if the implementation is doing some deviated preversion
with the data (i.e. a ref counted object
On 1/31/2017 12:00 PM, Mathias Lang wrote:
*Can* make use of it... But won't.
Any code calling memcpy has to be in a @trusted wrapper, in which `return scope`
is not checked.
So adding `return scope` annotations to non-safe D binding is just like adding
documentation. Which is on par with what C
On 1/31/2017 3:00 PM, Richard Delorme wrote:
May we have an example of how the memory safety of arguments supplied to memcpy
is checked in a way gcc cannot do?
I was thinking of the return attribute, that prevents for example to return the
address of a local variable through a call to memcpy:
On Tuesday, 31 January 2017 at 19:20:40 UTC, Walter Bright wrote:
On 1/31/2017 5:50 AM, Richard Delorme wrote:
Well, I would not have taken memcpy as an example in favor of
D. Good C
compilers (like gcc) know what memcpy does and are able to
optimize it according
to its arguments. DMD may know
On Tuesday, 31 January 2017 at 19:32:58 UTC, Nordlöw wrote:
Why is this feature used? Optimizations? Safety?
Just me being lazy. I'm gonna read up on
https://wiki.dlang.org/DIP25
On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright wrote:
By this information being knowable from the declaration, the
compiler knows it too and can make use of it.
*Can* make use of it... But won't.
Any code calling memcpy has to be in a @trusted wrapper, in which
`return scope` is
On 1/31/2017 2:44 AM, Nordlöw wrote:
On Tuesday, 31 January 2017 at 10:20:59 UTC, Olivier FAURE wrote:
I thought it meant "the parameter can be returned" not "the parameter *will*
be returned".
And what about multiple `return`-qualified function parameters?
'return' means treat the return va
On Tuesday, 31 January 2017 at 19:26:51 UTC, Walter Bright wrote:
On 1/31/2017 2:44 AM, Nordlöw wrote:
On Tuesday, 31 January 2017 at 10:20:59 UTC, Olivier FAURE
wrote:
I thought it meant "the parameter can be returned" not "the
parameter *will*
be returned".
And what about multiple `return`
On 1/31/2017 5:50 AM, Richard Delorme wrote:
Well, I would not have taken memcpy as an example in favor of D. Good C
compilers (like gcc) know what memcpy does and are able to optimize it according
to its arguments. DMD may know better about memcpy through its declaration but
does not make any us
On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright wrote:
2. The return value is derived from s1.
4. Copies of s1 or s2 are not saved.
Actually I didn't know either of those things from looking at the
signature because DIP25 and DIP1000 have marketing problems, in
that the only way to
On Tuesday, 31 January 2017 at 02:18:23 UTC, Mike wrote:
On Tuesday, 31 January 2017 at 02:01:05 UTC, Walter Bright
wrote:
On 1/30/2017 5:53 PM, Mike wrote:
One in particular prevents me from using D, period! -
https://issues.dlang.org/show_bug.cgi?id=14758
The -betterC switch is the approach
On Tuesday, 31 January 2017 at 11:32:01 UTC, John Colvin wrote:
On Tuesday, 31 January 2017 at 10:17:09 UTC, Olivier FAURE
wrote:
On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright
wrote:
Point 3 is about `const`, which as far as I know is unaffected
by application of @safe. Did you m
On Tuesday, 31 January 2017 at 10:00:03 UTC, Stefan Koch wrote:
Because of the return attribute.
return means I am passing this value through myself.
Ahh, missed that. My mistake.
Thanks, Walter!
On Tuesday, 31 January 2017 at 13:50:33 UTC, Richard Delorme
wrote:
But, my main argument here, is that a good C compiler, is able
to do a very good job at optimizing memcpy, so the extra
information brought by the D language, is not so useful in
practice.
The point of Walter's argument was n
On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright wrote:
Just from D's type signature, we can know a lot about memcpy():
1. There are no side effects.
2. The return value is derived from s1.
3. Nothing s2 transitively points to is altered via s2.
4. Copies of s1 or s2 are not saved.
Th
On Tuesday, 31 January 2017 at 10:17:09 UTC, Olivier FAURE wrote:
On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright
wrote:
3. Nothing s2 transitively points to is altered via s2.
Wait, really? Does that mean that this code is implicitly
illegal?
import core.stdc.string;
void m
On Tuesday, 31 January 2017 at 10:20:59 UTC, Olivier FAURE wrote:
I thought it meant "the parameter can be returned" not "the
parameter *will* be returned".
And what about multiple `return`-qualified function parameters?
On Tuesday, 31 January 2017 at 10:00:03 UTC, Stefan Koch wrote:
On Tuesday, 31 January 2017 at 09:31:23 UTC, Nordlöw wrote:
How can we be sure that the return value points to the same
content as `s1`?
Because of the return attribute.
return means I am passing this value through myself.
I th
On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright wrote:
3. Nothing s2 transitively points to is altered via s2.
Wait, really? Does that mean that this code is implicitly illegal?
import core.stdc.string;
void main()
{
int*[10] data1;
int*[10] data2;
On Tuesday, 31 January 2017 at 09:31:23 UTC, Nordlöw wrote:
How can we be sure that the return value points to the same
content as `s1`?
Because of the return attribute.
return means I am passing this value through myself.
On Tuesday, 31 January 2017 at 09:31:23 UTC, Nordlöw wrote:
How can we be sure that the return value points to the same
content as `s1`? If that is what you mean by "derived".
Now that we allow allocation functions to be `pure` as in
https://github.com/dlang/druntime/pull/1746
On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright wrote:
Rust:
pub unsafe extern fn memcpy(dest: *mut c_void,
src: *const c_void,
n: size_t)
-> *mut c_void
D:
pure void* memcpy(return void* s1, sc
On 31/01/2017 3:58 PM, Jaded Observer wrote:
On Tuesday, 31 January 2017 at 02:01:05 UTC, Walter Bright wrote:
On 1/30/2017 5:53 PM, Mike wrote:
One in particular prevents me from using D, period! -
https://issues.dlang.org/show_bug.cgi?id=14758
The -betterC switch is the approach we intend t
On Tuesday, 31 January 2017 at 02:01:05 UTC, Walter Bright wrote:
On 1/30/2017 5:53 PM, Mike wrote:
One in particular prevents me from using D, period! -
https://issues.dlang.org/show_bug.cgi?id=14758
The -betterC switch is the approach we intend to take to deal
with that issue.
You aren't
On Tuesday, 31 January 2017 at 02:01:05 UTC, Walter Bright wrote:
On 1/30/2017 5:53 PM, Mike wrote:
One in particular prevents me from using D, period! -
https://issues.dlang.org/show_bug.cgi?id=14758
The -betterC switch is the approach we intend to take to deal
with that issue.
I recommend
On 1/30/2017 5:53 PM, Mike wrote:
One in particular prevents me from using D, period! -
https://issues.dlang.org/show_bug.cgi?id=14758
The -betterC switch is the approach we intend to take to deal with that issue.
On Tuesday, 31 January 2017 at 01:30:48 UTC, Walter Bright wrote:
Just from D's type signature, we can know a lot about memcpy():
Yes, D has some notable advantages over other languages, but it
also has some notable disadvantages. One in particular prevents
me from using D, period! -
https
The C99 Standard says:
#include
void *memcpy(void * restrict s1, const void * restrict s2, size_t n);
Description
The memcpy function copies n characters from the object pointed to by s2
into the object pointed to by s1. If copying takes place between objects
that overlap, the beha
72 matches
Mail list logo
