GNOME Bugzilla – Bug 638683
Bad formatting of bitfield in struct variable.
Last modified: 2011-05-01 20:59:18 UTC
Code: static struct { /* Pin transmit current state */ unsigned pinTxEnabled:1; /* pin transmit feature enabled */ unsigned cdCodeEF:1; /* Clear/enter output code = oxe/oxf, ** else oxa/oxb */ Pin_pinDef_t pinDef; /* pin definition */ Pin_Feedback_t fb; /* user feedback */ } pts; Doxygen output: Variables</h2></td></tr> <tr><td class="memItemLeft" >struct {</td></tr> <tr><td class="memItemLeft" >   L   <a class="el" href="pin_transmit_8c.html#a95ac8660946b04e9948764d7f6bb532a">__pad0__</a>:/Artemis/code/hid-dev-embedded/Generic/keypad/pinTransmit.c" 2"L:/Artemis/code/hid-dev-embedded/Generic/keypad/pinTransmit.c" 2 unsigned pinTxEnabled:1</td></tr> <tr><td class="memItemLeft" >   unsigned   <a class="el" href="pin_transmit_8c.html#aa6383a5418920aa4a19933bf8659535c">cdCodeEF</a>:1</td></tr> <tr><td class="memItemLeft" >   Pin_pinDef_t   <a class="el" href="pin_transmit_8c.html#af08d3e65e89c4461a558b89b545e22e9">pinDef</a></td></tr> <tr><td class="memItemLeft" >   Pin_Feedback_t   <a class="el" href="pin_transmit_8c.html#a945369629abbc118c1f26c997fe677a7">fb</a></td></tr> <tr><td class="memItemLeft" valign="top">} </td><td class="memItemRight" valign="bottom"><a class="el" href="pin_transmit_8c.html#a50451486b81a8f1f7ecccdbf827a97f7">pts</a></td></tr> Visual text: Variables struct { L __pad0__:/Artemis/code/hid-dev-embedded/Generic/keypad/pinTransmit.c" 2"L:/Artemis/code/hid-dev-embedded/Generic/keypad/pinTransmit.c" 2 unsigned pinTxEnabled:1 unsigned cdCodeEF:1 Pin_pinDef_t pinDef Pin_Feedback_t fb } pts Notice the additional info shown for the first element. The actual item is outside the box in the HTML version. Also the variable name, pts, is shown in this copy and paste, it is invisible when the output is viewed with IE 6.0.
I have not been able to reproduce the problem with the code snippet you provided. Can you please attach a self-contained example (source+config file in a tar or zip) that allows me to reproduce the problem?
I cannot send the full source tree for proprietary reasons. The bug is not determined exclusively by the contents of the .c source file. When I add a second source file with a different name, but exact same contents, the original one manifests the error, while the copy doesn't (with both included in the run). If I restrict the file list to only the copy, tough, it manifests the error as well. Other points: 1. The failure is affected by #include files. If I replace an #include <typedefs.h> with contents of typedefs.h (using #if 0 #else control in the .c file), then the output is formatted properly. 2. There is an interaction between two different include files. typedefs.h includes others, including one which define the typedef unsigned char u1. The second include file has typedef u1 Pin_pinDef_t (referencing the first typedef). If I copy _either_ include file contents inline instead of including the associated .h file, the bug goes away. 3. The __pad0__ symbol in the output might be a clue. I didn't find it in my source directory. Unfortunately I don't have any more time to try to reproduce this.
I reported a similar problem as "Bug 639716", with the minimal set of source codes that can reproduce the bug.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!