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"
Jonas Maebe schrieb:
> ik wrote on Fri, 23 Oct 2009:
>
>> 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 :)
>
> No, you cannot use bi
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 wikip
On Sat, Oct 24, 2009 at 3:26 AM, 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
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://
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
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 conver
On 23/10/2009, 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 a
Graeme Geldenhuys wrote on Fri, 23 Oct 2009:
uint32_tSearchStart:31;// file offset to full text search table
uint32_tsearchlen: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 u
ik wrote on Fri, 23 Oct 2009:
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 :)
No, you cannot use bitpacked records for C header translations.
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/
On Fri, Oct 23, 2009 at 8:15 PM, Graeme Geldenhuys
wrote:
> Hi,
>
>
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_tSearchStart:31;// file offset to full text search table
uint32_tsearchlen:1; // if high bit set, size of
search record size is 16-bi
11 matches
Mail list logo
