[cairo] Cairo ported to OS/2 - Suggestions

[Doodle]

Carl Worth wrote:
> 
> If we do have to clutter up the public header at all, (which I'd like
> to avoid, see below), I would at least like to hide this stuff from
> human eyes as much as possible. Perhaps something like:
> 
> 							CAIRO_DECL_ANTE
> cairo_t *						CAIRO_DECL_POST
> cairo_create (cairo_surface_t *target);

I'd be satisfied with this solution as well. :)

> 
>>#else
>>/* Use __cdecl for all other platforms */
>>#define CAIROCALL __cdecl
>>#endif
> 
> 
> Can you explain this __cdecl thing to me more clearly? I can't find
> any mention of this in the C99 specification, and if I try putting
> "__cdecl" in function prototypes my compiler reports a syntax error.

Hm, maybe I was too quick in assuming that it's an ANSI-C keyword.
Looking after it now, it seems to be a MS extension, which was adopted
also by OpenWatcom (what I use).

It seems to me that in ANSI C it's called _cdecl, so one less
underscore. See:
http://en.wikipedia.org/wiki/Calling_convention

However, you're right, it might be better to use the
compiler-default calling convention on other platforms:

#else
/* Use the default for all other platforms */
#define CAIROCALL
#endif


> 
> I'm definitely grumpy about adding non-C things to a public header
> file. I did concede to put the 'extern "C"' thing there, so my
> grumpiness can be overcome, but I'll need to see a compelling reason
> first.
> 
> You said this calling convention thing could be controlled by compiler
> switches. It seems like a compiler-specific feature to me. Is there a
> reason that compiler switches shouldn't be the thing used to control
> it?

Yes. Here is a thread about the very same problem but with Expat, and
on Windows with MSC:
http://mail.libexpat.org/pipermail/expat-bugs/2003-October/001696.html

Basically, the problem is that if the calling convention is not
declared, then the compiler will use the default one, which is based
on compiler switches. Once a binary (a DLL or .so in our case) is
compiled and linked with that convention, all the other applications
that want to use that library has to take care to use the very same
default calling convention.
Now, IMHO, one can't force bigger projects (not that I have any) to use
a given calling convention as default just because it uses a given
library. (Even more, there might be collisions if for example another
libary used by the application assumes a different calling convention
to be the default.)

For a real-live example:
I usually compile all the code with the -5r switch of the OpenWatcom
compiler. It instructs the compiler to use register based calling
convention by default, for speed.
If anybody wants to use that DLL from an application which was
compiled with the -5s switch (or without optimization turned on),
that application will crash when calls into my DLL.

> 
> I agree that the symbol visibility issue is important, but I
> definitely want to solve it in places other than cairo.h. The primary
> consumers of cairo.h are humans that don't need to be told about
> public vs. private symbols, (since the file only contains public
> symbols).

I fully agree with you that the public header file has to be kept
clean and easy to read.

However, once you'll agree to include that calling convention thing
(I hope you will :) ) in the header file as CAIRO_DECL_POST, an other
CAIRO_DECL_ANTE isn't that big of an ask, I think. ;)

> 
>>(And being a bit of selfish here: it would save me a lot of job,
>>because right now I have to tell the OpenWatcom linker which
>>functions to export, but if the code would have these defines,
>>the linker would know them automatically.)
> 
> 
> I think it would be quite easy to write a little script that extracts
> the public symbols out of the header files. There's a small list of
> public header files, all of which have a fairly rigid style, and there
> are no public symbols that are not in those files. So, if we could
> construct such a list of symbols in a file, and provide it with the
> cairo source distribution, would that be sufficient for you to do what
> you what you need to do?

Yes, that would also help me a lot, I wouldn't have to look through the
public header files myself for changes after every release.

(Still, I think that it would not be needed if that
__declspec(dllexport) could be put in front of the declarations, for
example the CAIRO_DECL_ANTE way you mentioned, or name it any other,
like CAIROEXPORT what Bill mentioned.)


Doodle