Subject: Notification: incoming/548

From: [email-masked]
Date: Thu, 13 Jan 2000 07:53:00 -0600 (CST)

FVWM Bug Tracking notification

new message incoming/548

Message summary for PR#548
	From: [email-masked]
	Subject: Incorrect specification of bit field
	Date: Thu, 13 Jan 2000 07:52:58 -0600 (CST)
	0 replies 	0 followups

====> ORIGINAL MESSAGE FOLLOWS <====

---

From: "Paul D. Smith" <[email-masked]>
Date: 13 Jan 2000 11:33:10 -0500

%% [email-masked] writes:

  f> typedef struct MenuFeel {
  f>     struct
  f>     {
  f>       unsigned char Animated : 1;
  f>       unsigned char PopupImmediately : 1;
  f>       unsigned char TitleWarp : 1;
  f>     } f;
  f>     int PopupOffsetPercent;
  f>     int PopupOffsetAdd;
  f> } MenuFeel;

  f> It requires that a bit field is declared as int, unsigned int or signed
  f> int.

  f> I checked in Kernighan & Richie, they specify that an "int" datatype
  f> must be used, so I think this should be considered an error in fvwm2: 
  f> "Fields may be declared only as ints; for portability, specify signed or
  f> unsigned explicitly" (Kernighan and Rirchie, 2nd edition (1988) page 150).

This is true of ISO C as well; the above code is not
standard-compliant.  GCC allows char bitfields as an extension.

If you really want to save the space you can do some preprocessor tricks
to have it be a char on GCC and an int on other systems:

  #if __GCC__  || HAVE_CHAR_BITFIELDS
  # define MENU_BITTYPE char
  #else
  # define MENU_BITTYPE int
  #endif

    ...
      unsigned MENU_BITTYPE Animated : 1;
    ...

etc.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 13 Jan 2000 17:30:28 +0100

On Thu, Jan 13, 2000 at 07:53:00AM -0600, [email-masked] wrote:

This is already fixed in the 2.3.x betas.  If there will be a 2.2.5
release it will be fixed there too.

Bye

Dominik ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 14 Jan 2000 11:37:38 +0100

>       unsigned MENU_BITTYPE Animated : 1;

Does this really save space?  I'd have thought that the compiler
already uses the smallest possible data type for a packed bit
field.

Bye

Dominik ^_^

---

From: "Paul D. Smith" <[email-masked]>
Date: 14 Jan 2000 13:04:51 -0500

%% Dominik Vogt <[email-masked]> writes:

  dv> Does this really save space?  I'd have thought that the compiler
  dv> already uses the smallest possible data type for a packed bit
  dv> field.

Well, on most systems these days it won't make any difference in the
above struct since the subsequent ints have to be 4-byte aligned anyway,
so you'll have a space there.  Moving the bitfields to the end of the
struct _might_ save you something--not in an array of MenuFeel's, of
course, but if you malloc'd one by itself--hmm, no, I'm sure malloc
always reserves memory on a 4-byte boundary.  Well, maybe you could save
some stack if you had an auto variable of type MenuFeel :).

Actually, it's up to the compiler what data size to use when you use a
bitfield, I think.  If you weren't using a RISC-y CPU that required
things aligned properly it might save you something.  I don't think FVWM
runs on anything that esoteric :).

I think char-sized bitfields are really only practical if you have an
array of bitfields, like:

  struct foo { char foo : 1; char bar : 1; } baz[100];

Now if each struct foo was only a char instead of an int, you're saving
a lot of space.  Of course, the compiler could put them in an 8bit
quantity even if you used an int type I guess.

Once you stick them into a struct, the alignment properties of the
struct will almost certainly push them to take up 4 bytes anyway.  Well,
I guess you could also win if you put some chars or shorts after the
bitfields.

Whatever.  Just make 'em unsigned int :).