View mode: basic / threaded / horizontal-split · Log in · Help
January 05, 2006
(Mac) TypeInfo bug ?
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
Re: (Mac) TypeInfo bug ?
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
Re: (Mac) TypeInfo bug ?
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
Re: (Mac) TypeInfo bug ?
> 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
Re: (Mac) TypeInfo bug ?
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
Top | Discussion index | About this forum | D home