On Saturday, 17 February 2018 at 23:43:07 UTC, Adam D. Ruppe
wrote:
On Saturday, 17 February 2018 at 18:03:44 UTC, Peter Campbell
wrote:
Andrei mentioned at his DConf presentations is that the
runtime itself will be modified to not rely on the GC,
allowing for you to continue using features suc
On Saturday, 17 February 2018 at 18:03:44 UTC, Peter Campbell
wrote:
Andrei mentioned at his DConf presentations is that the runtime
itself will be modified to not rely on the GC, allowing for you
to continue using features such as associative arrays and array
concatenation, but without requiri
On Saturday, 17 February 2018 at 19:32:50 UTC, bachmeier wrote:
On Saturday, 17 February 2018 at 18:03:44 UTC, Peter Campbell
wrote:
My understanding from the vision documents and what Andrei
mentioned at his DConf presentations is that the runtime
itself will be modified to not rely on the G
On Saturday, 17 February 2018 at 18:03:44 UTC, Peter Campbell
wrote:
My understanding from the vision documents and what Andrei
mentioned at his DConf presentations is that the runtime itself
will be modified to not rely on the GC, allowing for you to
continue using features such as associati
ing :) I'm writing a library for @nogc
D programming, tanya. It has different aims than -betterC: I
use the full set of D features, just except features that
require GC. It isn't complete, I'm using it only in personal
projects and it is also a big learn project for me, so don'
On Saturday, 17 February 2018 at 12:18:28 UTC, Peter Campbell
wrote:
Hi everyone, it's been almost a year since I used D but I was
wanted to get back into it. I was checking the 2017 vision
pages and was wondering why there hasn't been a 2018H1 vision
page but also what the current status of be
status of being able to use D
without a garbage collector is?
It was noted in the H1 and H2 pages for 2017 but looking
through the compiler changelog doesn't indicate that we're
there yet? https://wiki.dlang.org/Vision/2017H2
Thanks.
Let me do a bit advertising :) I'm writ
On Saturday, 17 February 2018 at 12:18:28 UTC, Peter Campbell
wrote:
I was checking the 2017 vision pages and was wondering why
there hasn't been a 2018H1 vision page but also what the
current status of being able to use D without a garbage
collector is?
There are a number of ways to use D wi
Hi everyone, it's been almost a year since I used D but I was
wanted to get back into it. I was checking the 2017 vision pages
and was wondering why there hasn't been a 2018H1 vision page but
also what the current status of being able to use D without a
garbage collector is?
It was noted in t
Submitted
https://issues.dlang.org/show_bug.cgi?id=18058
On 10/12/17 14:07, Shachar Shemesh wrote:
On 10/12/17 14:00, Shachar Shemesh wrote:
On 10/12/17 13:44, Jonathan M Davis wrote:
it sounds like the delegate that's
being generated isn't @nogc, so it can't be called with
On Sunday, 10 December 2017 at 11:44:20 UTC, Jonathan M Davis
wrote:
On Sunday, December 10, 2017 12:54:00 Shachar Shemesh via
Digitalmars-d wrote:
void func1(scope lazy string msg) @nogc {
}
void func2(scope lazy string msg) @nogc {
func1(msg);
}
What? Why is msg GC allocating
On 10/12/17 14:00, Shachar Shemesh wrote:
On 10/12/17 13:44, Jonathan M Davis wrote:
it sounds like the delegate that's
being generated isn't @nogc, so it can't be called within the function,
which would be a completely different issue from allocating a closure.
Here'
On 10/12/17 13:44, Jonathan M Davis wrote:
it sounds like the delegate that's
being generated isn't @nogc, so it can't be called within the function,
which would be a completely different issue from allocating a closure.
Here's the thing, though. There is no reason fo
On Sunday, December 10, 2017 12:54:00 Shachar Shemesh via Digitalmars-d
wrote:
> void func1(scope lazy string msg) @nogc {
> }
>
> void func2(scope lazy string msg) @nogc {
> func1(msg);
> }
>
> What? Why is msg GC allocating, especially since I scoped the lazy? Why
void func1(scope lazy string msg) @nogc {
}
void func2(scope lazy string msg) @nogc {
func1(msg);
}
What? Why is msg GC allocating, especially since I scoped the lazy? Why
is msg even evaluated?
Something seems off here.
Thanks,
Shachar
ingle file package).
Wow! Yeah that seems like almost exactly what I want. Sorry
what is iz? Thank you!
-Craig
It's a D user library: https://github.com/BBasile/iz.
I forgot to say but the @NoGc data annotation relies on
construct(). Neither `new` not `std.experimental.allocator.ma
On Wednesday, 20 September 2017 at 02:43:44 UTC, B4s1L3 wrote:
It's another way of doing things. It's less strict than
checking all the functions.
note: the script can be run directly by passing the file to DUB
(single file package).
Wow! Yeah that seems like almost exactly what I want. So
on-GC heap using
malloc and free and emplace, but I find it troubling that you
still need to tell the GC to scan your allocation. What I
would like is, for example, to be able to write a @nogc
templated struct that guarantees that none of its members
require GC scanning. Thus:
@nogc struct Ar
nd it troubling that you still
need to tell the GC to scan your allocation. What I would like
is, for example, to be able to write a @nogc templated struct
that guarantees that none of its members require GC scanning.
Thus:
@nogc struct Array(T)
{
...
}
class GarbageCollectedClass
{
}
void
On Tuesday, 19 September 2017 at 20:57:17 UTC, Neia Neutuladh
wrote:
On Tuesday, 19 September 2017 at 15:11:31 UTC, Craig Black
wrote:
[...]
You want to ensure that it can never refer to GC memory. The
type system does not contain that information. It doesn't say
whether an object was alloca
e binary's static data segment...
So @nogc can't help you. You could, however, replace the GC
implementation with one that throws an AssertError whenever the
GC runs a collection, allocates memory, etc. Or you could just
add @nogc to your main function.
If you want to forbid all refere
On 09/19/2017 08:06 PM, Craig Black wrote:
This wouldn't
be allowed for classes or class references, since they are always
pointing to GC data
That's not true. You can put class objects into other places than the GC
heap.
On 9/19/17 2:06 PM, Craig Black wrote:
Thank you for the clarification. I understand mow that @nogc is only for
functions and not for data types. Thinking out loud, it would seem
beneficial if there was a way to mark a pointer or data structure as not
pointing to the GC heap. A guarantee to
ample, to be able to write a @nogc
templated struct that guarantees that none of its members
require GC scanning. Thus:
@nogc struct Array(T)
{
...
}
class GarbageCollectedClass
{
}
void main()
{
Array!int intArray; // fine
}
@nogc is a function attribute. It has no effect on types
e
he GC in any way.
I realize that you can allocate on the non-GC heap using malloc and
free and emplace, but I find it troubling that you still need to tell
the GC to scan your allocation. What I would like is, for example, to
be able to write a @nogc templated struct that guarantees that none
o
On Tuesday, 19 September 2017 at 14:34:10 UTC, Mike Parker wrote:
On Tuesday, 19 September 2017 at 14:22:21 UTC, Craig Black
wrote:
Thank you for your response. The @nogc attribute is good, but
in my opinion it is incomplete if all types still require
scanning. The purpose of not employing
On Tuesday, 19 September 2017 at 14:22:21 UTC, Craig Black wrote:
Thank you for your response. The @nogc attribute is good, but
in my opinion it is incomplete if all types still require
scanning. The purpose of not employing GC in certain sections
of code is performance, and we are
u can allocate on the non-GC heap using
malloc and free and emplace, but I find it troubling that you
still need to tell the GC to scan your allocation. What I
would like is, for example, to be able to write a @nogc
templated struct that guarantees that none of its members
require GC scanning.
nd it troubling that you still
need to tell the GC to scan your allocation. What I would like
is, for example, to be able to write a @nogc templated struct
that guarantees that none of its members require GC scanning.
Thus:
@nogc struct Array(T)
{
...
}
class GarbageCollectedClass
{
}
void
ng malloc
> and free and emplace, but I find it troubling that you still need
> to tell the GC to scan your allocation. What I would like is, for
> example, to be able to write a @nogc templated struct that
> guarantees that none of its members require GC scanning. Thus:
>
>
On 09/19/2017 03:46 PM, Craig Black wrote:
struct MyStruct
{
@nogc:
public:
Foo foo; // This does not produce an error, but it still requires a
GC scan
@nogc is about GC allocations. `Foo foo;` doesn't cause a GC allocation.
@nogc doesn't control what memory is scanned by the GC.
On Tuesday, 19 September 2017 at 13:46:20 UTC, Craig Black wrote:
Thanks, I didn't know you could to that but it still doesn't
give me the behavior that I want:
class Foo
{
}
struct MyStruct
{
@nogc:
public:
Foo foo; // This does not produce an error, but it still
requires
19.09.2017 16:46, Craig Black пишет:
class Foo
{
}
struct MyStruct
{
@nogc:
public:
Foo foo; // This does not produce an error, but it still requires a
GC scan
void Bar()
{
foo = new Foo; // This produces an error
}
}
it produces an error for me https://run.dlang.io/is
19.09.2017 16:49, drug пишет:
19.09.2017 16:48, drug пишет:
19.09.2017 16:46, Craig Black пишет:
class Foo
{
}
struct MyStruct
{
@nogc:
public:
Foo foo; // This does not produce an error, but it still requires
a GC scan
void Bar()
{
foo = new Foo; // This produces an error
n the non-GC heap using
malloc and free and emplace, but I find it troubling that you
still need to tell the GC to scan your allocation. What I
would like is, for example, to be able to write a @nogc
templated struct that guarantees that none of its members
require GC scanning. Thus:
@nogc s
19.09.2017 16:48, drug пишет:
19.09.2017 16:46, Craig Black пишет:
class Foo
{
}
struct MyStruct
{
@nogc:
public:
Foo foo; // This does not produce an error, but it still requires a
GC scan
void Bar()
{
foo = new Foo; // This produces an error
}
}
it produces an error for
nd it troubling that you still
need to tell the GC to scan your allocation. What I would like
is, for example, to be able to write a @nogc templated struct
that guarantees that none of its members require GC scanning.
Thus:
@nogc struct Array(T)
{
...
}
class GarbageCollectedClass
{
}
void
On Tuesday, 19 September 2017 at 13:13:48 UTC, Craig Black wrote:
@nogc struct Array(T)
{
...
}
class GarbageCollectedClass
{
}
void main()
{
Array!int intArray; // fine
Array!GarbageCollectedClass classArray; // Error: struct
Array is @nogc
}
If you want to enforce that behaviour I
nd it troubling that you still
need to tell the GC to scan your allocation. What I would like
is, for example, to be able to write a @nogc templated struct
that guarantees that none of its members require GC scanning.
Thus:
@nogc struct Array(T)
{
...
}
class GarbageCollectedClass
{
}
void
What I would like is, for
example, to be able to write a @nogc templated struct that
guarantees that none of its members require GC scanning. Thus:
@nogc struct Array(T)
{
...
}
class GarbageCollectedClass
{
}
void main()
{
Array!int intArray; // fine
}
On Wednesday, 2 August 2017 at 16:32:44 UTC, Andrei Alexandrescu
wrote:
import std.algorithm;
// I probably wouldn't even define this but use the body as is
auto strnlen_safe(in char[] str)
{
return countUntil(cast(ubyte[]) str, '\0');
}
Oh that cast it irks me so.
-Steve
return str
import std.algorithm;
// I probably wouldn't even define this but use the body as is
auto strnlen_safe(in char[] str)
{
return countUntil(cast(ubyte[]) str, '\0');
}
Oh that cast it irks me so.
-Steve
return str.representation.countUntil('\0');
Andrei
On Tuesday, 1 August 2017 at 22:52:26 UTC, H. S. Teoh wrote:
On Tue, Aug 01, 2017 at 06:46:17PM -0400, Steven Schveighoffer
via Digitalmars-d wrote:
On 8/1/17 6:17 PM, Moritz Maxeiner wrote:
[...]
> import std.algorithm;
> // I probably wouldn't even define this but use the body as
> is
> au
On Tue, Aug 01, 2017 at 06:46:17PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
> On 8/1/17 6:17 PM, Moritz Maxeiner wrote:
[...]
> > import std.algorithm;
> > // I probably wouldn't even define this but use the body as is
> > auto strnlen_safe(in char[] str)
> > {
> > return countUnt
On 8/1/17 6:17 PM, Moritz Maxeiner wrote:
On Tuesday, 1 August 2017 at 21:59:46 UTC, Steven Schveighoffer wrote:
On 8/1/17 5:54 PM, Moritz Maxeiner wrote:
On Tuesday, 1 August 2017 at 20:39:35 UTC, Marco Leise wrote:
Am Tue, 1 Aug 2017 10:50:59 -0700
schrieb "H. S. Teoh via Digitalmars-d"
:
O
On Tuesday, 1 August 2017 at 21:59:46 UTC, Steven Schveighoffer
wrote:
On 8/1/17 5:54 PM, Moritz Maxeiner wrote:
On Tuesday, 1 August 2017 at 20:39:35 UTC, Marco Leise wrote:
Am Tue, 1 Aug 2017 10:50:59 -0700
schrieb "H. S. Teoh via Digitalmars-d"
:
On Tue, Aug 01, 2017 at 05:12:38PM +, w0
On 8/1/17 5:54 PM, Moritz Maxeiner wrote:
On Tuesday, 1 August 2017 at 20:39:35 UTC, Marco Leise wrote:
Am Tue, 1 Aug 2017 10:50:59 -0700
schrieb "H. S. Teoh via Digitalmars-d"
:
On Tue, Aug 01, 2017 at 05:12:38PM +, w0rp via Digitalmars-d wrote:
> Direct OS function calls should probably
On Tuesday, 1 August 2017 at 20:39:35 UTC, Marco Leise wrote:
Am Tue, 1 Aug 2017 10:50:59 -0700
schrieb "H. S. Teoh via Digitalmars-d"
:
On Tue, Aug 01, 2017 at 05:12:38PM +, w0rp via
Digitalmars-d wrote:
> Direct OS function calls should probably all be treated as
> unsafe, except for rar
On Tue, Aug 01, 2017 at 10:39:35PM +0200, Marco Leise via Digitalmars-d wrote:
> Am Tue, 1 Aug 2017 10:50:59 -0700
> schrieb "H. S. Teoh via Digitalmars-d"
> :
>
> > On Tue, Aug 01, 2017 at 05:12:38PM +, w0rp via Digitalmars-d wrote:
> > > Direct OS function calls should probably all be treate
Am Tue, 1 Aug 2017 10:50:59 -0700
schrieb "H. S. Teoh via Digitalmars-d"
:
> On Tue, Aug 01, 2017 at 05:12:38PM +, w0rp via Digitalmars-d wrote:
> > Direct OS function calls should probably all be treated as unsafe,
> > except for rare cases where the behaviour is very well defined in
> > stan
On Tue, Aug 01, 2017 at 05:12:38PM +, w0rp via Digitalmars-d wrote:
> Direct OS function calls should probably all be treated as unsafe,
> except for rare cases where the behaviour is very well defined in
> standards and in actual implementations to be safe. The way to get
> safe functions for
Direct OS function calls should probably all be treated as
unsafe, except for rare cases where the behaviour is very well
defined in standards and in actual implementations to be safe.
The way to get safe functions for OS functionality is to write
wrapper functions in D which prohibit unsafe ca
On Monday, 31 July 2017 at 13:56:48 UTC, Shachar Shemesh wrote:
One of the things that really bother me with the D community is
the "100% or nothing" approach.
In the worst case when a function becomes unsafe, only @safe
attribute will be removed from it, which will be a breaking
change, but
On Monday, 31 July 2017 at 14:51:22 UTC, Timon Gehr wrote:
On 31.07.2017 16:15, Shachar Shemesh wrote:
That's fine, but since, according to the logic presented here,
no OS function can ever be @safe,
This is actually not true. Vladimir was just pointing out a
complication of which to be aware
On 31.07.2017 16:15, Shachar Shemesh wrote:
Why do you think @trusted exists?
That's fine, but since, according to the logic presented here, no OS
function can ever be @safe,
This is actually not true. Vladimir was just pointing out a complication
of which to be aware. Are you arguing agai
On 31/07/17 17:08, Timon Gehr wrote:
On 31.07.2017 15:56, Shachar Shemesh wrote:
One of the things that really bother me with the D community is the
"100% or nothing" approach.
...
Personally, I'm more bothered by this kind of lazy argument that sounds
good but has no substance.
System p
On 31.07.2017 15:56, Shachar Shemesh wrote:
One of the things that really bother me with the D community is the
"100% or nothing" approach.
...
Personally, I'm more bothered by this kind of lazy argument that sounds
good but has no substance.
System programming is, by definition, an exerc
On 31/07/17 16:33, Vladimir Panteleev wrote:
On Wednesday, 26 July 2017 at 17:48:21 UTC, Walter Bright wrote:
On 7/26/2017 6:29 AM, Kagamin wrote:
Should we still try to mark them safe at all?
Marking ones that are safe with @safe is fine. OS APIs pretty much
never change.
Sometimes operat
On Wednesday, 26 July 2017 at 17:48:21 UTC, Walter Bright wrote:
On 7/26/2017 6:29 AM, Kagamin wrote:
Should we still try to mark them safe at all?
Marking ones that are safe with @safe is fine. OS APIs pretty
much never change.
Sometimes operating systems add new flags to their API which
There's a less questionable problem with it.
Hint: FILE struct is transparent, look inside it, lots of
interesting stuff there.
On Friday, 28 July 2017 at 12:40:06 UTC, Kagamin wrote:
On Wednesday, 26 July 2017 at 17:48:21 UTC, Walter Bright wrote:
On 7/26/2017 6:29 AM, Kagamin wrote:
Should we still try to mark them safe at all?
Marking ones that are safe with @safe is fine. OS APIs pretty
much never change.
New t
On Wednesday, 26 July 2017 at 17:48:21 UTC, Walter Bright wrote:
On 7/26/2017 6:29 AM, Kagamin wrote:
Should we still try to mark them safe at all?
Marking ones that are safe with @safe is fine. OS APIs pretty
much never change.
New technologies and new features get introduced over time: 64
On 2017-07-27 13:46, Steven Schveighoffer wrote:
So the result is that it will segfault. I don't see a problem with this.
It's what I would have expected.
The problem is that behavior might change depending on which compiler is
used because the code is not valid according to the specification
On 07/25/2017 10:54 PM, Walter Bright wrote:
On 7/25/2017 8:26 AM, Andrei Alexandrescu wrote:
A suite of safe wrappers on OS primitives might be useful.
The idea of fixing the operating system interface(s) has come up now and
then. I've tried to discourage that on the following grounds:
*
On Thursday, 27 July 2017 at 14:45:03 UTC, Steven Schveighoffer
wrote:
On 7/27/17 10:20 AM, Moritz Maxeiner wrote:
On Thursday, 27 July 2017 at 13:56:00 UTC, Steven
Schveighoffer wrote:
I'm fine with saying libraries or platforms that do not
segfault when accessing zero page are incompatible
On Thursday, 27 July 2017 at 11:46:24 UTC, Steven Schveighoffer
wrote:
On 7/27/17 2:48 AM, Jacob Carlborg wrote:
And then the compiler runs the "Dead Code Elimination" pass
and we're left with:
void contains_null_check(int* p)
{
*p = 4;
}
So the result is that it will segfault. I don't
On 7/27/17 10:20 AM, Moritz Maxeiner wrote:
On Thursday, 27 July 2017 at 13:56:00 UTC, Steven Schveighoffer wrote:
On 7/27/17 9:24 AM, Moritz Maxeiner wrote:
On Wednesday, 26 July 2017 at 01:09:50 UTC, Steven Schveighoffer wrote:
I think we can correctly assume no fclose implementations exist t
On Thursday, 27 July 2017 at 13:56:00 UTC, Steven Schveighoffer
wrote:
On 7/27/17 9:24 AM, Moritz Maxeiner wrote:
On Wednesday, 26 July 2017 at 01:09:50 UTC, Steven
Schveighoffer wrote:
I think we can correctly assume no fclose implementations
exist that do anything but access data pointed at b
On Thursday, 27 July 2017 at 13:45:21 UTC, ag0aep6g wrote:
On 07/27/2017 03:24 PM, Moritz Maxeiner wrote:
--- null.d ---
version (linux):
import core.stdc.stdio : FILE;
import core.sys.linux.sys.mman;
extern (C) @safe int fgetc(FILE* stream);
void mmapNull()
{
void* mmapNull = mmap(null,
On 7/27/17 9:24 AM, Moritz Maxeiner wrote:
On Wednesday, 26 July 2017 at 01:09:50 UTC, Steven Schveighoffer wrote:
I think we can correctly assume no fclose implementations exist that
do anything but access data pointed at by stream. Which means a
segfault on every platform we support.
On pla
On 07/27/2017 03:24 PM, Moritz Maxeiner wrote:
--- null.d ---
version (linux):
import core.stdc.stdio : FILE;
import core.sys.linux.sys.mman;
extern (C) @safe int fgetc(FILE* stream);
void mmapNull()
{
void* mmapNull = mmap(null, 4096, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS
On Wednesday, 26 July 2017 at 01:09:50 UTC, Steven Schveighoffer
wrote:
On 7/25/17 8:45 PM, Timon Gehr wrote:
On 26.07.2017 02:35, Steven Schveighoffer wrote:
On 7/25/17 5:23 PM, Moritz Maxeiner wrote:
On Tuesday, 25 July 2017 at 20:16:41 UTC, Steven
Schveighoffer wrote:
The behavior is defin
On 07/27/2017 07:27 AM, Timon Gehr wrote:
On 27.07.2017 02:11, Steven Schveighoffer wrote:
On 7/26/17 7:56 PM, Andrei Alexandrescu wrote:
On 07/26/2017 06:16 PM, Steven Schveighoffer wrote:
So I guess I should restate that we can assume no implementations
exist that intentionally cause UB when
On 7/27/17 7:27 AM, Timon Gehr wrote:
On 27.07.2017 02:11, Steven Schveighoffer wrote:
On 7/26/17 7:56 PM, Andrei Alexandrescu wrote:
On 07/26/2017 06:16 PM, Steven Schveighoffer wrote:
So I guess I should restate that we can assume no implementations
exist that intentionally cause UB when str
On 7/27/17 2:48 AM, Jacob Carlborg wrote:
And then the compiler runs the "Dead Code Elimination" pass and we're
left with:
void contains_null_check(int* p)
{
*p = 4;
}
So the result is that it will segfault. I don't see a problem with this.
It's what I would have expected.
-Steve
On 27.07.2017 02:11, Steven Schveighoffer wrote:
On 7/26/17 7:56 PM, Andrei Alexandrescu wrote:
On 07/26/2017 06:16 PM, Steven Schveighoffer wrote:
So I guess I should restate that we can assume no implementations
exist that intentionally cause UB when stream is NULL (as in Timon's
example). E
On 2017-07-27 03:14, Steven Schveighoffer wrote:
I can't see how compilers can take advantage of this one. However, we
can take advantage that this UB is almost universally implemented as a
hardware segfault that ends the process.
Unfortunately it's not that easy with optimizing compilers for
On 7/26/17 8:09 PM, Timon Gehr wrote:
On 27.07.2017 01:56, Andrei Alexandrescu wrote:
On 07/26/2017 06:16 PM, Steven Schveighoffer wrote:
So I guess I should restate that we can assume no implementations
exist that intentionally cause UB when stream is NULL (as in Timon's
example).
My argume
On 7/26/17 7:56 PM, Andrei Alexandrescu wrote:
On 07/26/2017 06:16 PM, Steven Schveighoffer wrote:
So I guess I should restate that we can assume no implementations
exist that intentionally cause UB when stream is NULL (as in Timon's
example). Either they check for null, and handle gracefully,
On 27.07.2017 01:56, Andrei Alexandrescu wrote:
On 07/26/2017 06:16 PM, Steven Schveighoffer wrote:
So I guess I should restate that we can assume no implementations
exist that intentionally cause UB when stream is NULL (as in Timon's
example).
My argument was not that we need to fear impleme
On 07/26/2017 06:16 PM, Steven Schveighoffer wrote:
So I guess I should restate that we can assume no implementations exist
that intentionally cause UB when stream is NULL (as in Timon's example).
Either they check for null, and handle gracefully, or don't check and
segfault.
No need to worry
On 7/26/17 12:08 PM, Patrick Schluter wrote:
On Wednesday, 26 July 2017 at 01:09:50 UTC, Steven Schveighoffer wrote:
On 7/25/17 8:45 PM, Timon Gehr wrote:
On 26.07.2017 02:35, Steven Schveighoffer wrote:
On 7/25/17 5:23 PM, Moritz Maxeiner wrote:
On Tuesday, 25 July 2017 at 20:16:41 UTC, Stev
On 7/26/2017 6:29 AM, Kagamin wrote:
Should we still try to mark them safe at all?
Marking ones that are safe with @safe is fine. OS APIs pretty much never change.
On 7/26/2017 3:14 AM, Timon Gehr wrote:
On 26.07.2017 05:02, Walter Bright wrote:
The implementation checks for fp being NULL and returns EOF if it is.
The C mindset is that this check is a waste of precious processing resources and
morally wrong, as only a fool would pass NULL anyway, and fo
On Wednesday, 26 July 2017 at 03:16:44 UTC, Walter Bright wrote:
On 7/25/2017 6:09 PM, Steven Schveighoffer wrote:
Likewise, because D depends on hardware flagging of
dereferencing null as a segfault, any platforms that *don't*
have that for C also won't have it for D. And then @safe
doesn't e
On Wednesday, 26 July 2017 at 01:09:50 UTC, Steven Schveighoffer
wrote:
On 7/25/17 8:45 PM, Timon Gehr wrote:
On 26.07.2017 02:35, Steven Schveighoffer wrote:
On 7/25/17 5:23 PM, Moritz Maxeiner wrote:
On Tuesday, 25 July 2017 at 20:16:41 UTC, Steven
Schveighoffer wrote:
The behavior is defin
On Wednesday, 26 July 2017 at 02:54:34 UTC, Walter Bright wrote:
* Operating system APIs grow like weeds. We'd set ourselves an
impossible task.
It is worthwhile, however, to augment the APIs with the
appropriate attributes like @nogc, scope, nothrow, @safe (for
the ones that are)
On Tuesday, 25 July 2017 at 18:36:35 UTC, Moritz Maxeiner wrote:
fgetc cannot be @trusted the same way fclose cannot be @trusted.
If you pass either of them `null` - which constitutes a legal
@safe context - the behaviour is undefined, which contradicts
@trusted definition:
exhibit any undefine
On 7/26/17 7:55 AM, Timon Gehr wrote:
On 26.07.2017 13:22, Steven Schveighoffer wrote:
On 7/26/17 6:01 AM, Timon Gehr wrote:
On 26.07.2017 03:09, Steven Schveighoffer wrote:
...
In other words, I think we can assume for any C functions that are
passed pointers that dereference those pointers,
On 26.07.2017 13:22, Steven Schveighoffer wrote:
On 7/26/17 6:01 AM, Timon Gehr wrote:
On 26.07.2017 03:09, Steven Schveighoffer wrote:
...
In other words, I think we can assume for any C functions that are
passed pointers that dereference those pointers, passing null is
safely going to segfa
On 7/26/17 6:01 AM, Timon Gehr wrote:
On 26.07.2017 03:09, Steven Schveighoffer wrote:
On 7/25/17 8:45 PM, Timon Gehr wrote:
...
What Moritz is saying is that the following implementation of fclose
is correct according to the C standard:
int fclose(FILE *stream){
if(stream == NULL){
On 7/26/17 3:05 AM, Shachar Shemesh wrote:
On 25/07/17 18:26, Andrei Alexandrescu wrote:
(btw void[] doesn't work)
Can you expand on this point?
Shachar
Because anything casts to void[] implicitly.
e.g.:
void main() @safe
{
int *[] arr = new int*[5];
read(0, arr); // reading raw poi
On 26.07.2017 05:02, Walter Bright wrote:
On 7/25/2017 5:56 PM, Andrei Alexandrescu wrote:
I'd think that would be the case, but failed to find a fgetc
implementation that mentions it's undefined for a null FILE*. Is there
a link? Thx. -- Andrei
The documentation for DMC++ fgetc() is:
htt
On 26.07.2017 02:56, Andrei Alexandrescu wrote:
What Moritz is saying is that the following implementation of fclose
is correct according to the C standard:
int fclose(FILE *stream){
if(stream == NULL){
return go_wild_and_corrupt_all_the_memory();
}else{
return act
On 26.07.2017 03:09, Steven Schveighoffer wrote:
On 7/25/17 8:45 PM, Timon Gehr wrote:
...
What Moritz is saying is that the following implementation of fclose
is correct according to the C standard:
int fclose(FILE *stream){
if(stream == NULL){
return go_wild_and_corrupt_all_th
assed to pthread_create does not, logically,
run in the pthread_create function. As such, I don't think
this logic holds.
Then the @nogc definition would need to be updated from: "or
indirectly through functions it may call" to reflect this,
because that can be interpreted both wa
On Wednesday, 26 July 2017 at 00:35:13 UTC, Steven Schveighoffer
wrote:
On 7/25/17 5:23 PM, Moritz Maxeiner wrote:
On Tuesday, 25 July 2017 at 20:16:41 UTC, Steven Schveighoffer
wrote:
The behavior is defined. It will crash with a segfault.
In C land that behaviour is a platform (hardware/OS/
On 25/07/17 18:26, Andrei Alexandrescu wrote:
(btw void[] doesn't work)
Can you expand on this point?
Shachar
s such, I don't think this logic holds.
Then the @nogc definition would need to be updated from: "or indirectly
through functions it may call" to reflect this, because that can be
interpreted both ways.
As for pthread_join, I have no idea what you meant by it. Please
elaborate
On 7/25/2017 6:09 PM, Steven Schveighoffer wrote:
Likewise, because D depends on hardware flagging of dereferencing null as a
segfault, any platforms that *don't* have that for C also won't have it for D.
And then @safe doesn't even work in D code either.
I spent 10 years programming on DOS wi
101 - 200 of 1445 matches
Mail list logo
