Hi,

The first item is 31bit and the second item is 1 bit. Does FPC support a record structure that can define bit level sizes?

    uint32_t    SearchStart:31;    // file offset to full text search table
    uint32_t    searchlen:1;          // if high bit set, size of
search record size is 16-bit

If not, I guess I can continue with what I already do - read this as a 32bit unsigned and then when I need to work with that data, split the 32bit value into two separate variables as shown below.

var
  SearchTableOffset: longint;
  SearchTableRecordLengthIs16Bit: boolean;
begin
  SearchTableOffset := _pHeader^.SearchStart and $7fffffff;
  SearchTableRecordLengthIs16Bit := _pHeader^.SearchStart and $80000000 > 0;

Is there any better way of doing this? Does Object Pascal record structure support bit size definitions?

You can use bitpacked records:

http://www.google.com/codesearch?hl=en&lr=&q=bitpacked+record+package%3Ahttp%3A%2F%2Fpasxlibbind \.googlecode\.com&sbtn=Search

Here is an example on how I use it :)

Ido
http://ik.homelinux.org/

ik wrote on Fri, 23 Oct 2009:

No, you cannot use bitpacked records for C header translations. Bitpacked records are not guaranteed to have the same layout as in C (or even in different versions of FPC). If it works, you are lucky, and it will probably fail on some other platform or in another FPC version one day.

The internal format of bitpacked records is opaque, and it is impossible to express the alignment requirements of C bitpacked structs or their internal fields with them.

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

Graeme Geldenhuys wrote on Fri, 23 Oct 2009:

This code will at best only work on little endian systems. Most/all big endian systems also count the bits in bitpacked structs in the opposite order. The exact layout of a bitpacked C struct can however only be known by reading the ABI for that platform (it can even differ between different OSes on the same hardware architectures).

The safest way is to look things up in the ABIs you want to support, add code similar to the above for that specific ABI, and add a compiler directive to abort the compilation if someone tries to compile for an ABI you have not checked.

Is there any better way of doing this? Does Object Pascal record structure support bit size definitions?

Not in a C/ABI compatible way at this time.

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

Jonas Maebe wrote

The internal format of bitpacked records is opaque, and it is impossible to express the alignment requirements of C bitpacked structs or their internal fields with them.

So you suggest I continue like I was before? Reading that perticular piece of data as an uint32 and then splitting it later into two or more variables with whatever bit information I need.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Graeme Geldenhuys wrote

The first item is 31bit and the second item is 1 bit. Does FPC support a record structure that can define bit level sizes?

I've done this kind of thing quite a bit in the past. Usually, I define a "raw" version and a "clean" version, and write two routines to convert back and forth. I read into the raw version, convert to the clean one, use that in my application, then if I have to write it back, convert the clean back to raw and write it out. I've been Windows only, but taking into account Jonas' advice, you could make converter versions for each ABI and ifdef them appropriately, and that would be located in one place only, not strewn about your code everywhere you needed to access that data. Its a little bit more work, but it only has to be done once each way, and when I'm actually using the data, it saves a ton of mucking about in the middle.

Lately, I've taken to wrapping such data into objects, and using the getters and setters to handle getting things from and putting things into the right bits, and only having the raw storage.

Of course, if you only need it once, it really doesn't matter where or how you convert it.

Jeff.

That's make this feature very not useful and unneeded.

If I have a C struct that has a non standard bit count, how can I make sure that I'll have the needed data on the right field, and without any segfult in the middle ?

Doesn't Pascal have something to offer me to deal with it ?

Ido

http://ik.homelinux.org/

ik wrote

Doesn't Pascal have something to offer me to deal with it ?

Bitwise operations + inline functions. Covers most of the needs.

thanks,
dmitry

2009/10/24 ik :

Doesn't Pascal have something to offer me to deal with it ?

I've settled on using the uint32 to read that data, and use a bitpacked structure I overlay over then uint32 so I can access the two pieces of data in a more human readable form.

I read a bit about endianness on wikipedia, and decided the above is 100% sufficient for me. fpGUI is only supported on x86 systems (well that's all I have), so the INF Documentation Viewer will work fine on Linux, *BSD, Windows, ReactOS and Mac OS X. So that covers the most popular OSes and is good enough for me and my target audience

In general yes, but I still use it for simple cases which cover 95% of the usage :)

ik wrote on Sat, 24 Oct 2009:

[bitpacked records cannot be used for interfacing with C]

That's make this feature very not useful and unneeded.

It was primarily added for compatibility with Mac Pascal compiler, and it's also compatible with GPC's bitpacked records. It's as useless as "set" types to interface with C though.

FPC doesn't at this time, no.

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.