On 10/25/07, Brett Nash <[EMAIL PROTECTED]> wrote:
> > >    struct _Ecore_Exe_Event_Del /** Process exit event */
> > >      {
> > > -   pid_t      pid; /**< The process ID of the process that exited */
> > > -   int        exit_code; /**< The exit code of the process */
> > > -   Ecore_Exe *exe; /**< The handle to the exited process, or NULL if not 
> > > found */
> > > -   int        exit_signal; /** < The signal that caused the process to 
> > > exit */
> > > -   char       exited    : 1; /** < set to 1 if the process exited of its 
> > > own accord */
> > > -   char       signalled : 1; /** < set to 1 id the process exited due to 
> > > uncaught signal */
> > > -   void      *ext_data; /**< Extension data - not used */
> > > -   siginfo_t  data; /**< Signal info */
> > > +   pid_t         pid; /**< The process ID of the process that exited */
> > > +   int           exit_code; /**< The exit code of the process */
> > > +   Ecore_Exe    *exe; /**< The handle to the exited process, or NULL if 
> > > not found */
> > > +   int           exit_signal; /** < The signal that caused the process 
> > > to exit */
> > > +   unsigned char exited    : 1; /** < set to 1 if the process exited of 
> > > its own accord */
> > > +   unsigned char signalled : 1; /** < set to 1 id the process exited due 
> > > to uncaught signal */
> > > +   void         *ext_data; /**< Extension data - not used */
> > > +   siginfo_t     data; /**< Signal info */
> > >      };
> >
> >
> > Shouldn't the bit-field members be placed at the end of the struct to be
> > useful ?
>
> Not sure exactly what you mean.. but there is no real reason to do
> anything except make sure the bitfields are adjacent in the structure.
>
> Otherwise it won't make any difference for size (the whole structure
> will be aligned, and since there is no small members to pack smaller
> than the natural machine alignment requirements no gain there).
>
> In any case, I'd rather just do the minimum change to remove the
> warning/unportable-declaration - which is add unsigned.

I think Vincent was wondering about my last commit to ETK, that I
tried to remove struct holes with information provided by pahole. In
your case it will contain these holes since structs will be aligned,
and things like [char][pointer] will be laid out effectively as
[long][pointer], same for int, long, ... in the place of [pointer].
   For better use of memory, you should try to pack-a-hole (pahole
tool is meant for that) and even better: keep memory that is used
together within the same cacheline (pahole helps here to).

All in all is usually better to keep these bitfield as unsigned char
(or int, or short,...) at the end of the struct.

-- 
Gustavo Sverzut Barbieri
--------------------------------------
Jabber: [EMAIL PROTECTED]
   MSN: [EMAIL PROTECTED]
  ICQ#: 17249123
 Skype: gsbarbieri
Mobile: +55 (81) 9927 0010

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to