Ok second blog entry of the day, mainly because I don’t want to go sleep and I have nothing to do which doesn’t involve be completely awake.
News for who care: I joined pam herd to help az with pam modules and configuration files handling. That’s related to the work I’m doing to have pam working out of the box on Gentoo/FreeBSD, which requires to change a few things here and there.
Also, if you haven’t read the comment to my previous blog entry, you can find on Planet KDE, a rule to filter out the german spam in Dirk Mueller’s entry. Thanks Dirk for that 🙂
Now the topic of the entry… after release of gcc4, I started caring of portability fixes to have GCC4 working for some video stuff which broke. That’s common in video and sound software because to achieve performance, it’s not uncommon for programmers to use dirt hacks and trickies to carry out some processing. That, unfortunately, often makes programmers “assume” that their system is the same of every other. They can’t be more wrong.
Let’s see the most common errors which throws up when a new gcc is released and it gets more strict.
The first one is the declaration of static vars. Many developers just defines variables in .h and use them in just a .c source file as statics.. that’s not good because the .h defaults to extern. Another problem is when a variable is declared static and, with the same name, is declared extern elsewhere (see transcode problems)… that’s bad.
Other problems can be with some strange pointer arithmetics, which gets fooled up (xine-lib had this problem and required a couple of patches to get rid of it in the right way, as the more logical way from a non-expert pov is wrong by practical check). You should nevel try to write something in a way another developer can’t read, because probably neither newer compilers can read it in future. An assignment more shouldn’t be so much delay in the code.
Finally, there are my preferred errors: pointer foolups. GCC is getting more and more strict in latest version about it, and that’s good for everyone in a 64-bit architecture. Trying to summarize, many people just think that pointers are always 32-bit and they are always of the same size of int integers. Nothing can be more different.
On 64-bit systems, the pointers are sized… 64-bit, but int integers are just sized 32-bit as usual. Instead long integers are sized 64-bit, so long is the right type which is of the same size of pointers in current systems and compilers.
There are many ways to be sure that you don’t use the wrong type for those things.. for example you should never ever try to shade an int into a void* pointer… you should neither try to store a pointer into an int, if you really need to store a pointer use ptrdiff_t which is guarranteed to be of the same size of pointers (if using gcc or gcc-compatible compiler) or at least a long integer.
So in general, the new warnings in gcc 3.4, which turned into errors in 4, are good things ™ because they allows 64-bit systems’ users to be sure that the program they are running doesn’t try to do foolish things which causes segfaults and so on…
Now… you should think that something like that came up only on some strange multimedia stuff or in software which is poorly developed or not widely used.. that’s also wrong.
Following Mark’s entry I tried to build mozilla-firefox with gcc4, because it’s way and way faster.. unfortunately it fails also if gcc4 patch is applied, because firefox’s code suffer from many of the coding error I’ve just explained: integers shaded into void* (which breaks when you de-shade them), pointers stored as integers, and so on.
I don’t know how could Mozilla work fine on 64-bit systems with such problems, as they tend to corrupt the memory and makes the program segfault. But it’s true I usually use Konqueror and not Firefox so it can probably segfault often. Also many users just use 32-bit firefox to have Macromedia Flash support so they can’t see the problems.
Well… I think I’ll try to prepare some experimental ebuilds which uses kde split ebuilds and svn modules to try to build them with gcc4 and fix the problems where they aren’t fixed in svn (sheees.. I was writing cvs… I still haven’t made up my mind about kde’s svn move!).
Hey, you already have kde svn split ebuilds. I’m using them right now and they works.Give thanks to Mario 😉http://csua.berkeley.edu/~m…http://forums.gentoo.org/vi…
Just to make things more confusing – on some 64 bit platforms, ints are 64 bit and so are pointers, so the int -> void * conversion works just as well as it does in 32 bit platforms. Then you get something like AMD64/EM64T when they decide ints can stay 32 bit (despite the conventional wisdom that int is the platform native integer size – I suppose on those processors it’s a toss-up between 32 and 64 being ‘native’ as it can handle both with equal facility) and all hell breaks loose.Does make people tidy up their sloppy code though, and that can’t be a bad thing.
Replying to comment #1:Thanks, that really good to know, I’ll give them a try (probaly I need to change them a bit to use the stable branch instead of HEAD if they are similar to the old cvs ebuilds).Replyin to comment #2:I’ve just re-checked using SourceForge’s compile farm, and not only x86_64, but also alpha (which is not exactly something new), has 32-bit integers and 64-bit long and pointers. I’m not aware of other 64-bit archs, a part from ppc64 (which I can’t test) in which ints are 64-bit.If you can point me to an arch in which sizeof(int) == 8, I’ll try to find an access to one of these because I’m very interested in the way different platforms achieve the same result.