This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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: threads.h implementation issues


On Thu, Oct 30, 2014 at 05:40:27PM +0100, Juan Manuel Torres Palma wrote:
> > Including it from where? It can't be included from threads.h. But it
> > shouldn't need to be. Mapping of errors needs to take place internally
> > in the library, not as part of the calling application.
> 
> I have 2 different files. The header (threads.h) and an implementation
> file (threads.c). On threads.c I have included errno.h to be able to
> read the errors from pthread_* function calls and map them to their
> corresponding error value on the threads.h specification. The function
> is defined as:
> 
> static inline int __thrd_err_val(int);
> 
> I thought that it's complex enough to not be defined as a macro, so I
> created an inline static function, and it's a static one so I don't
> think it will create any ABI or namespace issues. Is that wrong?

If there's any reason that applications using the C11 threads API need
this function, that's a problem you need to fix. The public functions
should be returing the right error codes, not requiring code inlined
in the caller to fix the return values up.

If applications don't need this function, it doesn't belong in (the
public) threads.h but possibly in an implementation-internal include
file that gets included in the implementation of the relevant
functions.

Hope this helps.

Rich


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