Re: null dereference exception vs. segfault?
Pelle: > If NotNull will be in a library, it should probably use enforce, if I > have understood things correctly. External input, and all that. I think > most of phobos does it like this currently. I suspect that Andrei has still to "get" DbC :-) (And your lib is not Phobos.) Bye, bearophile
Re: null dereference exception vs. segfault?
In the meantime I have written the first part of the Bugzilla entry about non-null: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=114391 Bye, bearophile
Re: null dereference exception vs. segfault?
On 08/03/2010 01:08 AM, bearophile wrote:
Pelle:
struct NotNull(T) if(is(typeof(T.init !is null))) {
Is this enough?
struct NotNull(T) if (is(T.init is null)) {
this(T t) {
enforce(t !is null, "Cannot create NotNull from null");
enforce() is bad, use Design by Contract instead (a precondition with an assert
inside).
Bye,
bearophile
If NotNull will be in a library, it should probably use enforce, if I
have understood things correctly. External input, and all that. I think
most of phobos does it like this currently.
Re: null dereference exception vs. segfault?
> Is this enough?
> struct NotNull(T) if (is(T.init is null)) {
Sorry, I meant:
struct NotNull(T) if (T.init is null) {
Bye,
bearophile
Re: null dereference exception vs. segfault?
Pelle:
> struct NotNull(T) if(is(typeof(T.init !is null))) {
Is this enough?
struct NotNull(T) if (is(T.init is null)) {
> this(T t) {
> enforce(t !is null, "Cannot create NotNull from null");
enforce() is bad, use Design by Contract instead (a precondition with an assert
inside).
Bye,
bearophile
Re: null dereference exception vs. segfault?
On 08/03/2010 12:32 AM, bearophile wrote:
Pelle:
I think a good thing would be NonNull!T, but I haven't managed to create
one. If this structure exists and becomes good practice to use, maybe we
can get the good syntax in D3. In 20 years or so :P
Maybe we are talking about two different things, I was talking about nonnull
class references/pointers, you seem to talk about nullable values :-) Both can
be useful in D, but they are different things.
Nullable values are simpler to design, they are just wrapper structs that
contain a value plus a boolean, plus if you want some syntax sugar to manage
them with a shorter syntax.
Bye,
bearophile
I am talking about non-nullable references indeed. I don't think I
mentioned nullable types, really.
I also created this, as the simplest NotNull-type concievable:
struct NotNull(T) if(is(typeof(T.init !is null))) {
private T _instance;
this(T t) {
enforce(t !is null, "Cannot create NotNull from null");
_instance = t;
}
T get() {
assert (_instance !is null,
text("Supposed NotNull!(", T.stringof, ") is null"));
return _instance;
}
alias get this;
}
This has the obvious bug in that you can declare a nonnull without an
initializer and get a null from it. If we ever get @disable this(){} for
structs, this struct can become better.
I'll probably try it out in some code.
Re: null dereference exception vs. segfault?
Pelle: > I think a good thing would be NonNull!T, but I haven't managed to create > one. If this structure exists and becomes good practice to use, maybe we > can get the good syntax in D3. In 20 years or so :P Maybe we are talking about two different things, I was talking about nonnull class references/pointers, you seem to talk about nullable values :-) Both can be useful in D, but they are different things. Nullable values are simpler to design, they are just wrapper structs that contain a value plus a boolean, plus if you want some syntax sugar to manage them with a shorter syntax. Bye, bearophile
Re: null dereference exception vs. segfault?
On 08/03/2010 12:02 AM, bearophile wrote:
Pelle:
What I really wish for is non-nullable types, though. Maybe in D3... :P
I think there is no enhancement request in Bugzilla about this, I will add one.
I think there has been, at least this has been discussed on the newsgroup.
To implement this you have to think about the partially uninitialized objects
too, this is a paper about it, given a class type T it defines four types (I
think the four types are managed by the compiler only, the programmer uses only
two of them, nullable class references and nonnullable ones):
http://research.microsoft.com/pubs/67461/non-null.pdf
If a language defaults to nonnullable references, then you can use this syntax:
class T {}
T nonnullable_instance = new T;
T? nullable_instance;
But now it's probably nearly impossible to make D references nonnullable on
default, so that syntax can't be used. And I don't what syntax to use yet.
Suggestions welcome.
Bye,
bearophile
That is a good syntax indeed. What is also needed is a way of
conditionally getting the reference out of the nullable.
I think delight uses something like this:
T? nullable;
if actual = nullable:
actual.dostuff;
I think a good thing would be NonNull!T, but I haven't managed to create
one. If this structure exists and becomes good practice to use, maybe we
can get the good syntax in D3. In 20 years or so :P
Re: null dereference exception vs. segfault?
> But now it's probably nearly impossible to make D references nonnullable on
> default, so that syntax can't be used. And I don't what syntax to use yet.
> Suggestions welcome.
One of the few ideas I have had is to use the @ suffix for this:
class T {}
T nullable_reference;
T@ nonnullable_reference = new T@();
struct S {}
S nullable_pointer;
S@ nonnullable_pointer = new S@();
(Beside nonnullable class references/pointers, another way to catch bugs that I
miss in D are the ranged integers of ObjectPascal/Ada. Walter doesn't like
them, I think he thinks they are a failed idea, but I don't agree and I don't
remember why he thinks so.)
Bye,
bearophile
Re: null dereference exception vs. segfault?
Pelle:
> Null Pointer Exception!
Ah, I see. I hate TLA (Three Letter Acronyms).
> What I really wish for is non-nullable types, though. Maybe in D3... :P
I think there is no enhancement request in Bugzilla about this, I will add one.
To implement this you have to think about the partially uninitialized objects
too, this is a paper about it, given a class type T it defines four types (I
think the four types are managed by the compiler only, the programmer uses only
two of them, nullable class references and nonnullable ones):
http://research.microsoft.com/pubs/67461/non-null.pdf
If a language defaults to nonnullable references, then you can use this syntax:
class T {}
T nonnullable_instance = new T;
T? nullable_instance;
But now it's probably nearly impossible to make D references nonnullable on
default, so that syntax can't be used. And I don't what syntax to use yet.
Suggestions welcome.
Bye,
bearophile
Re: std.file.read
Dmitry Olshansky:
> Dang, DMD does not even type check the unitest code when the compiler
> option not passed.
This is a small known problem of D newsgroups. To partially cope with it at the
end of each module I add something like:
unittest { printf(__FILE__ ~ " unittest performed."); }
But among the enhancement requests of the D unit-testing there need to be a
better solution to that problem too.
Bye,
bearophile
Re: null dereference exception vs. segfault?
On 08/02/2010 11:27 PM, bearophile wrote: Ryan W Sims: The problem isn't how to check it on a case-by-case basis, there are plenty of ways to check that a given pointer is non-null. The problem is debugging _unexpected_ null dereferences, for which a NPE or its equivalent is very helpful, a segfault is _not_. I don't know what NPE is, but if you program with DbC your nulls are very often found out by asserts, so you have assert errors (that show line number& file name) instead of segfaults. Null Pointer Exception! However, I agree with getting segfaults from them. Otherwise, you will be tempted to use the exception handling mechanisms to catch null pointer exceptions, which is a bad thing. I also agree with the notion of using DbC to find nulls. What I really wish for is non-nullable types, though. Maybe in D3... :P
Re: null dereference exception vs. segfault?
Jonathan M Davis: > As for indexing into an array, the array itself should be null or not. It has > no > size if it's null, so it makes no sense to talk about large arrays which are > null. Technically dynamic arrays in D are represented with a 2-word struct that contains a pointer and length. So empty dynamic arrays are two zero words. In D there is also the literal [] that in my opinion is better to represent an empty array than just "null": http://d.puremagic.com/issues/show_bug.cgi?id=3889 Bye, bearophile
Re: null dereference exception vs. segfault?
Ryan W Sims: > The problem isn't how to check it on a case-by-case basis, there are > plenty of ways to check that a given pointer is non-null. The problem is > debugging _unexpected_ null dereferences, for which a NPE or its > equivalent is very helpful, a segfault is _not_. I don't know what NPE is, but if you program with DbC your nulls are very often found out by asserts, so you have assert errors (that show line number & file name) instead of segfaults. > Sorry, didn't mean to reopen a can of worms, just wanted to be clear. When people that discuss are polite there is no problem in reopening the can now and then :-) Bye, bearophile
Re: null dereference exception vs. segfault?
On Monday, August 02, 2010 08:34:50 Jeffrey Yasskin wrote: > That's good to know. Unfortunately, reading through a null pointer > does cause undefined behavior: it's not a guaranteed segfault. > Consider an object with a large array at the beginning, which pushes > later members past the empty pages at the beginning of the address > space. I don't suppose the D compiler watches for such large objects > and emits actual null checks before indexing into them? There are no null checks. When people have requested in the past that null checks be added (like you'd get in Java), Walter has indicated that he thought that there was no point to them because the OS takes care of them already by giving you a segfault. I'm not personally well-versed enough in exactly what goes on at the hardware or OS level to produce a segfault, so I can't say whether a segfault is absolutely guaranteed. It has been my understanding that it is. As for indexing into an array, the array itself should be null or not. It has no size if it's null, so it makes no sense to talk about large arrays which are null. On top of that, bounds checking is usually done on arrays (off of the top of my head, I don't remember the exact circumstances under which it's removed, but it's almost always there), so you wouldn't be able to index past its end, and if it's an element of the array that you're dereferencing, then whether that element is null or not will determine whether it segfaults. > > The pages that you're looking at there need to be updated for clarity. > > Nice use of the passive voice. Who needs to update them? Is their > source somewhere you or I could send a patch? Submit a bug report to bugzilla: http://d.puremagic.com/issues/ - Jonathan M Davis
Re: Sections in Ddoc?
On Mon, Aug 2, 2010 at 09:18, Lutger wrote: > > It isn't supported out of the box. You could further process ddoc output, I > had > something working nicely by spitting out xml instead of html and then using > xquery to generate the docs, but am too much pressed for time to finish it. > > A more lightweight approach is to insert a css class though a custom ddoc > macro: > > API_GROUP = > > From there you can use css selectors for styling. I'm not sure how far you > can > get with just css. A wee bit of jquery might help. It will be pretty awkard > anyway I suppose. > OK, thanks. I'll admit it readily: I've barely touched css, and I don't have the faintest idea what a selector is, nor how to use jquery. So I'll write it down as something that you cannot do easily and hope for brighter tomorrows. Philippe
Re: Initializing static arrays without specifying size
On Mon, Aug 2, 2010 at 14:15, bearophile wrote: > > That's one solution, but code like that is most useful when your arrays > liters are long (because if they are little you can just count the items and > avoid using staticArray) Yes, but as Ziad said: "If I want a static array (...) I'd have to specify the size in advance (5 in this case), which means that adding extra elements later on would require that the size be update." So small-size arrays _are_ a possibility. Ziad: > Thanks for your feedback Philippe and bearophile :) If you understand the code, very well. If not, say so. I know I'd have been unable to understand it two years ago. Philippe
Re: Debug OutOfMemoryError?
On 2010-08-02 14:34, Steven Schveighoffer wrote: On Sat, 31 Jul 2010 05:55:40 -0400, Jacob Carlborg wrote: How do I debug an OutOfMemoryError? I'm trying to run a simple application that uses SDL and OpenGL with Derelict on Mac OS X 10.6. It works fine using D1 and Tango but fails with the message "Memory allocation failed" when I use D2. I probably messed something up when I ported the Mac specific parts of Derelict SDL to make it work with D2. But how do I debug it when it just prints "Memory allocation failed" and exits with code 01? I can't catch the exception and even if I could it would be useless because it doesn't contain any stack trace, what it looks like after looking at the druntime source code. Any advise? Try compiling druntime in debug mode with -gc, then debug the application, putting a breakpoint at the point where it prints the error. -Steve I'll give that a try, thanks. -- /Jacob Carlborg
Re: null dereference exception vs. segfault?
On 8/2/10 10:33 AM, bearophile wrote: Mafi: If you want a NullPointerException as part of your program flow, you can use enforce() (in std.contracts I think). I don't think catching a NullPointerException in a big code block where you don't know which dereferencing should fail is good style. enforce() is not a panacea (panchrest); as far as I know DMD doesn't inline any function that contains enforce(). So sometimes an assert() is better, especially if it's inside a contract (precondition, etc). DesignByConstrac-style programming is not something that just happens, you have to train yourself for some time for it. Bye, bearophile The problem isn't how to check it on a case-by-case basis, there are plenty of ways to check that a given pointer is non-null. The problem is debugging _unexpected_ null dereferences, for which a NPE or its equivalent is very helpful, a segfault is _not_. Sorry, didn't mean to reopen a can of worms, just wanted to be clear. -- rwsims
Re: std.file.read
On 02.08.2010 21:36, bearophile wrote:
Pelle:
Well, it magically converts to whatever array type you have. So this works:
ubyte[] data = read("trash.txt");
This code does not work for me on dmd 2.047.
AH, nor for me.
Bye,
bearophile
Hm... it doesn't ...
Ouch, I was very much sure the unittest run, but unfortunately it didn't
(it was some other debug output then...).
Dang, DMD does not even type check the unitest code when the compiler
option not passed.
Again, my apologizes.
--
Dmitry Olshansky
Re: xfbuild, optlink and pragma(lib)
Am 02.08.2010 06:16, schrieb Mike Parker: Mafi wrote: The tool sounds cool but it seems that I have to buy it, so that's no option for me. So I tried to compile SDL myself. I have to say I'm to stupid for it. I tried to do the same thing as the makefile in powershell. After I hacked together some solution that worked dmc complained about missing Gl.h. It isn't there. So I added some MinGW to the include-path and then I get a bunch of errors in SDL without linenumbers. And anyways I am trying to compile it without MinGW, aren't I. Please, help me! I've converted it for you. You can download it here: http://aldacron.net/downloads/sdl.lib Thank you, but the download is corrupt for me. It's <1kb and most of it is '\0'. I downloaded objconv so I should be able to do it myself. Mafi
Re: std.file.read
Pelle:
> > Well, it magically converts to whatever array type you have. So this works:
> > ubyte[] data = read("trash.txt");
>
> This code does not work for me on dmd 2.047.
AH, nor for me.
Bye,
bearophile
Re: null dereference exception vs. segfault?
Mafi: > If you want a NullPointerException as part of your program flow, you can > use enforce() (in std.contracts I think). I don't think catching a > NullPointerException in a big code block where you don't know which > dereferencing should fail is good style. enforce() is not a panacea (panchrest); as far as I know DMD doesn't inline any function that contains enforce(). So sometimes an assert() is better, especially if it's inside a contract (precondition, etc). DesignByConstrac-style programming is not something that just happens, you have to train yourself for some time for it. Bye, bearophile
Re: std.file.read
On 08/02/2010 10:23 AM, Dmitry Olshansky wrote:
On 02.08.2010 5:23, bearophile wrote:
Can you tell me why std.file.read() returns a void[] instead of
something like a ubyte[]?
Well, it magically converts to whatever array type you have. So this works:
ubyte[] data = read("trash.txt");
This code does not work for me.
It's interesting fact deserving further investigation. It seems that
void[] arrays are converted implicitly, this also works:
void[] tr = malloc(20)[0..20];
data = tr;
Neither does this.
I am running 2.047, am I doing something wrong?
Re: null dereference exception vs. segfault?
Am 02.08.2010 16:50, schrieb Ryan W Sims:
On 8/2/10 1:56 AM, Jonathan M Davis wrote:
On Sunday 01 August 2010 21:59:42 Ryan W Sims wrote:
The following code fails with a "Bus error" (OSX speak for "Segfault,"
if I understand correctly).
// types.d
import std.stdio;
class A {
int x = 42;
}
void fail_sometimes(int n) {
A a;
if (n == 0) {
a = new A; // clearly a contrived example
}
assert(a.x == 42, "Wrong x value");
}
void main() {
fail_sometimes(1);
}
It's even worse if I do a 'dmd -run types.d', it just fails without even
the minimalistic "Bus error." Is this correct behavior? I searched the
archives& looked at the FAQ& found workarounds (registering a signal
handler), but not a justification, and the threads were from a couple
years ago. Wondering if maybe something has changed and there's a
problem with my system?
--
rwsims
You are getting a segmentation fault because you are dereferencing a null
reference. All references are default initialized to null. So, if you
fail to
explicitly initialize them or to assign to them, then they stay null,
and in
such a case, you will get a segfault if you try to dereference them.
Yes, I know *why* I'm getting a segfault, thank you - I set up the
example explicitly to defeat the compiler's null checking to test the
behavior. I was startled that there wasn't an exception thrown w/ a
stack trace.
[snip]
Unlike Java, there is no such thing as a NullPointerException in D.
You just get
segfaults - just like you would in C++. So, if you don't want
segfaults from
derefencing null references, you need to make sure that they aren't
null when
you dereference them.
- Jonathan M Davis
That was my question, thanks. It seemed like such an un-D thing to have
happen; I was surprised. I guess w/o the backing of a full virtual
machine, it's tricker to catch null dereferences on the fly, but boy
it'd be nice to have. Don't want to re-fire the debate here, though.
--
rwsims
If you want a NullPointerException as part of your program flow, you can
use enforce() (in std.contracts I think). I don't think catching a
NullPointerException in a big code block where you don't know which
dereferencing should fail is good style.
Mafi
Re: Initializing static arrays without specifying size
BCS: > Is that with or without inline? If that doesn't inline away to a memcopy > then it looks like an optimization opportunity to me. That's with inline, but if you don't use inline the result is the same, because that is the asm of a function, not of its caller (the main), so DMD keeps the not inlined function around anyway even when it inlines it. So in your binary you find all the staticArray() you have instantiated/used. This is the main (compiled with -O -release -inline, dmd 2.047): __Dmain comdat L0: sub ESP,0194h push0190h push03DEh push03D4h push03CAh push03C0h push03B6h push03ACh push03A2h push0398h push038Eh push0384h push037Ah push0370h push0366h push035Ch push0352h push0348h push033Eh push0334h push032Ah push0320h push0316h push030Ch push0302h push02F8h push02EEh push02E4h push02DAh push02D0h push02C6h push02BCh push02B2h push02A8h push029Eh push0294h push028Ah push0280h push0276h push026Ch push0262h push0258h push024Eh push0244h push023Ah push0230h push0226h push021Ch push0212h push0208h push01FEh push01F4h push01EAh push01E0h push01D6h push01CCh push01C2h push01B8h push01AEh push01A4h push019Ah push0190h push0186h push017Ch push0172h push0168h push015Eh push0154h push014Ah push0140h push0136h push012Ch push0122h push0118h push010Eh push0104h push0FAh push0F0h push0E6h push0DCh push0D2h push0C8h push0BEh mov EAX,offset FLAT:_D14TypeInfo_G100i6__initZ push0B4h push0AAh push0A0h push096h push08Ch push082h push078h push06Eh push064h push05Ah push050h push046h push03Ch push032h push028h push01Eh push014h push0Ah push0 push064h pushEAX callnear ptr __d_arrayliteralT add ESP,0198h pushEAX lea ECX,0Ch[ESP] pushECX callnear ptr _memcpy mov EDX,offset FLAT:_DATA pushdword ptr 018h[ESP] pushEDX callnear ptr _printf add ESP,014h add ESP,0194h xor EAX,EAX ret Bye, bearophile
Re: Initializing static arrays without specifying size
Thanks for your feedback Philippe and bearophile :) Cheers, -- Ziad
Re: Initializing static arrays without specifying size
Hello bearophile,
Philippe Sigaud:
Would a template-based solution be OK?
import std.stdio, std.traits;
CommonType!T[T.length] staticArray(T...)(T vals)
if ((T.length > 0) && is(CommonType!T))
{
return [vals];
}
That's one solution, but code like that is most useful when your
arrays liters are long (because if they are little you can just count
the items and avoid using staticArray), this is an example (I have
used printf to avoid the metric ton of functions and templates used by
writeln):
import std.c.stdio: printf;
import std.traits: CommonType;
CommonType!T[T.length] staticArray(T...)(T vals)
if (T.length && is(CommonType!T)) {
return [vals];
}
void main() {
auto a = staticArray(0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100,
...
990);
printf("%d\n", a[2]);
}
This is the asm of the staticArray:
_D5test2217__T11staticArrayTiÉÛÿ ÀÀÈÈZÖFiiÉÛÿ ¤¤ZG100i
comdat
L0: pushEAX
pushESI
pushEDI
pushdword ptr 010h[ESP]
...
pushdword ptr 0328h[ESP]
push064h
pushECX
callnear ptr __d_arrayliteralT
mov ESI,EAX
mov EDI,01A0h[ESP]
mov ECX,064h
rep
movsd
add ESP,0198h
mov EAX,8[ESP]
pop EDI
pop ESI
pop ECX
ret 0190h
Is that with or without inline? If that doesn't inline away to a memcopy
then it looks like an optimization opportunity to me.
And you essentially have one similar function each time you use
staticArray. This is why in my answer I have said I don't know any
good solution to this problem and this is why I have proposed the
enhancement [$] syntax.
In my code I count the items in some way (with Python, or I assign the
literal to a dynamic array, print its length and then modify the code
replacing the dynamic array with the printed number).
Bye,
bearophile
--
... <
Re: null dereference exception vs. segfault?
Jeffrey Yasskin: > That's good to know. Unfortunately, reading through a null pointer > does cause undefined behavior: it's not a guaranteed segfault. > Consider an object with a large array at the beginning, which pushes > later members past the empty pages at the beginning of the address > space. I don't suppose the D compiler watches for such large objects > and emits actual null checks before indexing into them? I am not expert enough to give you a good answer about this, but do some tests :-) And later if you want you may say the same things in the main D newsgroup. Bye, bearophile
Re: null dereference exception vs. segfault?
On Mon, Aug 2, 2010 at 1:49 AM, Jonathan M Davis wrote:
> On Monday 02 August 2010 00:05:40 Jeffrey Yasskin wrote:
>> Even better, you can annotate fail_sometimes with @safe, and it'll
>> still access out-of-bounds memory.
>>
>> Take the following with a grain of salt since I'm really new to the
>> language.
>>
>> gdb says:
>> Reason: KERN_PROTECTION_FAILURE at address: 0x0008
>> 0x1e52 in D4test14fail_sometimesFiZv ()
>>
>> which indicates that 'a' is getting initialized to null (possibly by
>> process startup 0ing out the stack), and then x is being read out of
>> it. You can get exactly the same crashes in C++ by reading member
>> variables out of null pointers. The D compiler is supposed to catch
>> the uninitialized variable ("It is an error to use a local variable
>> without first assigning it a value." in
>> http://www.digitalmars.com/d/2.0/function.html), but clearly it's
>> missing this one.
>>
>> I haven't actually found where in the language spec it says that class
>> variables are pointers, or what their default values are. I'd expect
>> to find this in http://www.digitalmars.com/d/2.0/type.html, but no
>> luck.
>>
>> Looking through the bug tracker ... Walter's response to
>> http://d.puremagic.com/issues/show_bug.cgi?id=671 seems to indicate
>> that he isn't serious about uninitialized use being an error. It's
>> just undefined behavior like in C++.
>>
>> In any case, the fix for your problem will be to initialize 'a' before
>> using it.
>
> _All_ variables in D are initialized with a default value. There should be
> _no_
> undefined behavior with regards to initializations. D is very concientious
> about
> avoiding undefined behavior. In the case of references and pointers, they are
> initialized to null.
That's good to know. Unfortunately, reading through a null pointer
does cause undefined behavior: it's not a guaranteed segfault.
Consider an object with a large array at the beginning, which pushes
later members past the empty pages at the beginning of the address
space. I don't suppose the D compiler watches for such large objects
and emits actual null checks before indexing into them?
> The pages that you're looking at there need to be updated for clarity.
Nice use of the passive voice. Who needs to update them? Is their
source somewhere you or I could send a patch?
Re: null dereference exception vs. segfault?
On 8/2/10 1:56 AM, Jonathan M Davis wrote:
On Sunday 01 August 2010 21:59:42 Ryan W Sims wrote:
The following code fails with a "Bus error" (OSX speak for "Segfault,"
if I understand correctly).
// types.d
import std.stdio;
class A {
int x = 42;
}
void fail_sometimes(int n) {
A a;
if (n == 0) {
a = new A; // clearly a contrived example
}
assert(a.x == 42, "Wrong x value");
}
void main() {
fail_sometimes(1);
}
It's even worse if I do a 'dmd -run types.d', it just fails without even
the minimalistic "Bus error." Is this correct behavior? I searched the
archives& looked at the FAQ& found workarounds (registering a signal
handler), but not a justification, and the threads were from a couple
years ago. Wondering if maybe something has changed and there's a
problem with my system?
--
rwsims
You are getting a segmentation fault because you are dereferencing a null
reference. All references are default initialized to null. So, if you fail to
explicitly initialize them or to assign to them, then they stay null, and in
such a case, you will get a segfault if you try to dereference them.
Yes, I know *why* I'm getting a segfault, thank you - I set up the
example explicitly to defeat the compiler's null checking to test the
behavior. I was startled that there wasn't an exception thrown w/ a
stack trace.
[snip]
Unlike Java, there is no such thing as a NullPointerException in D. You just get
segfaults - just like you would in C++. So, if you don't want segfaults from
derefencing null references, you need to make sure that they aren't null when
you dereference them.
- Jonathan M Davis
That was my question, thanks. It seemed like such an un-D thing to have
happen; I was surprised. I guess w/o the backing of a full virtual
machine, it's tricker to catch null dereferences on the fly, but boy
it'd be nice to have. Don't want to re-fire the debate here, though.
--
rwsims
Re: Doubled newlines
It makes sense now. Thanks. :)
Steven Schveighoffer Wrote:
> On Sat, 31 Jul 2010 23:10:05 -0400, Andrej Mitrovic
> wrote:
>
> > Oh and I'm getting the same issue in Python when using CR only. I don't
> > know why I have the CR option in the text editor if it doesn't work
> > properly. I guess CR is used on the Macs maybe..?
> >
> > Andrej Mitrovic Wrote:
> >
> >> I'm getting normal newlines here (XP):
> >>
> >> C:\output>test.exe
> >> import std.file: readText;
> >> import std.stdio: write;
> >> void main() {
> >> string s = readText("test.d");
> >> write(s);
> >> }
> >>
> >> The text used CR+LF newlines. I also tried them using LF newlines,
> >> which worked fine. But I've then tried with CR and that gives out weird
> >> output like so:
> >>
> >> } write(s);= readText("test.d");
>
> CR means carriage return. This is for old-style line printers. When you
> sent a CR, it means, literally, move the carriage back to the front of the
> line. When you sent a LF (line feed), it means, feed the paper another
> line.
>
> If you printed a file to such a printer with just line feeds, you would
> see:
>
> import std.file: readText;
>import std.stdio: write;
>void main() {
> ...
>
>
> If you printed the file with just CRs, you would see all the lines
> super-imposed over eachother, because the paper is never moved, just the
> carriage is returned.
>
> This is the effect you are seeing, each line is super-imposed over the
> other. However, on a terminal, you don't see the residual letters from
> previously printed lines, they are completely overwritten.
>
> Essentially, if you put in a sleep between printing each line, what you'd
> see is this:
>
> import std.file: readText;
>
> .. pause ..
>
> import std.stdio: write;t;
>
> .. pause ..
>
> void main() {dio: write;t;
>
>
>
> Hope this helps ;)
>
> -Steve
Re: xfbuild, optlink and pragma(lib)
[1] http://www.digitalmars.com/ctg/coff2omf.html [2] http://www.digitalmars.com/download/freecompiler.html The tool sounds cool but it seems that I have to buy it, so that's no option for me. Yeah, it's a pity that such an important tool for D development on Windoze isn't free. You may try objconv though: http://www.agner.org/optimize/?e=0,24#objconv
Re: Debug OutOfMemoryError?
On Sat, 31 Jul 2010 05:55:40 -0400, Jacob Carlborg wrote: How do I debug an OutOfMemoryError? I'm trying to run a simple application that uses SDL and OpenGL with Derelict on Mac OS X 10.6. It works fine using D1 and Tango but fails with the message "Memory allocation failed" when I use D2. I probably messed something up when I ported the Mac specific parts of Derelict SDL to make it work with D2. But how do I debug it when it just prints "Memory allocation failed" and exits with code 01? I can't catch the exception and even if I could it would be useless because it doesn't contain any stack trace, what it looks like after looking at the druntime source code. Any advise? Try compiling druntime in debug mode with -gc, then debug the application, putting a breakpoint at the point where it prints the error. -Steve
Re: null dereference exception vs. segfault?
On Mon, 02 Aug 2010 00:59:42 -0400, Ryan W Sims wrote:
The following code fails with a "Bus error" (OSX speak for "Segfault,"
if I understand correctly).
// types.d
import std.stdio;
class A {
int x = 42;
}
void fail_sometimes(int n) {
A a;
if (n == 0) {
a = new A; // clearly a contrived example
}
assert(a.x == 42, "Wrong x value");
}
void main() {
fail_sometimes(1);
}
It's even worse if I do a 'dmd -run types.d', it just fails without even
the minimalistic "Bus error." Is this correct behavior? I searched the
archives & looked at the FAQ & found workarounds (registering a signal
handler), but not a justification, and the threads were from a couple
years ago. Wondering if maybe something has changed and there's a
problem with my system?
I'm not familiar with dmd -run, but you should be aware that asserts are
not compiled into release code.
Try changing the assert to this:
if(a.x != 42) writeln("Wrong x value");
FWIW, D does not have null pointer exceptions, even in debug mode. It's
an oft-debated subject, but Walter hasn't ever budged on it. His view is
that you should use a debugger to see where your code is failing. We have
pointed out countless times that often it's not possible to have a
debugger at hand, or even be able to reproduce the issue that caused the
segfault while in a different environment. I don't know if we'll ever see
null pointer exceptions, but I'd love them in debug mode only, or at least
to see a stack trace when it occurs. The latter can be done without
Phobos/dmd help if someone can write such a signal handler function. I
don't know enough about stack traces to understand how to do it.
-Steve
Re: A confusing expression?
Steven Schveighoffer: > No warning, no error. It's natural to assume that operations are > performed from left to right. I don't find it confusing at all. Thank you for your opinion Steven. I am now leaning toward your idea, because I think raising an error in this case it too much, and the other solutions I see are not good enough. So I presume this problem can be left to future D lint programs. Bye, bearophile
Re: A confusing expression?
On Sun, 01 Aug 2010 19:22:42 -0400, bearophile
wrote:
Time ago an automatic tool has said that in a line of C code similar to:
int r = x / y * z;
a division operator followed by a mult is confusing, and to add
parentheses to improve the code:
int r = (x / y) * z;
When values are integral the position of parentheses can change the
value of the expression:
void main() {
int x = 10;
int y = 3;
int z = 5;
assert(x / y * z == 15);
assert((x / y) * z == 15);
assert(x / (y * z) == 0);
}
That has nothing to do with integral arguments. That has to do with
precedence.
assert(x / y * z == (x / y) * z);
is going to pass no matter what the value/type of x, y, z.
And given the values you have for x y z, the following statement is also
true regardless of type:
assert(x / y * z != x / (y * z));
Turning 'x / y * z' into a D syntax error (as done in bug
http://d.puremagic.com/issues/show_bug.cgi?id=4077 ) looks excessive to
me. A warning seems enough, but Walter is not a lover of warnings (and
sometimes I agree, I'd like to turn three D warnings into errors). What
do you think?
No warning, no error. It's natural to assume that operations are
performed from left to right. I don't find it confusing at all.
-Steve
Re: Initializing static arrays without specifying size
Philippe Sigaud:
> Would a template-based solution be OK?
>
> import std.stdio, std.traits;
>
> CommonType!T[T.length] staticArray(T...)(T vals)
> if ((T.length > 0) && is(CommonType!T))
> {
> return [vals];
> }
That's one solution, but code like that is most useful when your arrays liters
are long (because if they are little you can just count the items and avoid
using staticArray), this is an example (I have used printf to avoid the metric
ton of functions and templates used by writeln):
import std.c.stdio: printf;
import std.traits: CommonType;
CommonType!T[T.length] staticArray(T...)(T vals)
if (T.length && is(CommonType!T)) {
return [vals];
}
void main() {
auto a = staticArray(0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120,
130, 140, 150, 160, 170, 180, 190, 200, 210, 220, 230,
240, 250, 260, 270, 280, 290, 300, 310, 320, 330, 340,
350, 360, 370, 380, 390, 400, 410, 420, 430, 440, 450,
460, 470, 480, 490, 500, 510, 520, 530, 540, 550, 560,
570, 580, 590, 600, 610, 620, 630, 640, 650, 660, 670,
680, 690, 700, 710, 720, 730, 740, 750, 760, 770, 780,
790, 800, 810, 820, 830, 840, 850, 860, 870, 880, 890,
900, 910, 920, 930, 940, 950, 960, 970, 980, 990);
printf("%d\n", a[2]);
}
This is the asm of the staticArray:
_D5test2217__T11staticArrayTiÉÛÿ ÀÀÈÈZÖFiiÉÛÿ ¤¤ZG100i comdat
L0: pushEAX
pushESI
pushEDI
pushdword ptr 010h[ESP]
pushdword ptr 018h[ESP]
pushdword ptr 020h[ESP]
pushdword ptr 028h[ESP]
pushdword ptr 030h[ESP]
pushdword ptr 038h[ESP]
pushdword ptr 040h[ESP]
pushdword ptr 048h[ESP]
pushdword ptr 050h[ESP]
pushdword ptr 058h[ESP]
pushdword ptr 060h[ESP]
pushdword ptr 068h[ESP]
pushdword ptr 070h[ESP]
pushdword ptr 078h[ESP]
pushdword ptr 080h[ESP]
pushdword ptr 088h[ESP]
pushdword ptr 090h[ESP]
pushdword ptr 098h[ESP]
pushdword ptr 0A0h[ESP]
pushdword ptr 0A8h[ESP]
pushdword ptr 0B0h[ESP]
pushdword ptr 0B8h[ESP]
pushdword ptr 0C0h[ESP]
pushdword ptr 0C8h[ESP]
pushdword ptr 0D0h[ESP]
pushdword ptr 0D8h[ESP]
pushdword ptr 0E0h[ESP]
pushdword ptr 0E8h[ESP]
pushdword ptr 0F0h[ESP]
pushdword ptr 0F8h[ESP]
pushdword ptr 0100h[ESP]
pushdword ptr 0108h[ESP]
pushdword ptr 0110h[ESP]
pushdword ptr 0118h[ESP]
pushdword ptr 0120h[ESP]
pushdword ptr 0128h[ESP]
pushdword ptr 0130h[ESP]
pushdword ptr 0138h[ESP]
pushdword ptr 0140h[ESP]
pushdword ptr 0148h[ESP]
pushdword ptr 0150h[ESP]
pushdword ptr 0158h[ESP]
pushdword ptr 0160h[ESP]
pushdword ptr 0168h[ESP]
pushdword ptr 0170h[ESP]
pushdword ptr 0178h[ESP]
pushdword ptr 0180h[ESP]
pushdword ptr 0188h[ESP]
pushdword ptr 0190h[ESP]
pushdword ptr 0198h[ESP]
pushdword ptr 01A0h[ESP]
pushdword ptr 01A8h[ESP]
pushdword ptr 01B0h[ESP]
pushdword ptr 01B8h[ESP]
pushdword ptr 01C0h[ESP]
pushdword ptr 01C8h[ESP]
pushdword ptr 01D0h[ESP]
pushdword ptr 01D8h[ESP]
pushdword ptr 01E0h[ESP]
pushdword ptr 01E8h[ESP]
pushdword ptr 01F0h[ESP]
pushdword ptr 01F8h[ESP]
pushdword ptr 0200h[ESP]
pushdword ptr 0208h[ESP]
pushdword ptr 0210h[ESP]
pushdword ptr 0218h[ESP]
pushdword ptr 0220h[ESP]
pushdword ptr 0228h[ESP]
pushdword ptr 0230h[ESP]
pushdword ptr 0238h[ESP]
pushdword ptr 0240h[ESP]
pushdword ptr 0248h[ESP]
pushdword ptr 0250h[ESP]
pushdword ptr 0258h[ESP]
pushdword ptr 0260h[ESP]
pushdword ptr 0268h[ESP]
pushdword ptr 0270h[ESP]
pushdword ptr 0278h[ESP]
pushdword ptr 0280h[ESP]
pushdword ptr 0288h[ESP]
mov ECX,offset FLAT:_D14TypeInfo_G100i6__initZ
pushdword ptr 0290h[ESP]
pushdword ptr 0298h[ESP]
pushdword ptr 02A0h[ESP]
pushdword ptr 02A8h[ESP]
pushdword ptr 02B0h[ESP]
pushdword ptr 02B8h[ESP]
pushdword ptr 02C0h[ESP]
pushdword ptr 02C8h[ESP]
pushdword ptr 02D0h[ESP]
pushdword ptr 02D8h[ESP]
pushdword ptr 0
Re: Doubled newlines
On Sat, 31 Jul 2010 23:10:05 -0400, Andrej Mitrovic
wrote:
Oh and I'm getting the same issue in Python when using CR only. I don't
know why I have the CR option in the text editor if it doesn't work
properly. I guess CR is used on the Macs maybe..?
Andrej Mitrovic Wrote:
I'm getting normal newlines here (XP):
C:\output>test.exe
import std.file: readText;
import std.stdio: write;
void main() {
string s = readText("test.d");
write(s);
}
The text used CR+LF newlines. I also tried them using LF newlines,
which worked fine. But I've then tried with CR and that gives out weird
output like so:
} write(s);= readText("test.d");
CR means carriage return. This is for old-style line printers. When you
sent a CR, it means, literally, move the carriage back to the front of the
line. When you sent a LF (line feed), it means, feed the paper another
line.
If you printed a file to such a printer with just line feeds, you would
see:
import std.file: readText;
import std.stdio: write;
void main() {
...
If you printed the file with just CRs, you would see all the lines
super-imposed over eachother, because the paper is never moved, just the
carriage is returned.
This is the effect you are seeing, each line is super-imposed over the
other. However, on a terminal, you don't see the residual letters from
previously printed lines, they are completely overwritten.
Essentially, if you put in a sleep between printing each line, what you'd
see is this:
import std.file: readText;
.. pause ..
import std.stdio: write;t;
.. pause ..
void main() {dio: write;t;
Hope this helps ;)
-Steve
Re: Doubled newlines
On Sat, 31 Jul 2010 21:15:21 -0400, bearophile
wrote:
I think there is a bug here, but can you please try it a bit?
The name of this program is "test.d", so it loads its souce code:
import std.file: readText;
import std.stdio: write;
void main() {
string s = readText("test.d");
write(s);
}
On windows the output is:
import std.file: readText;
import std.stdio: write;
void main() {
string s = readText("test.d");
write(s);
}
So it shows extra newlines (on Windows newlines are two chars).
On Windows a similar Python program doesn't show the doubled newlines:
s = open("test.d").read()
print s
Copy-pasting the source from an editor to the newsgroup window may not
allow others to see the problem, since it may have to do with non-visible
characters.
Attach the file directly to a news post, then maybe we can repeat it
easier.
-Steve
Re: string initialization question.
On Fri, 30 Jul 2010 19:41:03 -0400, Justin Spahr-Summers wrote: On Fri, 30 Jul 2010 16:30:17 -0700, Jonathan M Davis wrote: On Friday, July 30, 2010 14:13:15 dcoder wrote: > If I'm writing a program that pretty prints tree data, or output of sql, > like Oracle's sqlplus, or postgres equivalent, I find having such a > utility function/constructor a pretty handy feature. > > I don't know where such a tool should finally be placed in D, but I having > it available as a library or as part of the language would be great. It > seems like a lot of other languages have it like python, perl, C++, and > Java. So it can't be that useless. Well, I certainly have no problem with a function like makeArray() existing. It's just that it's one of those functions that I've never found useful, and I don't think that I've ever seen anyone use it in code. That's because it's not a trivial function to write :) One has to have intimate knowledge of the runtime and understand how to properly allocate a block for this purpose. Basically, there have been code instances of the form: T[] x = new T[n]; x[] = initval; Because that's the only way to do it. Offer a function like makeArray, and why *wouldn't* you change to it? I prefer a single line/initialization anyways. I agree with this sentiment. I think the feature is pretty niche to begin with, and the compiler should be able to optimize out the initialization in the sample I gave previously. D is indeed a systems language, but I (and I'm sure others) would like to use it in a high- level way, where I can write natural, straightforward code and expect the compiler to do the Right Thing. I just find the syntax awkward: char[] divider = new char[5]; // hey, compiler I'm initializing divider divider[] = '-'; // OOHHH got you there, I wasn't done yet :) It just seems natural that I should be able to do this in one line. Having the compiler optimize isn't a bad thing, but relying on the optimization because "we can't find a better way" seems crappy to me. Besides, performance is not an applicable argument for this use case. Even if the array initialization is compiled into the binary, the amount of time it would take is infinitesimal. If someone's trying to initialize a 100,000 element array to some specific value, they're likely going to write their own makeArray() anyways. The performance improvement is certainly a smaller argument compared to the syntax. But it is a nice bonus. There are more significant performance bugs in initialization of static arrays using array literals. -Steve
Re: string initialization question.
On Sat, 31 Jul 2010 05:37:41 -0400, Jason Spencer
wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
I was wrong, I looked through the runtime and did not find such a
function.
std.string has a repeat() function. Try:
import std.string;
void main()
{
string divider = repeat("-", 5);
writeln(divider);
}
It doesn't do the right thing. It allocates, then initializes, resulting
in a double-initialization.
-Steve
Re: A confusing expression?
Jason Spencer: > the result is not unambiguous, it just requires that the > reader understand precedence. That's an arguably good thing in any > case. You can say exactly the same thing regarding bug 4077. But we have chosen otherwise. Programming is done by people that do mistakes, so in some situations it's better to forbid some bug-prone syntax. In the case of * / the tool I have used asks for extra parenthesis. In this case I don't know what the best solution is yet. Bye, bearophile
Re: std.file.read
Dmitry Olshansky:
> Well, it magically converts to whatever array type you have. So this works:
> ubyte[] data = read("trash.txt");
In more than tree years of nearly daily usage of D I have not even tried to
write that code :-)
Thank you,
bearophile
Re: null dereference exception vs. segfault?
Jonathan M Davis: > _All_ variables in D are initialized with a default value. There should be > _no_ > undefined behavior with regards to initializations. D is very concientious > about > avoiding undefined behavior. See also: http://d.puremagic.com/issues/show_bug.cgi?id=3820 Bye, bearophile
Re: null dereference exception vs. segfault?
On Sunday 01 August 2010 21:59:42 Ryan W Sims wrote:
> The following code fails with a "Bus error" (OSX speak for "Segfault,"
> if I understand correctly).
>
> // types.d
> import std.stdio;
>
> class A {
> int x = 42;
> }
>
> void fail_sometimes(int n) {
> A a;
> if (n == 0) {
> a = new A; // clearly a contrived example
> }
> assert(a.x == 42, "Wrong x value");
> }
>
> void main() {
> fail_sometimes(1);
> }
>
> It's even worse if I do a 'dmd -run types.d', it just fails without even
> the minimalistic "Bus error." Is this correct behavior? I searched the
> archives & looked at the FAQ & found workarounds (registering a signal
> handler), but not a justification, and the threads were from a couple
> years ago. Wondering if maybe something has changed and there's a
> problem with my system?
>
> --
> rwsims
You are getting a segmentation fault because you are dereferencing a null
reference. All references are default initialized to null. So, if you fail to
explicitly initialize them or to assign to them, then they stay null, and in
such a case, you will get a segfault if you try to dereference them.
If you changed your code to
import std.stdio;
class A {
int x = 42;
}
void fail_sometimes(int n) {
A a;
if (n == 0) {
a = new A; // clearly a contrived example
}
assert(a !is null, "a shouldn't be null");
assert(a.x == 42, "Wrong x value");
}
void main() {
fail_sometimes(1);
}
you would get output something like this
core.exception.asserter...@types.d(12): a shouldn't be null
./types() [0x804b888]
./types() [0x8049360]
./types() [0x8049399]
./types() [0x804ba54]
./types() [0x804b9b9]
./types() [0x804ba91]
./types() [0x804b9b9]
./types() [0x804b968]
/opt/lib32/lib/libc.so.6(__libc_start_main+0xe6) [0xf760bc76]
./types() [0x8049261]
Unlike Java, there is no such thing as a NullPointerException in D. You just
get
segfaults - just like you would in C++. So, if you don't want segfaults from
derefencing null references, you need to make sure that they aren't null when
you dereference them.
- Jonathan M Davis
Re: null dereference exception vs. segfault?
On Monday 02 August 2010 00:05:40 Jeffrey Yasskin wrote:
> Even better, you can annotate fail_sometimes with @safe, and it'll
> still access out-of-bounds memory.
>
> Take the following with a grain of salt since I'm really new to the
> language.
>
> gdb says:
> Reason: KERN_PROTECTION_FAILURE at address: 0x0008
> 0x1e52 in D4test14fail_sometimesFiZv ()
>
> which indicates that 'a' is getting initialized to null (possibly by
> process startup 0ing out the stack), and then x is being read out of
> it. You can get exactly the same crashes in C++ by reading member
> variables out of null pointers. The D compiler is supposed to catch
> the uninitialized variable ("It is an error to use a local variable
> without first assigning it a value." in
> http://www.digitalmars.com/d/2.0/function.html), but clearly it's
> missing this one.
>
> I haven't actually found where in the language spec it says that class
> variables are pointers, or what their default values are. I'd expect
> to find this in http://www.digitalmars.com/d/2.0/type.html, but no
> luck.
>
> Looking through the bug tracker ... Walter's response to
> http://d.puremagic.com/issues/show_bug.cgi?id=671 seems to indicate
> that he isn't serious about uninitialized use being an error. It's
> just undefined behavior like in C++.
>
> In any case, the fix for your problem will be to initialize 'a' before
> using it.
_All_ variables in D are initialized with a default value. There should be _no_
undefined behavior with regards to initializations. D is very concientious
about
avoiding undefined behavior. In the case of references and pointers, they are
initialized to null. There's not really such a thing as using a variable
without
initializing it, because variables are default initialized if you don't
initialize them yourself. The _one_ exception would be if you explicitly
initialized a variable to void:
int[] a = void;
In that case, you are _explicitly_ telling the compiler not to default
initialize the variable. That _can_ lead to undefined behavior and is
definitely
unsafe. As such, it is intended solely for the purposes of optimizing code
where
absolutely necessary. So, you really shouldn't have any variables in your code
that weren't initialized, even if you didn't initialize them explicitly.
The pages that you're looking at there need to be updated for clarity.
- Jonathan M Davis
Re: std.file.read
On 02.08.2010 5:23, bearophile wrote:
Can you tell me why std.file.read() returns a void[] instead of something like
a ubyte[]?
Well, it magically converts to whatever array type you have. So this
works:
ubyte[] data = read("trash.txt");
It's interesting fact deserving further investigation. It seems that
void[] arrays are converted implicitly, this also works:
void[] tr = malloc(20)[0..20];
data = tr;
(Performing a cast(ubyte[]) in SafeD can be a problem. I presume in SafeD I
have to use other safer functions to load binary data, like slurp() or
something similar.)
Bye,
bearophile
--
Dmitry Olshansky
Re: Sections in Ddoc?
Philippe Sigaud wrote: > Hi, > > as per Nick's advice, I was reading on Goldie's GenDocs template documentation > system: > > http://www.semitwist.com/goldiedocs/v0.3/Docs/Tools/GenDocs/TemplateFormat/ > > That's a nice work, and I saw there something I'd like to do with Ddocs: > sections. As in, document sections. > > Ideally there are some modules I'd like to document that way: > > > Module Name > > some general documentation on the module, what its use is supposed to be, the > things to do, etc. Imagine an algorithm module, for example. > > Section #1 - Sorting. > general documentation on the section, a specific part of the module. Say, > sorting. > > functions documentation for section 1. > > Section #2 - Finding. > another subject there, say finding elements in a range... General explanations > on the modules assumptions, trade-off, etc. > > functions documentation for section 2. > > an so on... > > But I cannot do that with DDocs. Or can I? > Does anyone know a way to do this? > > (ideally, I'd also like a summary-like part, like in Wikipedia :) ) > > Philippe It isn't supported out of the box. You could further process ddoc output, I had something working nicely by spitting out xml instead of html and then using xquery to generate the docs, but am too much pressed for time to finish it. A more lightweight approach is to insert a css class though a custom ddoc macro: API_GROUP = >From there you can use css selectors for styling. I'm not sure how far you can get with just css. A wee bit of jquery might help. It will be pretty awkard anyway I suppose.
Re: null dereference exception vs. segfault?
Even better, you can annotate fail_sometimes with @safe, and it'll
still access out-of-bounds memory.
Take the following with a grain of salt since I'm really new to the language.
gdb says:
Reason: KERN_PROTECTION_FAILURE at address: 0x0008
0x1e52 in D4test14fail_sometimesFiZv ()
which indicates that 'a' is getting initialized to null (possibly by
process startup 0ing out the stack), and then x is being read out of
it. You can get exactly the same crashes in C++ by reading member
variables out of null pointers. The D compiler is supposed to catch
the uninitialized variable ("It is an error to use a local variable
without first assigning it a value." in
http://www.digitalmars.com/d/2.0/function.html), but clearly it's
missing this one.
I haven't actually found where in the language spec it says that class
variables are pointers, or what their default values are. I'd expect
to find this in http://www.digitalmars.com/d/2.0/type.html, but no
luck.
Looking through the bug tracker ... Walter's response to
http://d.puremagic.com/issues/show_bug.cgi?id=671 seems to indicate
that he isn't serious about uninitialized use being an error. It's
just undefined behavior like in C++.
In any case, the fix for your problem will be to initialize 'a' before using it.
On Sun, Aug 1, 2010 at 9:59 PM, Ryan W Sims wrote:
> The following code fails with a "Bus error" (OSX speak for "Segfault," if I
> understand correctly).
>
> // types.d
> import std.stdio;
>
> class A {
> int x = 42;
> }
>
> void fail_sometimes(int n) {
> A a;
> if (n == 0) {
> a = new A; // clearly a contrived example
> }
> assert(a.x == 42, "Wrong x value");
> }
>
> void main() {
> fail_sometimes(1);
> }
>
> It's even worse if I do a 'dmd -run types.d', it just fails without even the
> minimalistic "Bus error." Is this correct behavior? I searched the archives
> & looked at the FAQ & found workarounds (registering a signal handler), but
> not a justification, and the threads were from a couple years ago. Wondering
> if maybe something has changed and there's a problem with my system?
>
> --
> rwsims
>
Re: A confusing expression?
I'm just trying to figure out what the error would be, exactly. That a programmer, knowing the language specification, obeyed it and wrote an expression using the shortest syntax? Rhetoric aside, the result is not unambiguous, it just requires that the reader understand precedence. That's an arguably good thing in any case. I could also make a similar argument that allowing operator overloading might be confusing and so should be disallowed. It's just an unfortunate fact that programming requires some attention to detail.
