I would get rid of "register" keyword. it serves only a little purpose, which is the compiler should complain if the address of the variable is taken, e.g. &the_thread should cause a compiler error. g++ ignores this.
FWIW in these cases the "restrict" keyword actually might make sense and be useful. the restrict condition should be satisfied due to dispatch disabled. -Gedare On Fri, Jan 17, 2014 at 12:22 PM, Jennifer Averett <jennifer.aver...@oarcorp.com> wrote: > I'll remove the include files that are not used. > > For the "register" modifier I was following the convention used in > other posix files: > pthreaddetach.c: register Thread_Control *the_thread; > pthreadgetaffinitynp.c: register Thread_Control *the_thread; > pthreadgetattrnp.c: register Thread_Control *the_thread; > pthreadgetschedparam.c: register Thread_Control *the_thread; > pthreadjoin.c: register Thread_Control *the_thread; > pthreadsetaffinitynp.c: register Thread_Control *the_thread; > pthreadsetschedparam.c: register Thread_Control *the_thread; > > We can change the convention, but I think it should be consistent. > > Jennifer > >> -----Original Message----- >> From: ged...@gwmail.gwu.edu [mailto:ged...@gwmail.gwu.edu] On >> Behalf Of Gedare Bloom >> Sent: Friday, January 17, 2014 11:06 AM >> To: Jennifer Averett >> Cc: rtems-devel@rtems.org >> Subject: Re: Patch to implement pthread_getattr_np >> >> I have a couple cosmetic complaints: >> >> why include cpuset.h? similarly is priorityimpl.h needed for something? >> >> i don't think it is necessarily a good idea to declare variables with the >> "register" modifier. >> >> As a general comment about our score thread implementation, i do not like >> the mismatch between the_thread=Thread_Get() and >> Object_Put(the_thread); this is not relevant to your patch, just >> commenting.. >> >> -Gedare >> >> On Fri, Jan 17, 2014 at 11:17 AM, Jennifer Averett >> <jennifer.aver...@oarcorp.com> wrote: >> > The attached patch implements pthread_getattr_np(). >> > >> > >> > Jennifer Averett >> > On-Line Applications Research >> > _______________________________________________ >> > rtems-devel mailing list >> > rtems-devel@rtems.org >> > http://www.rtems.org/mailman/listinfo/rtems-devel >> > _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
