seanc@dimensionalrift.com wrote:
>Just a minor interjection: as a user of third party libraries, I expect
>the following things to be true of any library, for it to be considered
>'nice and well behaved':
>
>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.
>2) All exported data structures are wrapped with #pragma pack's, for the
>same reason.
>
Sorry, but that's nonsense. The system ABI defines the layout of
structs. Compilers that don't conform to the ABI don't interest me at all.
>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.
>4) Exported data structures should never contain an enum type. An int or
>similar type is far superior.
>
Again, another ABI issue.
>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.
>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.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 23 21:32:00 2003