cochran_emc.h: packed structs
Thiago Macieira
thiago at macieira.org
Tue Oct 28 09:28:31 PDT 2014
On Tuesday 28 October 2014 18:03:27 Lubomir I. Ivanov wrote:
> On 28 October 2014 17:54, Thiago Macieira <thiago at macieira.org> wrote:
> > On Tuesday 28 October 2014 17:39:27 Lubomir I. Ivanov wrote:
> >> > __declspec(packed)
> >>
> >> i don't have that in MSVC 2003; perhaps it's a newer feature.
> >
> > Yeah, I was wrong, it's not there.
> >
> > http://msdn.microsoft.com/en-us/library/dabb5z75.aspx
> >
> > That's probably why the GCC attribute is disabled in MinGW for "MS struct"
> > compatibility. So it's not a bug, it's a feature.
> >
> > The suggestion is to not require packing of structs. Reorder the members
> > so
> > you don't need packing, if you can, or try to use different types if you
> > really need the members in that order due to data storage or protocol.
> >
> > That said, the cochran_emc_log_t structure only uses unsigned char. I
> > don't
> > see why packing is necessary in the first place.
>
> ok, i see.
>
> it was in the GCC bugzilla so i though it was an actual bug.
> not sure where they have documented it.
>
> updated patch to remove the packing for cochran_emc_log_t - missed that.
Wait, I only looked at cochran_emc_log_t.
cochran_emc_config1_t and cochran_cmdr_config1_t require packing for the
misaligned short and int. It would be better if you changed them to unsigned
char with the right size and manipulated individual bytes. This also gets you
the endianness correct.
uemis_sample_t and cochran_cmdr_log_t don't need packing for the member
access, but uemis_sample_t has an odd number of bytes in size, so the packing
changes the overall struct's size. So that changes the use of the struct in
array form in uemis_parse_divelog_binary.
Are we sure of the sample size? It's an odd number of bytes...
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
More information about the subsurface
mailing list