www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - might be a bug in the DMD FrontEnd

reply Davidl <Davidl 126.com> writes:
i don't see what prevent the following from compiling:
import std.stdio;
char[] ctfe()
{
	wchar[] k=3Dcast(wchar[])"int  =

i;/*asdfasf"~cast(wchar[])("adf"~cast(char)100~cast(char)192~cast(char)2=
50)~cast(wchar[])"dsafj*/  =

int j;";
	char[] jimmy =3D cast(char[])(k[0..k.length-1]);
	int i;
	for(i=3D0;i<jimmy.length;)
	{
		if (jimmy[i]=3D=3D0)
			jimmy=3Djimmy[0..i]~jimmy[i+1..jimmy.length];
		else
			i++;
	}
	return jimmy;
	=

}
void main()
{
	mixin(ctfe);
	char[] k=3Dctfe;
         printf ("%s",k.ptr);
}

and by viewing the frontend, i think there might be a bug of slicing  =

wchar[] in compile time.
ilwr, iupr ain't taken care of for wchar[] and dchar[] case

Regards,
David Leon
Mar 29 2007
next sibling parent reply Davidl <Davidl 126.com> writes:
sorry i didn't read the frontend carefully enough. it handles the  
different cases.
but i still don't get why my little func couldn't be evaulated in compile  
time
Mar 29 2007
parent Davidl <Davidl 126.com> writes:
err in constfold.c
func cat declare and assign Type t;
but t never used?
	t =3D es2->type;
	es->type =3D type;
either es->type =3D t; or an assertion might be preferred?
Mar 29 2007
prev sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Davidl wrote:
 i don't see what prevent the following from compiling:
I can see a few things...
 import std.stdio;
 char[] ctfe()
 {
     wchar[] k=cast(wchar[])"int
What's with the casting? http://www.digitalmars.com/d/lex.html#StringLiteral -- see the part on "Postfix" characters. I'm fairly certain that cast(wchar[]) doesn't do what you *think* it's doing. cast(wchar[]) casts an array of chars into an array of wchars... note that I *did not* say "converts" -- UTF-8 and UTF-16 are very different encodings, so you can't just cast between them and expect it to make any sense. It would be like casting a double pointer to a ushort pointer -- meaningless. Also, I can't work out why you would want to embed a comment in a mixin string, but it's not especially problematic :P
 i;/*asdfasf"~cast(wchar[])("adf"~cast(char)100~cast(char)192~cast(char)250)~cast(wchar[])"dsafj*/
cast(char)192, whilst technically valid, is really nasty. For starters, '192' isn't a valid character by itself in UTF-8, which means it can't be printed. Not to mention the potential byte-order problems. We have Unicode escape sequences for a reason. Again, see the section on string literals, but basically, we have "\x12" for ASCII characters, "\u1234" for wide characters, and "\U12345678" for really wide characters. And, again, that cast doesn't make any sense.
 int j;";
     char[] jimmy = cast(char[])(k[0..k.length-1]);
Dear lord, why?! You just spent half your time casting it to a wchar array, and now you're casting it back?! char[] is perfectly capable of storing Unicode text, if that's what you're worried about. Also, you're cutting off the last character of the string, which means you're losing that last ";", which means your mixin isn't valid, and will cause compilation to fail.
     int i;
     for(i=0;i<jimmy.length;)
     {
         if (jimmy[i]==0)
             jimmy=jimmy[0..i]~jimmy[i+1..jimmy.length];
         else
             i++;
     }
The only reason I can come up with as to why you're doing the above is because all that casting above generates a string with null characters in it... which it wouldn't if you didn't use all the casting.
     return jimmy;
     
 }
 void main()
 {
     mixin(ctfe);
     char[] k=ctfe;
         printf ("%s",k.ptr);
Please don't use printf, at least not without passing the string through toStringz. writefln works perfectly fine. I mean, you even imported std.stdio... Ok, let's try rewriting this... import std.stdio; wchar[] ctfe() { wchar[] k = "int i;/*asdfasf"w~("adf"w~cast(wchar)'\x64'~cast(wchar)'\u1234')~"dsafj*/ int j;"; return k; } void main() { mixin(ctfe()); wchar[] k = ctfe(); writefln("%s", k); } The above works perfectly. Heck, we could get rid of those cast(wchars) by just using wchar strings: "\x64\u1234"w.
 }
 
 and by viewing the frontend, i think there might be a bug of slicing
 wchar[] in compile time.
 ilwr, iupr ain't taken care of for wchar[] and dchar[] case
 
 Regards,
 David Leon
It could well be there's a bug in the frontend. But this is kind of like setting your house on fire, and then pointing out there's a burn-mark on the wall. :P -- Daniel -- int getRandomNumber() { return 4; // chosen by fair dice roll. // guaranteed to be random. } http://xkcd.com/ v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Mar 29 2007
parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Daniel Keep wrote:
 Davidl wrote:
 i don't see what prevent the following from compiling:
I can see a few things...
<...>
 cast(char)192, whilst technically valid, is really nasty.  For starters,
 '192' isn't a valid character by itself in UTF-8, which means it can't
 be printed.
<...>
 Please don't use printf, at least not without passing the string through
 toStringz.  writefln works perfectly fine.
Perhaps he's using printf because he wants to output the byte 192 without getting an "Error: 4invalid UTF-8 sequence". I've found that, currently, in both Phobos and Tango, the C library is the best way of outputting a character whilst letting the user worry about whether he can see it properly in his locale or not. The point about toStringz still stands, though.
Mar 30 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Deewiant wrote:
 Daniel Keep wrote:
 Davidl wrote:
 i don't see what prevent the following from compiling:
I can see a few things...
<...>
 cast(char)192, whilst technically valid, is really nasty.  For starters,
 '192' isn't a valid character by itself in UTF-8, which means it can't
 be printed.
<...>
 Please don't use printf, at least not without passing the string through
 toStringz.  writefln works perfectly fine.
Perhaps he's using printf because he wants to output the byte 192 without getting an "Error: 4invalid UTF-8 sequence". I've found that, currently, in both Phobos and Tango, the C library is the best way of outputting a character whilst letting the user worry about whether he can see it properly in his locale or not. The point about toStringz still stands, though.
True; I hadn't considered that. The first thing I thought was that he didn't know about Unicode literals, and was trying to manually encode the character in UTF-16. That said, I personally think that if you need to use printf because writefln is barfing on your string, then that's a bug in your program. char[] is UTF-8: if you're not storing UTF-8, you should be using ubyte[], not char[]. Incidentally, since D source must be either ASCII or some variant of UTF, cast(char)192 isn't a valid character *anyway*, unless it's part of a multibyte code-point, at which point the argument for outputting it literally falls apart since he's using it in a mixin :P Also, I just realised that the "you can't cast arrays of chars around" is something I should add to my text in D article... -- Daniel -- int getRandomNumber() { return 4; // chosen by fair dice roll. // guaranteed to be random. } http://xkcd.com/ v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Mar 30 2007
parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Daniel Keep wrote:
 That said, I personally think that if you need to use printf because
 writefln is barfing on your string, then that's a bug in your program.
 char[] is UTF-8: if you're not storing UTF-8, you should be using
 ubyte[], not char[].
I agree. However, both Phobos and Tango use char[] for all their string-processing functions _which also work on non-UTF-8_. This means that to call such a function you need to do, for instance, "std.string.strip(*cast(char[])iso-8859-1-string.ptr);" which gets ugly very quickly. I hoped that Tango would use ubyte[] in the C standard library, at least, but no. I understand why not (standard; most people use only char[] and don't want to do the cast from char[]* to ubyte[]* as above; good for ASCII anyway), and so I don't complain, but it's still something I'd like. Perhaps D needs a way to allow implicit conversion: finally(ubyte[] is char[]) { char[] foo(ubyte[] myString) { return std.string.strip(myString.dup); } } <g>
Mar 30 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Deewiant wrote:
 Daniel Keep wrote:
 That said, I personally think that if you need to use printf because
 writefln is barfing on your string, then that's a bug in your program.
 char[] is UTF-8: if you're not storing UTF-8, you should be using
 ubyte[], not char[].
I agree. However, both Phobos and Tango use char[] for all their string-processing functions _which also work on non-UTF-8_. This means that to call such a function you need to do, for instance, "std.string.strip(*cast(char[])iso-8859-1-string.ptr);" which gets ugly very quickly. I hoped that Tango would use ubyte[] in the C standard library, at least, but no. I understand why not (standard; most people use only char[] and don't want to do the cast from char[]* to ubyte[]* as above; good for ASCII anyway), and so I don't complain, but it's still something I'd like. Perhaps D needs a way to allow implicit conversion: finally(ubyte[] is char[]) { char[] foo(ubyte[] myString) { return std.string.strip(myString.dup); } } <g>
 foreach( dchar c ; some_string )
 {
     // ...
 }
Would *not* work correctly with the above if your string contains anything outside of the ASCII range. Yes, the functions might work with non-UTF-8 codepages, but that's more a side-effect of how they are implemented. I think what Phobos really needs is a character encoding conversion library, even if it's just a paper-thin binding to iconv or something. -- Daniel [1] I hope I've got the right term; I'm liable to get my head chewed off if I'm wrong :P -- int getRandomNumber() { return 4; // chosen by fair dice roll. // guaranteed to be random. } http://xkcd.com/ v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Mar 30 2007
next sibling parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Daniel Keep wrote:
 foreach( dchar c ; some_string )
 {
     // ...
 }
Would *not* work correctly with the above if your string contains anything outside of the ASCII range. Yes, the functions might work with non-UTF-8 codepages, but that's more a side-effect of how they are implemented.
True. But it's hard to implement (some of) them _without_ supporting non-UTF-8. <g> And there's always the C standard library.
 I think what Phobos really needs is a character encoding conversion
 library, even if it's just a paper-thin binding to iconv or something.
 
The problem is that you often aren't told the encoding, and have to work with just bytes. You can guess (and I'm sure some pretty smart heuristics have been developed for this), but it's not perfect, and you still need ASCII whitespace stripping to work, regardless of the encoding.* * Okay, so if the 0-127 range isn't ASCII, it won't work, but that's practically nonexistent these days (at least on the platforms DMD supports).
Mar 30 2007
prev sibling parent reply Dan <murpsoft hotmail.com> writes:
 int getRandomNumber()
 {
     return 4; // chosen by fair dice roll.
               // guaranteed to be random.
 }
^^^ Priceless. : D That reminds of the ol' "find x" "here it is ----> x" picture going around.
Mar 30 2007
next sibling parent Pragma <ericanderton yahoo.removeme.com> writes:
Dan wrote:
 int getRandomNumber()
 {
     return 4; // chosen by fair dice roll.
               // guaranteed to be random.
 }
^^^ Priceless. : D That reminds of the ol' "find x" "here it is ----> x" picture going around.
Taken from XKCD: http://xkcd.com/c221.html The author is one part geek, one part comedian and one part hopeless romantic. The comic archive is *packed* with humor like this. -- - EricAnderton at yahoo
Mar 30 2007
prev sibling parent Don Clugston <dac nospam.com.au> writes:
Dan wrote:
 int getRandomNumber()
 {
     return 4; // chosen by fair dice roll.
               // guaranteed to be random.
 }
^^^ Priceless. : D
The original IBM random number generator was a bit like that. When a bug report was made, the response was: "We guarantee that each number is random individually, but we don't guarantee that more than one of them is random." - Numerical Recipes, chapter 7.
Apr 02 2007