Thread overview
(Mac) TypeInfo bug ?
Jan 06, 2006
David Friedman
January 05, 2006
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
#0  0x00004e28 in _D3std6stream6Stream6vreadfFAC8TypeInfoPaZi ()
#1  0x0003102c in _arguments_Aa ()
#2  0x00005b38 in _D3std6stream6Stream5readfFYi ()

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...
January 06, 2006
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
> #0  0x00004e28 in _D3std6stream6Stream6vreadfFAC8TypeInfoPaZi ()
> #1  0x0003102c in _arguments_Aa ()
> #2  0x00005b38 in _D3std6stream6Stream5readfFYi ()
> 
> 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...
January 06, 2006
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
January 06, 2006
> 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
December 15, 2006
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