From: SourceForge.net <no...@so...> - 2006-11-10 10:25:15
|
Feature Requests item #1593259, was opened at 2006-11-09 10:45 Message generated for change (Comment added) made by frief You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1593259&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Frieder Ferlemann (frief) Assigned to: Nobody/Anonymous (nobody) Summary: cheaper return types for some library functions Initial Comment: some functions of SDCC's library could probably use a smaller return type: Functions iscntrl() isdigit() isgraph() islower() isprint() ispunct() isspace() isupper() isxdigit() could probably return bit (on mcs51) instead of char without causing problems. Also _sdcc_external_startup() could return bit instead of unsigned char. If this is changed it might make sense to bumb the version number as some user code will require adapting. memcmp() strcmp() strncmp() could probably return char instead of int without causing problems. ---------------------------------------------------------------------- >Comment By: Frieder Ferlemann (frief) Date: 2006-11-10 11:25 Message: Logged In: YES user_id=589052 > These changes would probably be incompatible with ANSI C. Yes. My attitude towards that is somewhat mixed, as we have mutually rationales there: small code, ANSI compatibility and to a lesser extend compatibility towards other 8-bit compilers. Our library is (I think with good reason) not ANSI with respekt to f.e. int getchar(void) and int putchar(int c). I would be surprised to learn if other mcs51 compilers used 16 bit variables there. I also see that with our current implementation of bitwise additions (1+1=0) (gcc: 1+1=1) we'd run into problems with expressions like isprint('A') + isupper('A') being evaluated to false. This should probably be changed to the behaviour of GCC!? A sidelook to other 8-bit compilers would probably tell us that function return the smallest type that can fit the range of results. I think we should follow that path. (Duck and cover, Frieder) ---------------------------------------------------------------------- Comment By: Raphael Neider (tecodev) Date: 2006-11-09 12:22 Message: Logged In: YES user_id=1115835 These changes would probably be incompatible with ANSI C. Some defines a la #define ANSI_C_COMPLIANT 1 // enabled by default #if defined(ANSI_C_COMPLIANT) && ANSI_C_COMPLIANT > 0 #define BOOL_RET_T char #define CMP_T int #else #define BOOL_RET_T bit #define CMP_T char #endif BOOL_RET_T iscntl(...); CMP_T strcmp(...); might help, but introduce more options for the user to choose from---and more options to raise incompatibilities among compiled library versions... Regards, Raphael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1593259&group_id=599 |