This prepares for #1058, which will pad bit-fields only to
the next byte, instead of the next sizeof(int) (two bytes).
OutputBitFieldData now outputs chars instead of ints, and
calls to this function loop until there is less than one byte
to output. A final partial byte is written out with zero padding
as a final partial int was previously.
* Allow overlap of bit-field storage units
Previously,
struct s {
unsigned int x : 10;
unsigned int y : 10;
};
had sizeof(struct s) == 4.
With this change, allow the storage units of x and y to overlap,
so sizeof(struct s) == 3, with y stored immediately after x,
with no padding between them.
An int bit-field (the only type currently supported) will still
never occupy more than two bytes.
* ParseStructInit: Fix typo and expand comment
Explain why there are at most 30, not 32 bits.
* ParseStructDecl: Rewrite AddBitFieldCall
No behavior change.
Co-authored-by: Jesse Rosenstock <jmr@users.noreply.github.com>
The general approach of cl65 when generating the command lines to be executed is to first put options and the put files. However, this doesn't work well with the --lib option which would rather need to be put when libraries in general are put. I opted to not add this special behavior to cl65 as
* the use case for the --lib option is _VERY_ specific
* cl65 is after all a wrapper for ordinary use cases
That lets them match old-style definitions. It avoids "Type conflict" error messages. It allows shorter function calls.
Fixed the types of some variables in "test/ref/otccex.c". It avoids crashes on 64-bit Windows (32-bit Windows with 64-bit pointers).
When compiling cc65, it will by default place the git hash (if available) of
the checked out commit in the version string. This isn't useful when building
a package for a Linux distribution, since there either won't be an upstream
git hash if there is one at all.
Thus we replace GIT_SHA with a more versatile BUILD_ID, which can be defined
to any arbitrary string. When building, its contents will be appended to the
version string instead of the git hash.
If BUILD_ID is not defined by the user the behaviour will be exactly the same
as before. That means BUILD_ID gets automatically defined to Git <GIT_SHA>,
if it can be determined from a checkout.