<br><br><div class="gmail_quote">On Fri, Aug 10, 2012 at 4:00 PM, Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 08/10/2012 02:36 PM, Steven Grunza wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-----Original Message-----<br>
From: <a href="mailto:rtems-devel-bounces@rtems.org" target="_blank">rtems-devel-bounces@rtems.org</a> [mailto:<a href="mailto:rtems-devel-" target="_blank">rtems-devel-</a><br>
<a href="mailto:bounces@rtems.org" target="_blank">bounces@rtems.org</a>] On Behalf Of Joel Sherrill<br>
Sent: Friday, August 10, 2012 3:27 PM<br>
To: <a href="mailto:rtems-devel@rtems.org" target="_blank">rtems-devel@rtems.org</a><br>
Subject: Named fields in Structure Initialization<br>
<br>
Hi<br>
<br>
I was looking at the definition of the default pthread_attr_t in<br>
cpukit/posix/src/pthread.c. What's the consensus on explicitly<br>
naming fields as opposed to using order to resolve things.<br>
<br>
In the filesystem code, I think it is all named now. I was thinking<br>
of changing this over to something like this:<br>
<br>
const pthread_attr_t _POSIX_Threads_Default_<u></u>attributes = {<br>
<br>
    .is_initialized = true,                       /* is_initialized<br>
*/<br>
    .stackaddr = NULL,                            /* stackaddr */<br>
    .stacksize = 0,                               /* stacksize --<br>
will be<br>
adjusted to minimum */<br>
    .contentionscope = PTHREAD_SCOPE_PROCESS,     /* contentionscope<br>
*/<br>
    .inheritsched = PTHREAD_INHERIT_SCHED,        /* inheritsched */<br>
    .schedpolicy = SCHED_FIFO,                    /* schedpolicy */<br>
    .schedparam = {                               /* schedparam */<br>
      .sched_priority = 2,                        /* sched_priority<br>
*/<br>
      #if defined(_POSIX_SPORADIC_<u></u>SERVER) || \<br>
          defined(_POSIX_THREAD_<u></u>SPORADIC_SERVER)<br>
        .sched_ss_low_priority = 0,               /*<br>
sched_ss_low_priority */<br>
        .sched_ss_repl_period = { 0L, 0 },        /*<br>
sched_ss_repl_period */<br>
        .sched_ss_init_budget = { 0L, 0 }         /*<br>
sched_ss_init_budget */<br>
      #endif<br>
    },<br>
<br>
    #if defined(_POSIX_THREAD_CPUTIME)<br>
      .cputime_clock_allowed = 1,                 /*<br>
cputime_clock_allowed */<br>
    #endif<br>
<br>
    .detachstate = PTHREAD_CREATE_JOINABLE,       /* detachstate */<br>
<br>
};<br>
<br>
--<br>
Joel Sherrill, Ph.D.             Director of Research&<br>
</blockquote>
Wow, just goes to prove there's always something new to learn.  I was<br>
unaware of this ability in C to explicitly name fields like this.<br>
</blockquote></div></div>
:) I must admit to learning this from the RTEMS Community also. :)<div class="im"><br></div></blockquote><div>These are called "designated initializers" c.f. <a href="http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html">http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html</a><br>
<br>They don't work for headers that are included from C++ code; i.e. C++ does not compile them properly. That is one concern I know about. But for a plain C file they should be OK to use.<br><br>-Gedare<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It seems to me that using explicit naming would decrease problems caused<br>
by adding a new field to the structure but neglecting to update the<br>
initialization.  I don't see a downside to this change, other than the<br>
effort required to make the change.<br>
<br>
</blockquote>
<br></div>
It is trading one risk for another. Without explicitly naming<br>
the fields, there is a risk that you didn't initialize things<br>
in the right order and "it just works". Or that a new field<br>
got added and it just continues to compile.<br>
<br>
This way, it will compile unless a field changes names but<br>
there is a risk that when new fields are added to the structure,<br>
it will not be automatically be caught.<br>
<br>
I like it now that some of the code has started doing it.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br></font></span><div class="im HOEnZb">
Joel Sherrill, Ph.D.             Director of Research&   Development<br>
joel.sherrill@OARcorp.com        On-Line Applications Research<br>
Ask me about RTEMS: a free RTOS  Huntsville AL 35805<br>
    Support Available             <a href="tel:%28256%29%20722-9985" value="+12567229985" target="_blank">(256) 722-9985</a><br>
<br>
<br></div><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
rtems-devel mailing list<br>
<a href="mailto:rtems-devel@rtems.org" target="_blank">rtems-devel@rtems.org</a><br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/<u></u>listinfo/rtems-devel</a><br>
</div></div></blockquote></div><br>