Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
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 ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | 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 ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Friedman | 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 ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | > 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 ? | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Friedman | 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 |
Copyright © 1999-2021 by the D Language Foundation