Messages

16

System / segfault/memory curruption risk in SFML Thread class.

« on: November 25, 2011, 10:57:01 am »

Ok, sorry. I did crawl the code and it reveal that the Wait function wasn't working properly on my system. The Thread object could be deleted while the thread was running.

This is definitively a problem of mine. Sorry for the inconvenience, you can close this topic if you wish.

17

System / segfault/memory curruption risk in SFML Thread class.

« on: November 24, 2011, 09:58:58 pm »

If you spawn a thread, launch it, and immediately delete it, you get intermitent segfault (or worse, memory corruption).

I triggered that with simple code as follow :

Code: [Select]

Thread* t = new Thread(someFunction);
t->Launch();
delete t;

I'm not sure how this is fixable (or not). Maybe by copying the Thread object in the launch function and using that copy ?

18

Feature requests / SFML should use only types of defined size

« on: November 21, 2011, 11:28:19 am »

Great !

19

SFML projects / SFGUI

« on: November 10, 2011, 04:11:13 pm »

You'll find classes Thread, Mutex and Lock in the module system.

20

Feature requests / SFML should use only types of defined size

« on: November 10, 2011, 01:11:26 pm »

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/

21

Feature requests / SFML should use only types of defined size

« on: November 10, 2011, 11:42:33 am »

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.

22

Feature requests / SFML should use only types of defined size

« on: November 10, 2011, 09:43:45 am »

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.

23

Feature requests / SFML should use only types of defined size

« on: November 09, 2011, 06:14:25 pm »

Fixed size type has a size you can rely on. That is just the point of fixed sized type.

So you now are sure that the type you use at one side will always match the type you'll find to the other side.

Note that C object files doesn't bring with them information about type, so you end up with really nasty bugs when the type size mismatch.

Currently, this is a problem for long, mostly, because the long size is really inconsistent across plateforms.

What is the problem of non fixed size type ? Well, they have non fixed size. You can rely on this size. You know thing will not explode in an unexpected way on some plateform.

Many header of SFML are already using types like sf::Uint32 and similars ones. So I guess you already see a point to have known sized types.

This isn't blablabla, all recent languages have known sized types. Call me crazy, but you already did that in several parts of SFML. And I can't see any good reason for most use of long in the public API.

Like, for exemple, the style of a RenderWindow. This can be 64 bits long, but still, those extra 32bits are non exploitables (I would make SFML incompatible for 32 bits or require the use of fixed size type for 32 bits SFML). The same goes for window. The same goes for Text.

The same goes for any usage of non known sized type in the API actually.

The int everywhere as not a problem as long as SFML isn't ported on other plateforms. I did work on plateform where int wasn't 32bits and I can assure you that this can become quite a mess quickly. You don't immagine how much code rely on the fact that int is 32bits (but actually isn't always).

Just try to link SFML with another language. Every missized variable will compile just fine. And then only god knows what happen at runtime because the calling convention is screwed. You don't get any error. You simply segfault or get plein wrong results, sometime you even get correct results that turns wrong with some criteria on input values. And you have actually no clue if your code will work on any plateforms because you cannot be sure of the size of thoses types. Long is especially inconsistent (it isn't 64bits on all plateforms).

24

Feature requests / SFML should use only types of defined size

« on: November 09, 2011, 01:54:35 pm »

Well so just don't do SFML at all. SDL works fine.

Binding are possible (for sure, I'm working on that currently) but the typesystem quirks from C leaks into other language by consequence.

Just like you don't have to do OOP and all that stuff. SDL is working just fine without it.

25

Feature requests / SFML should use only types of defined size

« on: November 08, 2011, 08:34:22 pm »

http://schneide.wordpress.com/2011/11/08/inconsistent-usage-of-type-definitions-kills-portability-in-cc/

26

Network / Packet has dangerous behaviour with char* and operator >&

« on: October 31, 2011, 12:16:31 pm »

Well I wanted to do it, but it seems that somebody did it for me.

27

Network / Packet has dangerous behaviour with char* and operator >&

« on: October 30, 2011, 06:15:04 pm »

Code: [Select]

Packet& Packet::operator >>(char* data)
{
    // First extract string length
    Uint32 length = 0;
    *this >> length;

    if ((length > 0) && CheckSize(length))
    {
        // Then extract characters
        std::memcpy(data, GetData() + myReadPos, length);
        data[length] = '\0';

        // Update reading position
        myReadPos += length;
    }

    return *this;
}

This piece of code is made for buffer overflow. This function should be aware of teh size pointed by data.

As C++ as a string class, this operator overloading should just be removed in my oppinion. To ensure the possibility of binding throw C, a function can be added like read(char* data, size_t maxCharRead).

28

Feature requests / SFML should use only types of defined size

« on: October 30, 2011, 12:54:05 pm »

Ok, so I'll stop trying

29

Feature requests / SFML should use only types of defined size

« on: October 29, 2011, 07:36:59 pm »

You'll get linker errors if you mix 32 and 64 bits libraries anyway, using fixed-size types won't make it magically work.
If you don't mix architectures, I don't see what kind of problems you would get.

That is not what I meant. Just consider the cas ewhere a size_t is passed to a function using int paramater. This will work on 32 bits. This will fail badly on 64 bits. And, if thoses are different mabguage, fail at link time with explainations in klingon.

Consider java port, this is, well, a port, and not using SFML code.

Actually, yes using primitive types in C/C++ ends up being a mess when you link to other languages. I will not say that they shouldn't be used at all, but probably not exposed.

30

Network / IPv6 support

« on: October 29, 2011, 06:11:29 pm »

I don't think it's really necessary right now, IPv6 is still not used a lot. I can probably wait a few years before thinking about adding this task.

Well, I'll wake up this thread. Now that the worldwide IPv4 address pool is exhausted and that some counties switched to IPv6 as a main protocol (china for exemple) It is time for IPv6 in SFML.

Why not take advantage of SFML2 to include this feature ?