www.digitalmars.com         C & C++   DMDScript  

D - obj == null causes out of memory exception or stiffs the prog.

reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
if the following is build with Win32 DMD 0.43

import stream;

class OutputBuffer
{
public:
 this() { }
}

int main( char[][] args )
{
 try {
 OutputBuffer buf;

 printf("start:\n");
 if ( buf == null ) { buf = new OutputBuffer(); }

 printf("done:\n");

 } catch (Exception e ) {
  printf("Exception caught:\n");
  e.print();
 }
 return 0;
}

and then run, it just outputs the first line. 'start: ' then stiffs.
if you add a member function or two, (I had a couple and a char[][]
lines,member)
then you get the message 'Error: Out of memory'

if you comment out the   if ( buf == null ) line then it runs ( the =new
.... works )

Mike.
Oct 01 2002
parent reply Burton Radons <loth users.sourceforge.net> writes:
Mike Wynn wrote:

 if the following is build with Win32 DMD 0.43
 
 import stream;
 
 class OutputBuffer
 {
 public:
  this() { }
 }
 
 int main( char[][] args )
 {
  try {
  OutputBuffer buf;
 
  printf("start:\n");
  if ( buf == null ) { buf = new OutputBuffer(); }


The "==" operator is transformed into "buf.eq (null)"; calling methods 
on null usually stalls.  The "===" operator is the one for comparing 
stack cells, or you may be able to do "!buf" (you definitely can on DLI, 
but DMD's a little clumsy when it comes to logic).
Oct 01 2002
next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Burton Radons wrote:


 The "==" operator is transformed into "buf.eq (null)"; calling methods
 on null usually stalls.


Given that (as I understand it) buf is supposed to be null here, should we
get a segfault?  Is the stall designed behavior or a bug to be fixed?

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Oct 01 2002
prev sibling next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
arr, guess I should read the docs ...
I do find the === and !== operators a bit odd
with arrays == (2'='s) and (=== 3'='s) behave the same when checking against
null
(although new char[0] == null might be ok but new char[0] === null still
bugs me)

what type is null ? in Java arrays are objects and there are no pointers so
null is an object

what does  if ( null == null )  { } do ? null.eq(null) or null === null ?
(FYI null==null and null===null are both true)

but in D null can be pointer, array or object
in D pointers and arrays are similar so I feel that null should be a
pointer/array type
and borrow the pascal/delphi/oberon 'nil' be used for the object 'null'
( obj == null ) would then cause a incompatable type compile time error
and (obj == nil ) would call obj.eq( nil ); and should cause the compiler to
issue a warning
(object value compared to nil at line ...)

This might help fools such as I, who write D code with a head full of C,
C++, Java, Php and Perl syntax and make me thing about what I'm doing!


"Burton Radons" <loth users.sourceforge.net> wrote in message
news:3D99C541.2020701 users.sourceforge.net...

 Mike Wynn wrote:

  if ( buf == null ) { buf = new OutputBuffer(); }


 The "==" operator is transformed into "buf.eq (null)"; calling methods
 on null usually stalls.  The "===" operator is the one for comparing
 stack cells, or you may be able to do "!buf" (you definitely can on DLI,
 but DMD's a little clumsy when it comes to logic).
Oct 01 2002
parent Burton Radons <loth users.sourceforge.net> writes:
Mike Wynn wrote:

 arr, guess I should read the docs ...
 I do find the === and !== operators a bit odd
 with arrays == (2'='s) and (=== 3'='s) behave the same when checking against
 null
 (although new char[0] == null might be ok but new char[0] === null still
 bugs me)


I don't like it either; it's hard to remember to use it when it's 
practically indistinguishable from ==.  "is" would be handier.


 what type is null ? in Java arrays are objects and there are no pointers so
 null is an object


null takes its type from the expression context.


 what does  if ( null == null )  { } do ? null.eq(null) or null === null ?
 (FYI null==null and null===null are both true)


null assumes the type of (void *) when there's no context.  So it's just 
a pointer comparison.


 but in D null can be pointer, array or object
 in D pointers and arrays are similar so I feel that null should be a
 pointer/array type
 and borrow the pascal/delphi/oberon 'nil' be used for the object 'null'
 ( obj == null ) would then cause a incompatable type compile time error
 and (obj == nil ) would call obj.eq( nil ); and should cause the compiler to
 issue a warning
 (object value compared to nil at line ...)


Why?  It should definitely throw up if you try to call a method on a 
null object when debugging is on, but that's an easy thing to have, and 
it could be seen as invalid to compare objects against null.  Adding 
another keyword looks pointless.


 This might help fools such as I, who write D code with a head full of C,
 C++, Java, Php and Perl syntax and make me thing about what I'm doing!
Oct 01 2002
prev sibling parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:3D99C541.2020701 users.sourceforge.net...

 Mike Wynn wrote:

 if the following is build with Win32 DMD 0.43

 import stream;

 class OutputBuffer
 {
 public:
  this() { }
 }

 int main( char[][] args )
 {
  try {
  OutputBuffer buf;

  printf("start:\n");
  if ( buf == null ) { buf = new OutputBuffer(); }


 The "==" operator is transformed into "buf.eq (null)"; calling methods
 on null usually stalls.  The "===" operator is the one for comparing
 stack cells...


Maybe the compiler could produce a warning (please) if explicit null is
compared to an object with the original non-overloaded eq member from the
Object class.
Oct 02 2002
parent "Walter" <walter digitalmars.com> writes:
"Sandor Hojtsy" <hojtsy index.hu> wrote in message
news:anea1p$c78$1 digitaldaemon.com...

 The "==" operator is transformed into "buf.eq (null)"; calling methods
 on null usually stalls.  The "===" operator is the one for comparing
 stack cells...


 Maybe the compiler could produce a warning (please) if explicit null is
 compared to an object with the original non-overloaded eq member from the
 Object class.


You're right, I should investigate doing something about this. -Walter
Oct 12 2002