Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove USHORT typedef. #457

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

waywardmonkeys
Copy link
Contributor

This was defined as unsigned for DOS and unsigned short for everyone else, but it was only used in bitfield definitions where just having unsigned is fine.

Other bitfield definitions (in some cases, immediately adjacent to the ones modified here), were already just using a bare unsigned, so this improves the consistency of the definitions.

This was defined as `unsigned` for DOS and `unsigned short` for
everyone else, but it was only used in bitfield definitions
where just having `unsigned` is fine.

Other bitfield definitions (in some cases, immediately adjacent
to the ones modified here), were already just using a bare
`unsigned`, so this improves the consistency of the definitions.
@waywardmonkeys
Copy link
Contributor Author

There's a reasonable argument to be made that any bitfield that is just 1 bit could instead be a _Bool / bool, but that'd be for some other PR, not just cleaning up USHORT.

Copy link
Collaborator

@nbriggs nbriggs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe these (all?) need to be "unsigned short" rather than "unsigned" because structures will be pointing to 16-bit word(s) shared with the Lisp code and have to be bit/size exact.

@waywardmonkeys
Copy link
Contributor Author

These are the storage types within the structs, which have specific bit sizes assigned to them. The type here only ends up mattering for what happens when a value is extracted from the struct ... and for whether it is signed or unsigned.

Also note that a number of other structs are using bare unsigned as well.

@nbriggs
Copy link
Collaborator

nbriggs commented Feb 25, 2023

Clang and GCC seem to be consistent in the way they lay out the bits, but as far as I recall there was no requirement that pad bits be in any particular place when the number of bits didn't add up to the size of the field, and the alignment requirement is that of the largest element of the struct.

With reference to this source:

int main(int argc, char *argv[])
{
struct uswbits {
  unsigned short a:1;
  unsigned short b:7;
  unsigned short c:8;
} us ;

struct uwbits {
  unsigned a:1;
  unsigned b:7;
  unsigned c:8;
} u;
 us.a = u.a;
}
% clang -cc1 -fdump-record-layouts /tmp/foo2.c

*** Dumping AST Record Layout
         0 | struct uwbits
     0:0-0 |   unsigned int a
     0:1-7 |   unsigned int b
     1:0-7 |   unsigned int c
           | [sizeof=4, align=4]

*** Dumping AST Record Layout
         0 | struct uswbits
     0:0-0 |   unsigned short a
     0:1-7 |   unsigned short b
     1:0-7 |   unsigned short c
           | [sizeof=2, align=2]

The structs that use bare unsigned should have bit fields that add up to 32. Some of the structs are going to be used as templates over a 16-bit aligned pointers, some over a 32-bit aligned pointers, and I'd rather not introduce unnecessary warnings for alignment mismatches when it's trivial to get it right.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants