timer_create null check for 2nd arg (evp)

Kay McCormick kaym at modsystems.com
Fri Feb 9 22:17:24 UTC 2007


You're right on the second point, and in fact it appears to do that,
just too late in the routine to handle that initial case.  So, checking
for null appears to have the desired effect in that it's checking for
SIGEV_THREAD, and as you said, it should behave as if its SIGEV_SIGNAL,
which it would.  Alternately, for some perceived higher level of
correctness, the code defaulting evp to the address of a properly
initialized local could be moved to the beginning of the routine.

Either way, as long as it doesn't core, I am happy.

Kay

_____________________________________________
From: Mike Frysinger [mailto:vapier at gentoo.org] 
Sent: Friday, February 09, 2007 2:11 PM
To: uclibc at uclibc.org
Cc: Kay McCormick
Subject: Re: timer_create null check for 2nd arg (evp)

On Friday 09 February 2007, Kay McCormick wrote:
> In timer_create function in librt (librt/timer_create.c) the second
> argument should be checked for NULL.  I have third-party (commercial)
> code that calls timer_create with evp NULL.  I checked the specs
> available online and this is allowable.

true:
http://www.opengroup.org/onlinepubs/009695399/functions/timer_create.htm
l

> So where it says 
> if (__builtin_expect(evp->sigev_notify == SIGEV_THREAD, 1))
> near the top of the function and file and changed it to
> if (evp != NULL && __builtin_expect(evp->sigev_notify == SIGEV_THREAD,
> 1))

yes and no ... the proper thing would be to implement:
If the evp argument is NULL, the effect is as if the evp argument
pointed to a 
sigevent structure with the sigev_notify member having the value 
SIGEV_SIGNAL, the sigev_signo having a default signal number, and the 
sigev_value member having the value of the timer ID.
-mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/uclibc/attachments/20070209/5d61c094/attachment-0002.htm 


More information about the uClibc mailing list