[Coco] Drivewire mixed results...

[Chuck Youse]

On Mon, 2008-09-29 at 08:48 -0600, Theodore (Alex) Evans wrote:
> Chuck Youse wrote:
> > On Thu, 2008-09-25 at 07:56 -0500, Boisy Pitre wrote:
> >> On Sep 25, 2008, at 7:52 AM, Chuck Youse wrote:
> >>
> >>>>> int calChecksum(char *ptr, int count)
> >>>>> {
> >>>>>    short Checksum = 0;
> >>>>>    while(--count)
> >>>>>    {
> >>>>>         Checksum += *(ptr++);
> >>>>>    }
> >>>>>    return (Checksum);
> >>>>> }

> 
> Actually the size of the char, short and int are implementation 
> dependent.  Char is merely guaranteed to be no larger than short and 
> short no larger than int.  In fact it is common for the size of int to 
> be either 16 or 32 bits. 

Eh, you're technically correct but gone are the days of 36-bit PDP-10s
and 60-bit CDCs.  It is safe to assume that the architecture is
two's-complement and has a word size that is 8, 16, 32, 64 bits.. and
given that, you know that a short must be at least 16 bits if it's going
to conform to standards, and a char will be 8 bits.  

The size of int is not material in this case.

>  The type of the return value for calChecksum 
> and Checksum should be changed to march one another.

Doesn't matter, if Checksum is declared short, and short is shorter than
int, then it is sign-extended, but the caller will simply disregard the
upper bits.  If calChecksum() is declared to return 'short', the
compiler will silently rewrite that as declared to return 'int'.  That's
why I get annoyed when I see people write

char func();
or
short func();

Because it demonstrates a lack of the fundamental rules of C,
specifically, the default promotions.  The same thing applies to
function arguments, you can't pass anything smaller than an int to a
function.  Hell, you can't perform any operation that involves a binary
operator on anything smaller than an int, for that matter.

C.