Lockedstdlib.h, ltoa functions, and __18CXX

Post
forrestc
New Member
2012/08/13 01:11:50
I'm working on porting some code in a new project to XC8, and am having a few weird problems.
 
Specifically, with the ltoa "family" of functions (ltoa, ultoa, ftoa).   The problem being that there seems to be an issue with the XC8 vs C18 style definitions.   
 
In <stdlib.h> these are prototyped as follows:
 
extern char * itoa(char * buf, int val, int base);
extern char * utoa(char * buf, unsigned val, int base);
#ifdef __18CXX
extern char * ltoa(long val, char * buf);
extern char * ultoa(unsigned long val, char * buf);
#else
extern char * ltoa(char * buf, long val, int base);
extern char * ultoa(char * buf, unsigned long val, int base);
#endif
 
My code uses the ltoa(val,buf) calls, but could easily be changed to match the new xc8 syntax of ltoa(buf,val,base);
 
What appears to be happening is that <stdlib.h> is being included a couple of times - at least once with __18CXX being defined and at least once without.   When it hits this section, it yelps about the inconsistent declarations, aka, throws the error:
 
C:\Program Files (x86)\Microchip\xc8\v1.10\include\stdlib.h:106: error: type redeclared
C:\Program Files (x86)\Microchip\xc8\v1.10\include\stdlib.h:106: error: conflicting declarations for variable "ltoa" (C:\Program Files (x86)\Microchip\xc8\v1.10\include\stdlib.h:109)
 
So some questions...
 
1) What is the intended 'native' XC8 syntax for these functions.   It appears that it is ltoa(buf,val,base).   Is this the same for XC16 and XC32?   
 
2) Should __18CXX be getting defined?  I guess I'm asking if this is supposedly a C18 define, and not a XC8 define.   Any ideas why it's getting defined halfway through the code?  I haven't found any places this is being defined in my code, but I guess there is a possibility it's buried somewhere.
 
Thanks.
 
-forrest
forrestc
New Member
Re:stdlib.h, ltoa functions, and __18CXX 2012/08/13 01:54:50
Well, I found the define of __18CXX, it was in 'Compiler.h' in the microchip application libraries.     Looks like it is setting it as a work-around to make the libraries compile easier under the XC compiler...   but definitely causing grief where Compiler.h gets included for the first time after the first include of stdlib.h.
 
I'll dig a bit more on this.
 
-forrest
post edited by forrestc - 2012/08/13 01:59:39
sjb741
Super Member
Re:stdlib.h, ltoa functions, and __18CXX 2012/08/13 07:28:17
Hi forrestc,
 
Here they say "The itoa (integer to ASCII) function is a ...non-standard extension to the standard C programming language. It cannot be portably used..."
 
Regarding Q1:
In the XC16 v1.00 library it says
/* These functions are not ANSI Standard */
extern char *    itoa(char * buf, int val, int base);
extern char *    utoa(char * buf, unsigned val, int base);
extern char *    ltoa(char * buf, long val, int base);
extern char *    ultoa(char * buf, unsigned long val, int base);
 
In the XC8 v1.01 library it has
extern char *    itoa(char * buf, int val, int base);
extern char *    utoa(char * buf, unsigned val, int base);
#ifdef __18CXX
extern char *    ltoa(long val, char * buf);
extern char *    ultoa(unsigned long val, char * buf);
#else
extern char *    ltoa(char * buf, long val, int base);
extern char *    ultoa(char * buf, unsigned long val, int base);
#endif
 
Notice that ONLY the XC16 library has the comment about being non-standard.


 
I've confirmed the itoa problem. For C18 it is not a problem (either way)
   #include <stdlib.h>
   #include "Compiler.h"
OR
   #include "Compiler.h"
   #include <stdlib.h>
 
 
forrestc
New Member
Re:stdlib.h, ltoa functions, and __18CXX 2012/08/13 09:39:54
I note the c18 library has itoa defined with the (int,char *) argument set as well, which means things are even less consistent...
 
Looking in the stdlib headers, it looks like perhaps everything defined in here (which is basically *toa and ato*, and rand/srand) is implementation-specific.   
 
I'm in the process of rebuilding our shared code repository, and am trying to end up with as portable of code as possible.   It looks like I should either switch this code to sprintf, or perhaps build my own implementation of these... or at least wrappers to the built-in functions.