BuiltInFontData not const

[hendu]

Checking what's taking up space in my app's .data and relro data sections, I noticed that irr::gui::BuiltInFontData is in data.

That means that it's writable, not marked const. Any reason why?

[CuteAlien]

Probably no good reason, but it's used in createMemoryReadFile... which again takes not a const-pointer. As it's a read file I guess that one could also be const - but have to test that first.

[hendu]

Patch posted for this and other things:
https://sourceforge.net/tracker/?func=d ... tid=540678

And yes, I also think that the ReadFile should take const pointers. But that's a bigger change, I'll leave it to you.

[CuteAlien]

I don't think we should cast the const away there, this should be fixed in the readfile instead. While the rest of the patch looks fine on first view - so I could apply it partly (but can't close it then - more one one change in a patch is always bad because that happens nearly every time, better splitting patches up into several reports - for simple stuff like const-fixes you can just post it here that can be applied easy as long as it doesn't change interfaces).

[hendu]

Blame SVN for that, those were nicely separated in my git branch. For things that change the same file, SVN is really horrible.

[hybrid]

Why do you change const char* x to const char x[]? Looks counter-intuitive to me.

[hendu]

Because the pointer is not const in a "const char *foo". The pointer is writable, which prevents some compiler optimizations, and puts it in the .data segment.

As for "const char * const foo" vs "const char foo[]", the latter is marginally better because there are no pointers involved at all, not even const ones. This can affect startup overhead, due to the pointer requiring a relocation if the compiler can't optimize it away. The array will always be able to be in the un-relocated read-only data segment [1].


[1] fPIE and fPIC excepted.