Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 22 Mar 2013 09:51:31 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Building unstable jumbo failed

>From: magnum Sent: Friday, March 22, 2013 4:16
>
>FWIW, if I understand things right, representing a file format or network
protocol
>bitfield with a C bitfield is not guaranteed to be portable - the internal
>representation of the bitfield is undefined. But I can't see anything we
can
>do about that if it's specified like this.

I do not think this is correct.  The warning could be output for a couple
reasons.

1. there is no way to 'legally' access a bit field as it actual layout.  The
bitfield I fixed had all 16 bits used, and was 'exactly' a 16 bit integer in
width.
2. the bit field was not at a 16 bit offset, due to byte packing of the
structure, and location within the structure.

Now, I am not sure which issue the compiler was complaining about.  The
typecast and recast do exactly the same thing as the union.  The union
simply 'hides' what it is doing.  Also, on an align required system, I am
not sure how the union will play. It may break the structure, aligning the
data.  I am already pretty sure that on aligned required systems, that these
type packed structures will NOT work, and we will have to build proper
aligned stuctures, and then read the data blob as an array of bytes, and
write them one element at a time, into a proper aligned structure.   The
wpa2john does not do that, it simply 'typecasts' the raw structure into the
data stream.

Jim.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.