Named fields in Structure Initialization

[Joel Sherrill]

On 08/10/2012 02:36 PM, Steven Grunza wrote:
>> -----Original Message-----
>> From: rtems-devel-bounces at rtems.org [mailto:rtems-devel-
>> bounces at rtems.org] On Behalf Of Joel Sherrill
>> Sent: Friday, August 10, 2012 3:27 PM
>> To: rtems-devel at rtems.org
>> Subject: Named fields in Structure Initialization
>>
>> Hi
>>
>> I was looking at the definition of the default pthread_attr_t in
>> cpukit/posix/src/pthread.c. What's the consensus on explicitly
>> naming fields as opposed to using order to resolve things.
>>
>> In the filesystem code, I think it is all named now. I was thinking
>> of changing this over to something like this:
>>
>> const pthread_attr_t _POSIX_Threads_Default_attributes = {
>>
>>     .is_initialized = true,                       /* is_initialized
>> */
>>     .stackaddr = NULL,                            /* stackaddr */
>>     .stacksize = 0,                               /* stacksize --
>> will be
>> adjusted to minimum */
>>     .contentionscope = PTHREAD_SCOPE_PROCESS,     /* contentionscope
>> */
>>     .inheritsched = PTHREAD_INHERIT_SCHED,        /* inheritsched */
>>     .schedpolicy = SCHED_FIFO,                    /* schedpolicy */
>>     .schedparam = {                               /* schedparam */
>>       .sched_priority = 2,                        /* sched_priority
>> */
>>       #if defined(_POSIX_SPORADIC_SERVER) || \
>>           defined(_POSIX_THREAD_SPORADIC_SERVER)
>>         .sched_ss_low_priority = 0,               /*
>> sched_ss_low_priority */
>>         .sched_ss_repl_period = { 0L, 0 },        /*
>> sched_ss_repl_period */
>>         .sched_ss_init_budget = { 0L, 0 }         /*
>> sched_ss_init_budget */
>>       #endif
>>     },
>>
>>     #if defined(_POSIX_THREAD_CPUTIME)
>>       .cputime_clock_allowed = 1,                 /*
>> cputime_clock_allowed */
>>     #endif
>>
>>     .detachstate = PTHREAD_CREATE_JOINABLE,       /* detachstate */
>>
>> };
>>
>> --
>> Joel Sherrill, Ph.D.             Director of Research&
> Wow, just goes to prove there's always something new to learn.  I was
> unaware of this ability in C to explicitly name fields like this.
:) I must admit to learning this from the RTEMS Community also. :)
> It seems to me that using explicit naming would decrease problems caused
> by adding a new field to the structure but neglecting to update the
> initialization.  I don't see a downside to this change, other than the
> effort required to make the change.
>

It is trading one risk for another. Without explicitly naming
the fields, there is a risk that you didn't initialize things
in the right order and "it just works". Or that a new field
got added and it just continues to compile.

This way, it will compile unless a field changes names but
there is a risk that when new fields are added to the structure,
it will not be automatically be caught.

I like it now that some of the code has started doing it.

-- 
Joel Sherrill, Ph.D.             Director of Research&   Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
     Support Available             (256) 722-9985