Branko Cibej wrote:
>> 1) All exported functions have their calling convention defined in
>> the prototype. My project settings might not match the setting the
>> library was built against for this.
>>
> That, I'm afraid, is a valid point. I'm still looking for the bright
> guy at MS who decided that mixinc calling conventions is a good
> thing. I've even got several different kinds of pincers warming in
> the coals.
>
Heh. Maybe you can get him to settle on one bawling convention...
> ...
>> 3) All exported functions should use plain data types or struct
>> pointers. If a typedef or #define to wrap the plain types is
>> necessary, it sure should be clearly unique to the library so there
>> is no chance of a name collision.
>>
> You're mixing two things here: one is an ABI issue (like 2), the other
> is a naming convention issue. We don't have naming convention
> problems.
What is the ABI issue? I can't see a problem with using typedefs.
>> 5) Due to the madness of windows memory management in a DLL system,
>> I should never directly free something the dll allocated or vice
>> versa, except via calls into the library for this express purpose.
>>
> Yet another ABI issue, although in this case, the shot is at
> Microsoft, not at everybody else. Berkeley DB is the only library
> that has explicit problems with this, but our other libraries are
> also vulnerable. I think we'll simply have to provide two versions of
> the libraries in the development package, and they'll have to have
> different names.
If you are writing new code, it's much easier to follow the guideline and
just not call malloc() and free() for a given block of memory across shared
libaries.
I don't think microsoft has made any mistakes here. Unlike unix, windows has
no special relationship with C. malloc and free are not syscalls, so you
shouldn't assume that every library can call them directly.
>> 6) Pulling in loads of system headers due to including the library
>> headers can be annoying, but sometimes unavoidable. A lot of
>> standard library functions are unsafe (and banned in some shops) and
>> people tend to use whats in the address space accidentally
>> (sprintf/strcat etc come to mind). Pulling in windows.h is fat and
>> slow and should be avoided at all costs.
>
> We don't (or at least, we shouldn't) use the unsafe functions; I think
> we're pretty disciplined in that respect. OTOH, what's "banned in some
> shops" doesn't concern me at all -- we only export the SVN API,
> nothing else, and we use the safe APR versions of the string
> functions everywhere.
>
> We do pull in windows.h (as part of APR if nothing else), but it's
> pared down to a minimum (by defining WIN32_LEAN_AND_MEAN). I don't
> think we include windows.h from any of our public headers directly.
APR really shouldn't be pulling in windows.h in its public headers either,
although I see that it does do this in apr.h ...
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 24 23:07:15 2003