Trying to understand what appeared to have been frustration on the part of two coworkers.

Consider:

Code:
typedef std::vector < char > CHAR_VEC ;
int main() 
{

  CHAR_VEC uv ( 2 ) ;
  char *ptr_buffer = &uv [ 0 ];
  typedef unsigned short ushort_type ; 
  ushort_type value = 0x9C2C ; 
  *ptr_buffer++ = ( value & 0xFF ) ; 
  *ptr_buffer++ = value >> 8 ;   
  for ( std::size_t odx ( 0 ); odx < uv.size(); ++odx ) 
    std::cout << std::hex << static_cast < int > ( uv [ odx ] ) << '\n';

  std::cin.get() ;
}

The result on my implementation:
0x2c
0xffffff9c

1)
For starters, I'm not sure how serialization entered the dicussion but in my view storing unsigned shorts into byte arrays does not equate to serialization. You ask me the array would have to be 4 deep and the contents equate to:
uv[ 0 ] = 'C'
uv[ 1 ] = '2'
uv[ 2 ] = 'C'
uv[ 3 ] = '9'
for serialization. True/False?

2) The value 9C stored when stored in the character array results in: 0xffffff9c. 0x9C is obviously too large for the type. 0x9C is 156 and 0xffffff9c is -100. Two questions:
a) is this an issue of 'overflow' or is this just simply an issue where the value is too large for the type?
b) I thought the difference 127-156 (-29) would be the end result that gets stored in location. Why -100?