Conference hydra::amiga_v1

I'm in the process of "porting" some code to the Amiga, and I'm having 
problems with using any type of bitfield declaration.  

The code runs beautifully under VMS/(VAXC,GNU-CC), VAX/Ultrix/(VCC,CC), 
RISC/Ultrix/(CC), MS-DOS, and even the Mac, but I get errors using 
Lattice/SAS C V5.10.  

Has anyone used this "feature"?  I will call the support line tomorrow, 
unless someone has an answer for me.

-Steve

*** This small program will produce the same error as the "real" code

/*-----------------------------------*/

typedef unsigned char BITS;

main()
{
    /* basic structure */
    struct foo {
	BITS a : 1;
	BITS b : 2;
	BITS c : 1;
        BITS p : 4;
        BITS d : 8;
        BITS e : 16; 
    } bar;
    unsigned long int *tmp = (unsigned long int *)&bar;

    /* set some bits */
    memset(&bar, 0, sizeof(struct foo));
    bar.a = 1;
    bar.b = 1;
    bar.d = 0xff;

    /* output the result in a hex integer format */
    printf("bar = 0x%08X\n", *tmp);
}

/*---------------------------*/

*** this is output from the compiler...

Compiling foo.c
	BITS a : 1;
foo.c 8 Error 80: invalid bit field
	BITS b : 2;
foo.c 9 Error 80: invalid bit field
	BITS c : 1;
foo.c 10 Error 80: invalid bit field
        BITS p : 4;
foo.c 11 Error 80: invalid bit field
        BITS d : 8;
foo.c 13 Error 80: invalid bit field
        BITS e : 16;
foo.c 15 Error 80: invalid bit field
    } bar;
foo.c 17 Error 64: structure contains no members
    bar.a = 1;
foo.c 23 Error 14: undefined member "a"
    bar.b = 1;
foo.c 24 Error 14: undefined member "b"
    bar.d = 0xff;
foo.c 26 Error 14: undefined member "d"
Maximum number of errors/warnings reached
Execution terminated

Total files: 1, Compiled OK: 0, Failed to compile: 1

> /*-----------------------------------*/;   
>
> typedef unsigned char BITS;

Make this:

typedef unsigned int BITS;


And it works fine.


Also, I'm not sure what the compiler willdo,but for member "e" below, isn't
16 bits a bit (no pun) large for an unsigned char?


> main()
> {
>     /* basic structure */
>     struct foo {
> 	BITS a : 1;
> 	BITS b : 2;
> 	BITS c : 1;
>         BITS p : 4;
>         BITS d : 8;
>         BITS e : 16; 
>     } bar;
>     unsigned long int *tmp = (unsigned long int *)&bar;


john

Thanks john, that's a help.  However, using an unsigned int causes me some
other problems.  I _need_ a structure with bitfields that must be 3 bytes
long.  If I use an unsigned int, and only specify 24 bits worth of data, the
structure becomes 32 bits long.  This is part of a comm protocol message,
and is very specific - it must be 3 bytes.  Any ideas?

The other structures that I'm dealing with, we pad out to 32 bits, so they're
not a problem.  Originally, we discovered that (for portability) specifying
an unsigned char always gave us the size structure we needed (no padding,
or alignment problems).  However, it looks like Lattice might not support
this.

I don't know how valid the 16 bit BITS (unsigned char) field is, but _most_
compilers will generate the 16 bits that you want.  It certainly looks odd,
but...

Steve

If you absoultely need 24 bits, I'd make SURE you only get 24 bits and that
no compiler will EVER (like in later versions of it) start padding a struct
on you.

I'm sure there's a better way, but how about just using an array of 3 chars
and then using bitwise AND and OR operators to manipulate the fields.

You might look in the X11 server sources for how they handled it since they
have lots of bit fields to handle there asd the DIX stuff is "portable".



unsigned char BITS[3];		/* 3 chars = 24 contiguous bits */



    struct foo {
	BITS a : 1;		// bit  0	BITS[0]
	BITS b : 2;		// bits 1-2	BITS[0]
	BITS c : 1;		// bit  3	BITS[0]
        BITS p : 4;		// bits 4-7	BITS[0]
        BITS d : 8;		// bits 0-7	BITS[1]
        BITS e : 16; 
    } bar;


BTW - struct foo is 32 bits, not 24...

john

You can't make what you're doing portable using bit fields. First problem:

"A bit-field shall have a type that is a qualified or unqualified version
of int, unsigned int or signed int." (from X3.159-1980, 3.5.2.1)

Your code isn't valid ANSI C, so it's not very portable to start with.

Other problem:

	The order of allocation of bit-fields within a unit (high-order to
	low-order or low-order to high-order) is implementation-defined.

So you don't know what order the bits are going to wind up in your structure.
One of these days, you're bound to run into a compiler that does things the
"wrong" way around, and have to rewrite most of that code anyway.

My solution when I ran into this was to blow off bitfields, and use macros
to extract the data chunks from an integral type long enough to hold the
bits I needed.

	<mike

Bit-fields are a pain in the ass.  If a large amount of code didn't depend
on them, I would use some simple macros to set the bits.

I knew about the possible problem with the order of bit-fields within
a unit, and I've dealt with that with a small amount of conditionalized
code.

I can probably live with "int" sized structures, as long as I don't 
sizeof() them, and know what size I need to deal with.

I also just discovered that SAS didn't implement the %n format control
for sprintf, etc.  This was draft ANSI last time I looked.  They also
reverse the functionality of %x and %X.  I _hope_ these are fixed in
the 5.10a update!

Steve

SAS's attitude about non-ANSI things is "5.10 isn't ANSI compliant;
6.0 will be." I wouldn't expect them to fix the missing %n until 6.0.
I don't recall seeing anything about x & X being swapped in 5.10a, either.
You might give them a call to check, and if it isn't, report it (they can't
fix it if nobody tells them about it).

	<mike

> I don't recall seeing anything about x & X being swapped in 5.10a, either.

From the bugfix_5.10a file:

FIXED UAM-1586
TITLE: PRINTF format codes %lx and %lX get the case wrong

Is this the same bug?

john

Just a word about Lattice printf.  I'm surprised at how limited
this implementation is.  After all, Lattice redid printf numerous times
if I recall correctly.

Coincidentally last night I found out that %n didn't work.  You probably
already know that [] member stuff isn't supported yet.  All I was trying
to do was parse out of a string 3 integers, 1 float and get the rest as a
string.  This is fairly difficult to do without [] or %n.  I was just
hacking so I used a hack to get what I wanted, but maybe someone can tell
me an easy way that I've missed.

I'm still using Lattice 5.05...

-steve