On 11/18/2012 05:28 PM, Jonathan Schleifer wrote:
Am 18.11.2012 um 14:58 schrieb Axel Dörfler:AFAIK all public API that we added follows the BeOS style, so this is already the status quo. Besides that, the coding style is not set in stone; it just makes sense to keep most of it as is, as changes would require lots of changes in the source code -- most of it should follow our current style by now :-)Ah, that's a relief to hear. Well, have you considered changing the coding style regarding constants? It seems we still have many uppercase constants that are not part of the Be API. It looks like we even have more uppercase than camel case (I might be wrong, though - this was just a quick look). Thus, changing from kCamelCase to uppercase might not be too much work and everything would be nice and consistent :).The same could be said about POSIX. They pollute the global namespace, and so do we. I think all we can do about this is exporting only weak symbols. Renaming would work, too, but I'm not sure this really is a necessity.
Yeah, the POSIX API is somewhat similar with respect to this problem. A difference is that the BeOS/Haiku API is significantly less known. Ported software (i.e. the majority of software available for Haiku) is likely using or at least aware of the POSIX API.
Linkage is only part of the problem, BTW. Ported software that needs to use Haiku specific API will likely include <OS.h> and thus pull in lots of API declarations that may clash with internal declarations of that port.
Weak symbols might horribly break things. Imagine some application has a function create_sem(), which is a wrapper around the POSIX call. Our POSIX call then use create_sem() again. If this is a weak symbol, we have a problem :).
Due to symbol preemption the same already happens without making the symbol weak. The solution -- which we haven't employed yet -- is to define two symbols: A regular (or even local) __create_sem() that is used by libroot code internally and a weak alias create_sem(). Since other libraries (e.g. libbe) would still use create_sem() your application can still break things by overriding create_sem(), but only *if* it actually exports the symbol, which it shouldn't (unless that's really the intention).
What would be more useful is maybe something like the two-level namespaces like in Mach-O?
Don't know about those. However, I'm pretty happy that our tool chain and runtime loader work very similar to those of Linux and the BSDs. This makes porting/interoperability a lot easier.
CU, Ingo
