Archive: ch ch ch


28th May 2004 23:32 UTC

ch ch ch
I dont know if this has been discussed before but has anyone else noticed that naming a variable 'ch' results in undefined behaviour. It's happened to me more than once when I've had a variable named 'ch' and spend frustrating minutes trying to work out why my code wont work, and changed it to 'ch1' only to have it spring into life.

I've only really noticed it in ssc's (prolly since that what i use most). I can only assume its a reserved word.


29th May 2004 01:46 UTC

Never seen that before. I agree with your assumption that it is a reserved word


29th May 2004 02:21 UTC

It seems to be stuck at 192 for me. Odd...


29th May 2004 10:21 UTC

yup. thats true, it happened to me too, when i did it my scope did'nt show anything at all.:confused:


29th May 2004 22:18 UTC

I try 'ch' and got also 192. Then, I noticed that 192 equals 16*12, and 12 is written c in hexadecimal notation. So, I tried with fh and I got ... 240 !
Conclusion : The suffix 'h' can be added to an hexadecimal string (using 0 to 9 and a to f 'number') to get a value equals to this hexadecimal number multiply by 16. Just as if this 'h' replaces a final zero.

In other words :
0h = 0x00 = 0,
1h = 0x10 = 16,
2h = 0x20 = 32,
and so on.

But also :
ch = 0xc0 = 192
f1h = 0xf10 = 3856

Very strange notation, in fact.

However, now, all readers of this thread know that they should avoid variable names using the characters '0' to '9' and 'a' to 'b' and ending by 'h' as it is a number ! ;)

BTW, I also tried to written numbers like 10d or 128d, and it works (respectively 10 and 128). Not very useful nor dangerous, but just amusing ...:)


1st June 2004 12:28 UTC

Strange that it isn't mentioned anywhere :igor:


1st June 2004 13:28 UTC

From nseel-eval.c:


int nseel_translate(compileContext *ctx, int type)
{
int v;
int n;
*ctx->yytext = 0;
nseel_gettoken(ctx,ctx->yytext, sizeof(ctx->yytext));

switch (type)
{
case INTCONST: return nseel_createCompiledValue(ctx,(double)atoi(ctx->yytext), NULL);
case DBLCONST: return nseel_createCompiledValue(ctx,(double)atof(ctx->yytext), NULL);
case HEXCONST:
v=0;
n=0;
while (1)
{
int a=ctx->yytext[n++];
if (a >= '0' && a <= '9') v+=a-'0';
else if (a >= 'A' && a <= 'F') v+=10+a-'A';
else if (a >= 'a' && a <= 'f') v+=10+a-'a';
else break;
v<<=4;

}
return nseel_createCompiledValue(ctx,(double)v, NULL);
}
return 0;
}


Obviously it's meant to support the 'xxxxh' notation for hexadecimal, but the code is buggy. When parsing a number, the 'else break' clause only hits on the 'h' character. So after the final digit, an extra bitshift is performed.

Bug ;)

2nd June 2004 06:36 UTC

intriguing, another little <cough> 'feature' of avs discovered.


2nd June 2004 07:05 UTC

Yup avs has a lot of 'features' [offtopic] like the one in superscope that it doesn't always draw on the edges of the screen. Try x=i*2-1 or y=i*2-1 and watch closely, it's really starting to piss me off along with the linesize limit :([/offtopic]