SO the ampersand & in this case simply means bitwise AND, (bitmasking
operation), not Address Of?
That clarifies things. I believe it is in fact part of the marshalling and
serialization code to send client info to disk or over the wire, thus it
probably needs to be very specific if for no reason other than endianess,
right?
On Wed, Jan 22, 2014 at 2:31 PM, Levi Pearson <levipear...@gmail.com> wrote:
> On Wed, Jan 22, 2014 at 5:23 AM, S. Dale Morrey <sdalemor...@gmail.com>
> wrote:
>
> > For instance in many places, Origin has...
> > pstart->nVersion
> >
> > but fork1 has
> > pstart->nVersion&0xff
> >
> > According to the header nVersion is defined as an int.
> >
> > For the life of me I just can't understand what fork1 is doing with that
> > line of code. It's possible that this code was present in the origin
> code
> > base and only modified later, frankly I'm not sure how I would go about
> > checking.
> >
> > Still the line is bothering me, it's used in several places usually in
> > something along the lines of
> > if(pstart->nVersion >= 2){do something}
> >
> > and in the fork code it's the same except fork1 has the &0xff part as
> well.
> > if ((pstart->nVersion&0xff) >= 2){do something}
> >
> > I'm reading the origin code as
> > pstart object nVersion
> >
> > and the fork1 code as
> > pstart object nVersion at byte 255
> >
> > So it's not making much sense to me.
> > I realize that an int in C++ is 4 bytes, and so this may be saying look
> at
> > only the first (or possibly second) 2 bytes. Even so I'm not sure which
> it
> > may be saying to look at or for that matter why would we only look at 2
> > bytes of a 4 byte int.
>
> The type 'int' in C++ varies in representation depending on the
> architecture. Specifically, it's:
> * not smaller than 'short'
> * at least 16 bits (on a 32/64-bit system, it will usually be at
> least 32 bits, but there is no guarantee of this in the spec)
> * signed
>
> See the std::numeric_limits template class in <limits> to determine
> the numeric properties of the base types in the standard C++ way.
> To find out what they are in C, you'd use <stdint.h>
> In either language, the 'sizeof' operator will give you the size of
> any variable or type (types must be parenthesized, but variable names
> need not be).
> Note that 'sizeof' returns the size in multiples of the 'char' type's
> size, i.e. 'sizeof (char)' is always 1.
>
> The type 'char' in C++ is defined to be:
> * large enough to store any member of the implementation's basic
> character set (which is not defined by the spec)
> * possibly holds negative values (implementation-defined)
> * all bits participate in the representation (no padding)
> * for unsigned char, all bit patterns represent numbers
>
> Note that nothing there says '8 bits'; there are some platforms where
> the bit-width of char is not 8. A co-worker of mine was fairly
> recently programming a DSP chip where the bit width of char was 32
> bits, which was the addressable unit of the processor. Of course,
> this meant that sizeof (int) = 1 for that platform. He was very
> confused for a while.
>
> Also note that if the C or C++ specifications speak of a 'byte', they
> really mean a 'char'. They normally don't use 'byte', though, as it
> is not an unambiguous term.
>
> So... on to the code.
>
> pstart->nVersion&0xff
>
> There are two operators in this expression, '->' and '&'. They are
> both left-associative, and '->' has higher precedence. So this is
> equivalent to:
>
> (pstart->nVersion) & 0xff
>
> The '->' operator is the "member of pointer" operator. Unless it's
> overloaded, in which case it might do something unexpected, it
> dereferences the pointer to its left and looks up the member named on
> its right at the dereferenced struct/object. Unless that member is a
> function or enumeration, the result will be an lvalue designating that
> member.
>
> You didn't explicitly give the type of the nVersion member; based on
> what you *did* say I will assume it is 'int', but if it's actually
> something different then the following could be not quite correct.
>
> So, we have an lvalue of type int on the left of the '&' operator and
> a hexadecimal literal value on the right.
>
> A literal with no suffix will have the smallest type of int, long int,
> or long long int that it will fit in. So, at least 16 bits, most
> likely 32, a signed quantity, and all but the least significant 8 bits
> are zero. We have an 'int' on the left and an 'int' on the right, so
> no integral type conversion takes place.
>
> The '&' operator is the bitwise-AND operator. Since both sides have
> the same bit width, the implementation is the obvious bitwise AND
> (unless it was overloaded, of course), which will have the effect of
> setting all but the least significant 8 bits of the final value to 0,
> with the least significant bits retaining the value they had on the
> left-hand side.
>
> So the final evaluation of the expression is an rvalue of type int.
> It will be a positive integer between 0 and 255 consisting of the
> least-significant 8 bits of the value stored at pstart->nVersion.
>
> This seems like an odd thing to do to a version number, but it might
> be reasonable if it's going to be put into an 8-bit field somewhere
> after the quoted bit of code. It would ensure that you didn't try to
> stuff more than 8 bits into the 8-bit field, but it would certainly
> mangle version numbers that were negative or too large to fit.
>
> --Levi
>
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */
>
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
