Subject: Tru64 and "signed" enumeration bit fields

From: [email-masked]
Date: Wed, 2 Feb 2000 13:01:13 -0500 (EST)

Now that I've got fvwm-2.3.13 working on Tru64 Unix, thanks to the help of Dan
Espen (thanks VERY much!), I've found other problem that prevents certain
title styles from being displayed properly.

In fvwm/screen.h, there is a structure:

typedef struct
{
  DecorFaceType face_type : 3;
  struct
  {
    JustificationType h_justification : 2;
    JustificationType v_justification : 2;
#define DFS_BUTTON_IS_UP   0
#define DFS_BUTTON_IS_FLAT 1
#define DFS_BUTTON_IS_SUNK 2
#define DFS_BUTTON_MASK    3
    unsigned int button_relief : 2;
    /* not used in border styles */
    unsigned int use_title_style : 1;
    unsigned int use_border_style : 1;
    /* only used in border styles */
    unsigned int has_hidden_handles : 1;
    unsigned int has_no_inset : 1;
  } flags;
} DecorFaceStyle;

The problem is with face_type:  The enumeration DecorFaceType can have up to
seven values.  If it is stored in a bit-field of size 3, the first bit will be
interpreted as a sign bit.  Thus, it will take on the values -4 to +3.  (This
is the behavior of Compaq C, anyways.)

Since adding "unsigned" as a prefix to the type declaration is not valid,
there are two possible fixes:

1.  Extend the size of the field to 4 bits.

2.  "Normalize" the value when you query face_type to an unsigned value by
    explicitly casting the value.

I'm not sure if Compaq C is exhibiting incorrect behavior here.  I do know
that when I made it a bit field of size 4, title pixmaps and button mini-icons
started displaying properly.

-- 
Larry Gensch                                          [email-masked]

                  "May I have ten thousand marbles, please?"

--
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: "Paul D. Smith" <[email-masked]>
Date: 02 Feb 2000 13:40:30 -0500

%% [email-masked] writes:

  lg> In fvwm/screen.h, there is a structure:

  lg>   DecorFaceType face_type : 3;

Did we discuss this before?

Technically this isn't valid; in Standard C (89; not sure about the 99
version) the only valid types for a bitfield are int, unsigned int, and
signed int.  Enums aren't allowed.

In GNU make I actually test for this based solely on whether the
compiler is GCC or not :).  In GCC, it works correctly to make this an
enum _and_ the value will be unsigned: enumerations aren't signed unless
at least one member is signed (IIRC--anyway, it works in GCC).

However, in make what I do is not make the enum a bitfield unless you're
using GCC.  All other compilers will use the enum but without the
bitfield designator.

If we wanted to be as efficient as possible we could get configure to
test (a) whether enum bitfield types are supported, and (b) if so,
whether they need an extra sign bit or not.  Then we could do something
like this:

  #if !defined HAVE_ENUM_BITFIELDS
  # define ENUM_BITFIELD(n) /* empty */
  #elsif defined HAVE_UNSIGNED_ENUM_BITFIELDS
  # define ENUM_BITFIELD(n) :n
  #else
  # define ENUM_BITFIELD(n) :n+1
  #endif

then use:

    DecorFaceType face_type ENUM_BITFIELD(3);

in the code.

Hopefully ":n+1" will work everywhere; the standard says it's legal
since it'll expand to 3+1 which is a constant expression, but...

Just a thought.

-- 
-------------------------------------------------------------------------------
 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: Bob Woodside <[email-masked]>
Date: Wed, 02 Feb 2000 15:05:41 -0500

[email-masked] wrote:
> Espen (thanks VERY much!)...

	Larry, either I've missed some mail, or you and Dan must have had a
private exchange about the other thread ("Fvwm 2.3.13 still not working
on Tru64 Unix"). Could either you or Dan give us a brief description of
what the problem was?

	In the last message I saw, Dan had pointed to a potential problem (the
type mismatch in HandleModuleInput) that we've known for some time is
lurking there, but we haven't seen a confirmation on this list that
anyone's getting bitten by it. Was this it, or was it something else?

Cheers,
Bob

---

From: Bob Woodside <[email-masked]>
Date: Wed, 02 Feb 2000 15:11:26 -0500

Bob Woodside wrote:
> 
>         Larry, either I've missed some mail, or....
> Could either you or Dan give us a brief description of
> what the problem was?

	Just saw Dan's CVS commit fly by when I sent the previous message.
Ignore the question.

Cheers,
Bob

---

From: [email-masked] (lar3ry gensch)
Date: Wed, 2 Feb 2000 15:36:22 -0500 (EST)

[Not Taken Offlist -- (smile)]

> on Tru64 Unix"). Could either you or Dan give us a brief description of

Our exchange was offlist.  I figured that there would be a check-in
soon, since I had confirmed that his proposed fix actually worked.

Sorry for the confusion.

> anyone's getting bitten by it. Was this it, or was it something else?

Yup.  I'm amazed that others hadn't gotten bit by this one yet. 

Myself, I was waiting until "feature freeze" was started before
attempting to use 2.3.x on my work system.  This is usually when I
start pointing out things that aren't working on Tru64 Unix.