Date: Thu, 31 Jan 2008 11:52:35 -0800 From: Jin Guojun <jin@george.lbl.gov> To: threads@freebsd.org Subject: improper order to check NULL pointer in libthr Message-ID: <47A22703.7030903@george.lbl.gov>
next in thread | raw e-mail | index | archive | help
Most pthread_mutex functions and some pthread_ functions in linbthr do
not check NULL
pointer at the function entry, but they dereference the pointer to see
if its content is NULL.
The NULL pointer is ASSERTed at last stage (in xxxxx_common routines)
somehow, which is
meaningless.
So, what is the correct design pattern? -- (should be like libpthread,
which looks correct)
Return EFAULT / EINVAL at the entry point as +++ below if the pointer is
NULL?
or
ASSERT at the entry point if pointer or its content is NULL?
Please CC me since I am not on thread list.
Thanks,
-Jin
int
_pthread_mutex_trylock(pthread_mutex_t *mutex)
{
+ if (!mutex)
+ return EFAULT;
+
struct pthread *curthread = _get_curthread();
int ret = 0;
/*
* If the mutex is statically initialized, perform the dynamic
* initialization marking the mutex private (delete safe):
*/
if ((*mutex != NULL) ||
((ret = init_static_private(curthread, mutex)) == 0))
ret = mutex_trylock_common(curthread, mutex);
return (ret);
}
static int
mutex_lock_common(struct pthread *curthread, pthread_mutex_t *m,
const struct timespec * abstime)
{
struct timespec ts, ts2;
long cycle;
int ret = 0;
THR_ASSERT((m != NULL) && (*m != NULL),
"Uninitialized mutex in mutex_lock_common");
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47A22703.7030903>