StormC 64-bit arithmetic bug?

[Minuous]

I seem to have found a bug in StormC? Try the following in "StormC 3" mode:

void main(void)
{   long long number;

    number = 10;
    number *= 2;
    printf("%Ld!\n", number);
}

The answer should be 20 but is not...!

On a related subject, does anyone have documentation for the undocumented AG2Index and GenDictionaries tools supplied with StormC 4?

[Cymric]

Not sure whether this answer is of use, but I'll write it anyway. (I like to see myself write :-D.) According to the manpages of sprintf() on my Linux box, the 'L' modifier is only used in conjunction with long double. If you want to use the correct modifier for ints, one uses 'll' (ell-ell). And forgive me if I'm wrong here (I never use long longs), but shouldn't the declaration read 'long long int number'? Or does StormC understand that it is an int without explicitly writing it down?

[Karlos]

StormC 3 has a multitude of bugs and quirks, especially in C++ mode.

If you dump the number as a pair of unsigned longs (use a union of an array of 2 unsigned longs and 1 unsigned long long), you will see the arithmetic is correct, but in fact the formatted output is at fault.

Add this to improperly constructed arrays of polymoprphic objects, broken function template instansiation, ability to take the address of a nonstatic member function (without an object), non threadsafe exception handling... the list goes on :-/

[Minuous]

I'm actually using StormC 4.0, but with the StormC 3 compiler engine. In ANSI C mode, not C++, by the way.

And %Ld is correct for 64-bit signed decimals.

[Karlos]

I wasn't implying that you were using C++, just that overall the SC3 compiler model is seiously bug ridden.

[PiR]

ability to take the address of a nonstatic member function (without an object)

Well, without arguing that StormC is overloaded with bugs, which is very unfortunate, as it has really seriusly designed IDE and a lot of effort was obiously put in production of it, I doubt if this one is really a bug.

The method if really a function with the first argument 'hidden', which name is hardcoded to 'this'. For simple storing of address of that function no existing object is needed.

To be honest, if such constructs were forbidden by the compiler, I belive THAT would be a bug. The other thing is if such constructs are usefull for anything, while the same thing can be probabily designed with virtual methods.

My 2 grosz'es (1/100 of the national currency in Poland)