SFML should use only types of defined size

[Laurent]

That makes sense of course, but as you can see it is working.

So tell me which type does (not may) crash, on which platform with which language. If you can find one, I'll say ok.

Plus... SDL uses native types too (mostly int). Would you say that it doesn't work across platforms and languages, too?

[deadalnix]

Plus... SDL uses native types too (mostly int). Would you say that it doesn't work across platforms and languages, too?

No, that was my point. SDL works fine on many plateforms and many languages. But SFML is a clear improvement over SDL in its interface (better abstraction, handier to use, better performances). It doesn't means that if something works it cannot be improved. SDL works. SFML improved it anyway.

SFML binding works, they can be improved anyway.

The main problem, as long as we stay on plateforms with 32bits ints is long. Because if you use a constant size in a binding, it will compile without even a warning. The weird thing will happen at runtime and it will be plateform and compiler dependant.

It will works on plateforms where types are the same size. For different size types, you usually get completely inconsistent results.

Thoses thing will crash if any mistake is made in the conditionnal compilation part which define the type size. As thoses are not strictly defined.

Long size is very inconsistent, especially on 64bits systems. You'll find them in the inrterfaces of text, window and renderwindow. In both cases, the usage of long is not justoified anyway, because code cannot rely on the extra bits anyway or it will loose its portability. Producing code that will crash is some cases is pretty easy.

Code: [Select]

extern(C) sfWindow* sfWindow_Create(sfVideoMode mode, const char* title, uint style, const sfContextSettings* settings);

Voila !

Use that function in D and you'll be happy in x86 world and x86_64 on windows. You'll fail badly on linux or mac on x86_64. Note that you'll find that in the actual D binding of SFML (even if I did correct that during my update for D2/SFML2 of that binding, I'm still note sure my correction will work on any plateform). I'm pretty sure that similar errors exists in other binding. Because IT IS error prone and almost impossible to fully test for an individual as it require to run tests on many plateforms that may not be available.

Note that you'll not even get a warning as C object files do not contains any type information.

Int will cause the same problem for any attempt to port SFML on a non 32bits int plateform (I did experience that on PICs for exemple, but it is unlikely that SFML will be ported on thoses plateforms).

So I guess that we can assume that int are fixed size in our case. But We must note that some UNIX has 64bits int and SFML binding will probably never work on thoses plateforms (notably solaris on Sparc) if we assume that. It have the advantage to keep modification to the actual interface very limited.

wchar_t is also inconsistent. But I guess the whole wchar_t is the problem here, and that SFML can do very little about it.

[Laurent]

It doesn't means that if something works it cannot be improved. SDL works. SFML improved it anyway.

Since we're takling about crashes and undefined behaviours, not "features", improved == fixed. So if it works, there's nothing to fix and thus nothing to "improve".

Use that function in D and you'll be happy in x86 world and x86_64 on windows. You'll fail badly on linux or mac on x86_64. Note that you'll find that in the actual D binding of SFML (even if I did correct that during my update for D2/SFML2 of that binding, I'm still note sure my correction will work on any plateform).

So it really crashes on those platforms? Have you tried it? Is it sure?

So I guess that we can assume that int are fixed size in our case

In fact SFML assumes even more: char is 8 bits, short is 16 bits, and int is 32 bits. Because if one of them doesn't match its size, there is a "hole", ie. no other type that can match this particular size.

wchar_t is also inconsistent. But I guess the whole wchar_t is the problem here, and that SFML can do very little about it.

SFML tries to work around the inconsistencies of wchar_t, but yes this type is clearly flawed. But it is still the only type that can be used to write "unicode" literals, with the current C++ standard.

I have another question: since the bool type in C++ has no fixed size, how would you suggest that I implement boolean arguments? With a typedef to either Uint8 or Uint32? Then how do you solve the compiler warnings (implicit conversion from int to bool, ...)? Is it even in the standard that true converts to the integer 1 and nothing else?
In this case, I think you would clearly go against the language.

[deadalnix]

Use that function in D and you'll be happy in x86 world and x86_64 on windows. You'll fail badly on linux or mac on x86_64. Note that you'll find that in the actual D binding of SFML (even if I did correct that during my update for D2/SFML2 of that binding, I'm still note sure my correction will work on any plateform).

So it really crashes on those platforms? Have you tried it? Is it sure?

Yes, it does segfault. I guess it can just do random stuff if, by luck, it ends up that what C think is a pointer in parameters point to allocated memory.

Note that I fixed this crash with my work on DSFML, but we can't be sure that no other dirty things like this are not lurking around unless we use defined size types. I also think that it is sad that we have to fix thing like that every times in each binding as it can be solved once for all binding.

The bool case is interesting, and, to be honest, I don't have anything to suggest right now. I never experienced crashes with bool. It doesn't means that it will never crash on any plateform, because its size is undefined so can mismatch in a plateform dependant manner. I guess that as long as bool's size isn't more than 4 bytes, the allignement mecanism make it work. Well at least as long as we don't have func(bool, bool); or similar stuff in the function definition.

[Laurent]

So it would already be a good step forward to replace unsigned long with Uint32 (or unsigned int), right? The int type doesn't seem to be a problem. And for bool, since there's no clean solution, we should just hope that nothing bad happens.

There is another interesting problem: enums. Since the current standard doesn't allow to fix the size of an enum type, or even its type (is it signed or unsigned?), it can't be handled at all.

[deadalnix]

Yes using, (U)int32 instead of (unsigned) long would be nice.

For enum, this trick is available and could be used for public interface : http://mateusz.loskot.net/2009/05/24/size-of-enumeration-type-in-c/

[Nexus]

For enum, this trick is available and could be used for public interface : http://mateusz.loskot.net/2009/05/24/size-of-enumeration-type-in-c/

That complicates the usage of enums for effectively nothing.

Using a template everywhere you work with enumerations clearly goes away from the "simple" part of SFML. Generally, I think you overstate the problem of C++ types. It is certainly good to use fixed-size types where appropriate (e.g. for data that is serialized over network), but enforcing them at all costs doesn't look like a good idea.

[Laurent]

Yes using, (U)int32 instead of (unsigned) long would be nice.

Done.

[deadalnix]

Great !