Russell Yanofsky wrote:
>Branko Cibej wrote:
>
>
>>...
>>
>>
>>>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.
>
I read (3) as forbidding passing struct params by value. That's the 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.
>>
>>
>
>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.
>
Well, we're not writing new code, we're using existing code (Berkeley DB
in this case).
>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.
>
Malloc and free aren't syscalls, they're C runtime functions even on
Unix. They're usually implemented in terms of brk, sbrk, mmap of valloc
(which _are_ syscalls), but that doesn't change things. Changing the
heap layout *and* the library name was a stupidity, plaing and simple.
If they'd kept the same library name for the basic C runtime,
dynamically linked prigrams would just use the right malloc and free
everywhere. Statically linked programs don't have a problem anyway.
>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 ...
>
>
I'm afraid it has to. Otherwise the error handling stuff just wouldn't work.
--
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 Mon Mar 24 23:44:37 2003