This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: HAVE_DD_LOCK


The code that uses HAVE_DD_LOCK in libc/posix was taken from an existing code base (IIRC FreeBSD).

The code in libc/posix is offered optionally to platforms. The dir family routines code there can be ignored if the platform already supplies these functions (via the flag HAVE_OPENDIR). If not short-circuited via HAVE_OPENDIR, a port must implement sys/dirent.h or else the code will not build to begin with as you are probably already well-aware. A platform can also build these and also override them in either the libc/machine/xxx or libc/sys/xxxx directories.

So, if you choose to build the functions in libc/posix for your platform and you do not short-circuit them with HAVE_OPENDIR and do not override them yourself in your libc/sys directory and you support multi-threading, then you had either better implement the dd_lock field and set HAVE_DD_LOCK or else document that those functions are not thread-safe.

-- Jeff J.

Neal H. Walfield wrote:
I'm trying to understand the purpose of HAVE_DD_LOCK.  It seems to me
either the library is multi-threaded, in which case the locking
functionality described in libc/include/sys/lock.h must be provided
and not locking is a bug, or the library is single-threaded, in which
case, the locking primitives a no-ops.

Thanks,



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]