bin/71623: [PATCH] cleanup of the usr.sbin/pcvt code

[Dan Lukes]

The following reply was made to PR bin/71623; it has been noted by GNATS.

From: Dan Lukes <dan at obluda.cz>
To: Giorgos Keramidas <keramida at freebsd.org>
Cc: bug-followup at freebsd.org
Subject: Re: bin/71623: [PATCH] cleanup of the usr.sbin/pcvt code
Date: Mon, 13 Sep 2004 08:48:19 +0200

 Giorgos Keramidas wrote:
 
 > It's a hack.  Hacks are very rarely nice and should be evaluated carefully
 > for their risk vs. merit ratio.
 > 
 > In this case the risk is IMHO great and the merit is not more than that
 > provided by a standard initialization to NULL.  If the code below this
 
 	With exception that v=v desn't emit a code, but v=0 emit some I agree
 with all.
 
 >>>>!     if (kbdc < 32) printf("  %s", ckeytab[(short int)kbdc].csymbol);
 >>>Does the value really have to be a (short int) here?  Wouldn't an (int) be
 >>Because kbdc is type of char. Short int should be sufficient for char.
 
 > IIRC, the range of values for `char' is always within the bounds of the
 > range for `short'.  So yes, short int is sufficient.  I just meant that
 > a cast to a plain `int' would probably be more preferrable, like for
 > example many functions of <stdio.h>.  Apparently there's no special
 > reason why this value should be `short' and not `int', so keeping the
 > existing practice of using an `int' for holding a `char' value is what
 > my suggestion was about.
 
 	OK.
 
 	I suggested (short int) because probability that size of (short int)
 equal to (chat) is higher than for (int).
 
 	When sizes aren't equal then compiler must emit an conversion code.
 
 	Well, I'm understand now that nobody here cares about a few bytes of
 memory or tenths CPU ticks. Some of my programmesr skills came from
 ancient days, so every byte and ticks seems to be valuable for me. But
 no problem for me to adapt to todays programers practices ... ;-)
 
 	If existing practice want int here we should use int.
 
 Dan