[SOLVED] question about bit field alignment in FPC records

[SymbolicFrank]

A few years ago, I had a job interview for lead embedded and C++ applications. The manager was happy, as he was also an engineer and mostly interested in leadership and the big picture.

During the talk with my potential co-workers, it was clear they barely knew how to program in C. And that their current hot topic was "saving pointers". They grilled me about that.

You can simply store all your data in a global struct, and load / save that to / from disk. It happens a lot in C/C++. So, they kept asking me how I would write pointers to disk.

I explained, that I don't. It doesn't work, for many reasons, not just because the memory addresses change. I write in/export functions. For disk access, or sockets. And I generally use a readable format if I can decide that. Ini-files and XML are popular with me. Json isn't, as there isn't enough meta-data in that format to make it usable.

But they kept repeating that same question. I'm pretty certain they didn't know and wanted me to provide a solution. And in/export functions and readable files weren't it. Much harder than simply writing a struct to disk. I don't think they understood a single word I said.

I wasn't hired.

Although my next job was bugfixing and extending a 25 years old C/C++ application, where they made all the mistakes, and more. So, I know what happens. It's bad.

Readability and Maintainability.

[JernejL]

In fact, you don't need to use bitpacked at all, as Pascal provides alternatives. Consider using bitwise operators: AND, OR, XOR. Probably "bitpacked" was added in a moment of weakness, just like +=, I say.

For interfacing with other structures, technologies and file formats bitpacking is not a moment of weakness but an invaluable tool.
 
Amout of gibberish bit arithmetics code that had been replaced in my project after i switched to bitpacking is outstanding, without this, FPC would be in a stone age.
 
There's people who use FPC daily and trust me, when it comes to compatibility and ease of use, there is no "moment of weakness"..
 

[engkin]

In fact, you don't need to use bitpacked at all, as Pascal provides alternatives. Consider using bitwise operators: AND, OR, XOR. Probably "bitpacked" was added in a moment of weakness, just like +=, I say.

For interfacing with other structures, technologies and file formats bitpacking is not a moment of weakness but an invaluable tool.
 
Amout of gibberish bit arithmetics code that had been replaced in my project after i switched to bitpacking is outstanding, without this, FPC would be in a stone age.
 
There's people who use FPC daily and trust me, when it comes to compatibility and ease of use, there is no "moment of weakness"..

I hope you guys realize that my comments in this thread are pointed at core developers and users that mainly participated in this VERY LONG CHAIN of emails to reject adding a new basic feature to FPC. (Thank you Akira)

@JernejL, they can still throw argument back at you: "You don't need bitpacked, you can write your own library to handle dealing with bits and not scatter bit arithmetic code all over".

[440bx]

I hope you guys realize that my comments in this thread are pointed at core developers and users that mainly participated in this VERY LONG CHAIN of emails to reject adding a new basic feature to FPC. (Thank you Akira)

That's nice to know.  Next time you choose to do that, you might want to mention that is your intention a little bit earlier.

[JernejL]

That's nice to know.  Next time you choose to do that, you might want to mention that is your intention a little bit earlier.

Agreed.. i really did not understand this from the post.
 
However this whole debate really highlights once again, that perhaps a fpc fork might be a desireable option in the future - then things would get done based on real world scenarios of increasing productivity and not religious-like arguments on purity of pascal.
 

[nanobit]

However this whole debate really highlights once again, that perhaps a fpc fork might be a desireable option in the future - then things would get done based on real world scenarios of increasing productivity and not religious-like arguments on purity of pascal.

There is some need for a fork, but for me only a bugfixed version (without new features).
The bugfixed version would also have a trustbuilding effect and attract more users to Freepascal.

[Thaddy]

There is no need for a fork, but feel free to do so.
I think it is pretty well explained by PascalDragon.

Such discussions are useless if 80% is written by people who have no clue..... <Yes, grumpy... >
(80% is actually friendly..)
(clue is actually friendly...)

[440bx]

The bugfixed version would also have a trustbuilding effect and attract more users to Freepascal.

I agree.

Best feature a compiler can have is to be bug free.  Second best is - likely - to be consistent and symmetrical.

There is no need for a fork, but feel free to do so.

There is plenty of need for a fork but, creating a fork is a whole heck of a lot of work.

It seems that part of the problem in creating a fork is that there are too many people afflicted with "featurities" and addicted to "binary sugar".

[PascalDragon]

I hope you guys realize that my comments in this thread are pointed at core developers and users that mainly participated in this VERY LONG CHAIN of emails to reject adding a new basic feature to FPC. (Thank you Akira)

What has you complaining about the use of existing and well used functionality to do with arguing about the inclusion of a new feature?

And just to make that clear: we'll always argue the inclusion of new features. Adding a new feature means that it needs to be supported in the future, that it needs to be maintained. So the feature needs to provide enough worth to offset that need. Or provide something that's not trivially doable already in the language (e.g. anonymous functions or custom attributes are not trivially doable right now, while multi line strings are simply some convenience functionality aka syntactic sugar).

[440bx]

Just in case someone is interested, the following construct causes the next bit field to be aligned on a byte boundary:

Code: Pascal  [Select][+][-]

1.   TAlignedBitField = bitpacked record   // size is 2 - as it should be
2.     OneBit    : 0..1;
3.     Align     : record end;   // this causes the alignment to go to the next byte
4.     OneBit2   : 0..1;
5.   end;
6.  

[engkin]

440bx and JernejL, please accept my apology.

[jamie]

Where do I wish for my Anonymous Record fields within a Record definition so I can bring the
scope of a middle variant case and broken bitfields out to the parent name space ?

In C you can have Unions (variant Case) without a identifier at the head, it simply uses the
name space of the parent. This allows to have variant fields without the need for an extra sub ID.

  of course you need to use unique ID's within the parent structure.

Code: Pascal  [Select][+][-]

1. MyRecord = record
2.    Record
3.     Case byte of
4.      0:(A:Integer);
5.      1:(B:Word;);
6.     End;
7.     C:LongWord;
8.  End;
9.  

In this example, I can access A or B like I would C...

BUt I can't because I can not have a nameless record..

do you think the wish guy will grant it to me?

[engkin]

Just in case someone is interested, the following construct causes the next bit field to be aligned on a byte boundary:

Code: Pascal  [Select][+][-]

1.   TAlignedBitField = bitpacked record   // size is 2 - as it should be
2.     OneBit    : 0..1;
3.     Align     : record end;   // this causes the alignment to go to the next byte
4.     OneBit2   : 0..1;
5.   end;
6.  

I don't think this is documented, and probably not intended. I am afraid this might be considered a bug.

[jamie]

I understand that one but that isn't very clean actually and I see it going away due to the fact that its totally
empty and some in the DEV will deem it as bad style...

 I would rather wrap the field with a NameLess record..

 In fact, if you can have nameless records it could also work as you specified for bit alignment without
the name to place a Tag on it..
 
 It really need to be looked into and considered..

[440bx]

440bx and JernejL, please accept my apology.

Apology accepted, no harm done.

Just in case someone is interested, the following construct causes the next bit field to be aligned on a byte boundary:

Code: Pascal  [Select][+][-]

1.   TAlignedBitField = bitpacked record   // size is 2 - as it should be
2.     OneBit    : 0..1;
3.     Align     : record end;   // this causes the alignment to go to the next byte
4.     OneBit2   : 0..1;
5.   end;
6.  

I don't think this is documented, and probably not intended. I am afraid this might be considered a bug.

It is documented but, not in a very visible way. From the Free Pascal Reference Guide:

Non-ordinal types - which include but are not limited to - sets, floats, strings, (bitpacked) records, (bitpacked) arrays, pointers, classes, objects, and procedural variables, are stored on the first available byte boundary.

It is also documented that the record may be empty (the syntax diagram shows it - section 3.3.2 of the reference guide.) 

Therefore, the compiler's behavior in that case is as spec-ed.  The compiler is aligning the record as documented and, has a size of zero because there are no fields in it, which is legal.


ETA:

In fact, if you can have nameless records it could also work as you specified for bit alignment without the name to place a Tag on it..

I agree but, got to work with what's available.

I can't wait until nameless records are added (if ever) to define the structure "ideally".