www.digitalmars.com         C & C++   DMDScript  

D.gnu - (Mac) TypeInfo bug ?

reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Was trying the new stream readf out:
(on OS X 10.3 with gdc-0.17/gcc-3.3)

import std.stdio;

import std.stream;
import std.cstream;

int main()
{
   char[] name;

   dout.writef("What is your name? ");
   din.readf(&name);

   writefln("Hello, %s", name);
   return 0;
}

But it just crashed: (stupid no-contracts Phobos)

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x00004e28 in _D3std6stream6Stream6vreadfFAC8TypeInfoPaZi ()
(gdb) bt




Recompiling it without -release and with -g too,
then I got: Error: ArrayBoundsError stream.d(719)

So it seems that none of the default formats matched ?
(which was strange since printing it said "char[]*"...)


Adding some debugging code shows the main problem here:

	else
	{
	  std.stdio.writefln(arguments[j] is typeid(char[]*));
	  std.stdio.writefln(arguments[j] == typeid(char[]*));
	}

Which outputs: (integers since I didn't cast-to-bit)

0
1


So: is the root of the problem in GDC, or in Phobos ?
(i.e. should one be able to expect that the TypeInfo
is *identical* to typeid, or will it only be equal to)

It seems to be working OK in gdmd on Linux. (and DMD)

--anders


PS. Wonder what it will take to get readf into std.stdio...
Jan 05 2006
parent reply David Friedman <dvdfrdmn users.ess-eff.net> writes:
This is the same GDC issue that causes templates to not work (you're 
using gcc 3.x, right?).  Both modules need to emit TypeInfo for char[]* 
because there is no single "correct" place to do so.  Without "link 
once" support, GDC emits private copies in each module.

I have not been able think of simple a solution for this.  A complex 
solution might involve registering TypeInfo pointers using the mangled 
name as a key...

David

Anders F Björklund wrote:

 Was trying the new stream readf out:
 (on OS X 10.3 with gdc-0.17/gcc-3.3)
 
 import std.stdio;
 
 import std.stream;
 import std.cstream;
 
 int main()
 {
   char[] name;
 
   dout.writef("What is your name? ");
   din.readf(&name);
 
   writefln("Hello, %s", name);
   return 0;
 }
 
 But it just crashed: (stupid no-contracts Phobos)
 
 Program received signal EXC_BAD_ACCESS, Could not access memory.
 0x00004e28 in _D3std6stream6Stream6vreadfFAC8TypeInfoPaZi ()
 (gdb) bt



 
 Recompiling it without -release and with -g too,
 then I got: Error: ArrayBoundsError stream.d(719)
 
 So it seems that none of the default formats matched ?
 (which was strange since printing it said "char[]*"...)
 
 
 Adding some debugging code shows the main problem here:
 
     else
     {
       std.stdio.writefln(arguments[j] is typeid(char[]*));
       std.stdio.writefln(arguments[j] == typeid(char[]*));
     }
 
 Which outputs: (integers since I didn't cast-to-bit)
 
 0
 1
 
 
 So: is the root of the problem in GDC, or in Phobos ?
 (i.e. should one be able to expect that the TypeInfo
 is *identical* to typeid, or will it only be equal to)
 
 It seems to be working OK in gdmd on Linux. (and DMD)
 
 --anders
 
 
 PS. Wonder what it will take to get readf into std.stdio...
Jan 05 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
David Friedman wrote:


 This is the same GDC issue that causes templates to not work (you're 
 using gcc 3.x, right?).  Both modules need to emit TypeInfo for char[]* 
 because there is no single "correct" place to do so.  Without "link 
 once" support, GDC emits private copies in each module.


I'm using GCC 3.x on Panther, yes. (and GCC 4.x, when on Tiger...)

But this was a Mac-only problem, yes ? Since I didn't get the same
results when using GCC 3.x on Linux (it tested OK with Fedora Core)


 I have not been able think of simple a solution for this.  A complex 
 solution might involve registering TypeInfo pointers using the mangled 
 name as a key...


Wonder how much work patching GCC to allow once-only linking is ?

i.e. "move" that feature over from Apple's GCC3 to the FSF GCC3...
http://www.opensource.apple.com/darwinsource/DevToolsAug2004/gcc-1762/

--anders
Jan 06 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
 Wonder how much work patching GCC to allow once-only linking is ?
 
 i.e. "move" that feature over from Apple's GCC3 to the FSF GCC3...
 http://www.opensource.apple.com/darwinsource/DevToolsAug2004/gcc-1762/


The "correct" GCC was "3.3 20030304 (Apple Computer, Inc. build 1666)" :
http://www.opensource.apple.com/darwinsource/DevToolsAug2004/gcc_os-1666/

Other seems to be a more experimental GCC source, and not for gdcmac...

--anders
Jan 06 2006
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
David Friedman wrote: (as in, a year ago)


 (i.e. should one be able to expect that the TypeInfo
 is *identical* to typeid, or will it only be equal to)





 This is the same GDC issue that causes templates to not work (you're 
 using gcc 3.x, right?).  Both modules need to emit TypeInfo for char[]* 
 because there is no single "correct" place to do so.  Without "link 
 once" support, GDC emits private copies in each module.
 
 I have not been able think of simple a solution for this.  A complex 
 solution might involve registering TypeInfo pointers using the mangled 
 name as a key...


I don't think it will ever be fixed for GCC 3.3 / Mac OS X 10.3 ?

In the meantime I'm adding a small note to gdcmac that templates
needs Mac OS X 10.4 / GCC4 to work and aren't supported fully for
Mac OS X 10.2/10.3 and that this will break readf/DMDScript/etc.

But if someone has a patch to enable "link once" for GCC 3.3.6
on Darwin, I would be happy to apply it to the gdcmac 0.20 build.
(i.e. the same way that I ported .framework support over earlier)

--anders
Dec 15 2006