View previous topic :: View next topic |
Author |
Message |
SeeCwriter
Joined: 18 Nov 2013 Posts: 160
|
sprintf format error |
Posted: Mon Jun 01, 2015 9:32 am |
|
|
When a variable is declared as an int, the following sprint() statement fails to compile with a format error:
Code: |
int myvar = 3;
sprint( ptr, "%d", myvar );
|
If I change the format to %c, it compiles. Or if I change the variable declaration to byte, which is int8_t, it compiles.
Does this make sense?
v5.046 PCWHD, 18F87J60. |
|
|
SeeCwriter
Joined: 18 Nov 2013 Posts: 160
|
|
Posted: Mon Jun 01, 2015 9:35 am |
|
|
"sprint" is a typo, it should be sprintf. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19549
|
|
Posted: Mon Jun 01, 2015 10:21 am |
|
|
Do you possibly have a #type declaration in your code?.
Remember a default 'int' is unsigned, while %d prints a signed variable. Normally though I'd not expect that to complain, but if int had been re-declared, so it was an int16 (for example), then the printf would complain.
Just tried it, and if I have:
#type int=16
then it complains exactly as you describe.
You then have to use %ld
Last edited by Ttelmah on Mon Jun 01, 2015 10:37 am; edited 1 time in total |
|
|
SeeCwriter
Joined: 18 Nov 2013 Posts: 160
|
|
Posted: Mon Jun 01, 2015 10:32 am |
|
|
I have a number of typedef's, but I did not redefine 'int'.
I even tried format %u, and it still failed. It doesn't make sense. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19549
|
|
Posted: Mon Jun 01, 2015 10:39 am |
|
|
Not typedef's #type.
This changes the default size of a variable.
With int re-declared as an int16, then the %ld format has to be used.
Do a search in your code for #type. There will be one in the chip include file, so look carefully at what they all say. |
|
|
SeeCwriter
Joined: 18 Nov 2013 Posts: 160
|
|
Posted: Mon Jun 01, 2015 11:37 am |
|
|
I've searched all the files in PICC\Devices and in PICC\Drivers and I could find no #type statements. I also searched all my project files, and no #type.
But I'm beginning to think there is something else going on. The compiler is acting differently. It no longer generates a list of compiler errors, it just lists one error at a time. Fix that error and recompile, and it lists one error...etc. And the errors I'm getting now don't make sense, such as the sprintf() format error. I tried %u, %d, %ld, %lu, and they all generate a format error if the variable is declared as 'int'.
So I change the variable to 'byte', and that error goes away, but the next one is "Function used but not defined." But it is defined. I have a whole file that is nothing but function prototypes that is included right after the chip header file. Nevertheless, I move the prototype into the same file as the call. Still get the error. Move the prototype to just before the call, still get the error. I finally rewrite the function into a #define statement. Now the error is gone, but a new one shows up, and it's the next line of code: Function used but not defined. Comment out that call, and the next line is flagged as an undefined error. This is all bogus. I think the project is corrupt or there is a problem with the new compiler version, v5.046. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
|
SeeCwriter
Joined: 18 Nov 2013 Posts: 160
|
|
Posted: Mon Jun 01, 2015 12:12 pm |
|
|
I did not remember that. However, I have wrapped all TCP/IP stack statements in #ifdef's and have removed TCP/IP from the project. I also renamed the tcpip directory created under my project directory just to make sure no stack files were being accessed.
That will present a problem in the future when I try to enable Ethernet capability and have to go through the program re-declaring many variables. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19549
|
|
Posted: Mon Jun 01, 2015 1:02 pm |
|
|
First, start with a much smaller (literally ten line) program, and verify that things work correctly.
Then look at #device=ANSI. This makes the default integer size int16, so %d will print an int16. Makes the variable sizes match what the ethernet stack will expect.
Then consider if you might have something really simple, like a #define that is affecting your int definition.
On your 'error' behaviour, there is a tick box in the project options 'show all errors'. If this is unticked, only the first error will be shown. From the command line, this is the -E option. It does suggest that some project options have been changed. Look at everything here carefully. Perhaps a global define?. |
|
|
SeeCwriter
Joined: 18 Nov 2013 Posts: 160
|
|
Posted: Wed Jun 03, 2015 4:57 pm |
|
|
Even wrapping all the Ethernet includes and configurations in #ifdef's to remove them from the program did not solve the problem. My last resort was to start over.
I created a new project with no Ethernet capability, and copied over all my non-Ethernet related code to the new project. And now all the weirdness is gone, I can build an executable, and it's running on my hardware. |
|
|
|