BScreen* has corrupt data

[johndrinkwater]

Picked this error up from GLQuake, it uses a BScreen*, but doesnt call a constructor before using it. Rather cryptic description, but attached is a test in case I dont make myself clear

obj->Frame() returns a corrupted BRect, so Quake tries to init a GL screen of -2147483647 x 1!

Related: width + height also are corrupt; they arent 0 like the application assumes (norty), See URL for code

Filed incorrectly under interface kit; really not sure where to put it, sorry. It's more a "class members have trashed (non blank) data if they arent set."

[johndrinkwater]

src + bin of a little BScreen test

[axeld]

When you access a non initialized object, how do you think this should work? This is just a bug in the application, and must be fixed there.

[johndrinkwater]

Why? Because it works this way on BeOS. The test app and GLQuake show it. How can the developer access SetMode() if the object isnt initialized?

I understand its poor coding; I have a patch to fix this problem, but that doesnt fix the fact that the BeOS binary wont work.

[korli]

John, if you don't init correctly your class members, the behaviour is undefined. Seems you're out of luck on Haiku ...

[axeld]

Well, I think we just can live with that - and will so in similar situations (especially when the source is available and all). But don't get me wrong: thanks for your effort, it's very much appreciated!

[mmlr]

I suppose this works on BeOS since it only has one static BScreen backend object whereas the Haiku implementation has a BObjectList of at least two PrivateScreens. In Haiku the PrivateScreen has to be referenced to be useable as done in the constructor, in BeOS the members are probably just statics. It still is just a bug to use an unitialized pointer. Interesting that it doesn't segfault.