[Icc-avr] history of c

[Jaspers, Ton]

There is a reason. An 'int' is an undefined type. It is whatever your
computer likes best. In other words what is most efficient on your
system. On some systems it may be a 16 bit variable on others an 18 bit
or a 32 bit variable. You never know unless you qualify it explicitly as
in 'unsigned short int' or signed 'long int', etc.. So in all cases
where the exact type does not matter we tend to use 'int' and allow the
compiler to use what ever works best on a particular system.  
 
Obviously there are many cases where you need to define your variables
exact. Always use modifiers in those cases such as 'unsigned', 'short',
'const' and lots more. It may help to typedef your variables, but then
there are scholars that heavily oppose typedeffing. They argue that it
hides valuable information.  
 
cheers,
Ton
 
 
PS I still have my first edition of K&R. Must have     
 
 
 


________________________________

	From: icc-avr-bounces at imagecraft.com
[mailto:icc-avr-bounces at imagecraft.com] On Behalf Of BobGardner at aol.com
	Sent: zondag 27 april 2008 17:40
	To: icc-avr at imagecraft.com
	Subject: [Icc-avr] history of c
	
	
	
	Is there a technical reason that char functions like putchar
tend to promote the chars to ints? putchar and getchar have 'always' had
a return type of int. Some of this 'tradition' has to do with a
historical desire to make everything an integer so it will run fast on a
pdp11 I guess, but if I make a mistake and return a char instead of an
int, does something break? Does the wrong half of the int get used as
the return value if there is a size mismatch? I can see how you can
return a char in an int, but how do you return an int in a char? What
gets returned? The hi byte or the lo byte?



	
________________________________

	Need a new ride? Check out the largest site for U.S. used car
listings at AOL Autos
<http://autos.aol.com/used?NCID=aolcmp00300000002851> .

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080429/1ded154f/attachment.html