PAK-9
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.
hungryskull
29th May 2004 01:46 UTC
Never seen that before. I agree with your assumption that it is a reserved word
Shock Value
29th May 2004 02:21 UTC
It seems to be stuck at 192 for me. Odd...
[Ishan]
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:
piR
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 ...:)
Warrior of the Light
1st June 2004 12:28 UTC
Strange that it isn't mentioned anywhere :igor:
UnConeD
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 ;)
PAK-9
2nd June 2004 06:36 UTC
intriguing, another little <cough> 'feature' of avs discovered.
Tuggummi
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]