makes pointer from integer without a cast... DS1307, RTC, BCD

Question

I know this question has been asked before. It's all over Google and on this site too, but I can't understand people when they explain it. I have already spent far too many hours trying to understand and I still don't so please try to understand that there's something fundamental I am NOT understanding... here we go.

When programming in C on Proteus, I often get the warning and/or error (in this case warning):

makes pointer from integer without a cast

and I don't get it. Like I said, I've already spent hours looking into it and I get it has to do with types, and/or pointers, blah. Someone please explain it to me like a normal person.

Also, I get this a lot. Could it be possible to get this warning from other types of variables without a cast? A character? How would I go about fixing this problem now, and avoiding it in the future?

Here's the context...

#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>
#include "stdlib.h"
#include "USART.h"
#include "I2C.h"
#include "ds1307.h"

void Wait()
{
   uint8_t i;
   for(i=0;i<20;i++)
      _delay_loop_2(0);
}

uint8_t ss,mm,hh,dd,nn,yy,x;    // Appropriately labeled variables
uint16_t sec[3],min[3],hr[3],day[3],month[3],year[3],mode[2];
uint16_t secs,mins,hrs,days,months,years,modes;

int main(void)
{
   _delay_ms(50);
   USART_interrupt_init();          // 
   USART_send('\r');                // Send carriage return
   _delay_ms(100);              // Allows for the LCD module to initialize

   I2CInit();                   // Initialize i2c Bus
   DS1307Write(0x07,0x10);          // Blink output at 1Hz
   while(1)
      {
     int i=0;
     /* SECONDS */
     DS1307Read(0x00,&ss);      // Read seconds address
     /* MINUTES */
     DS1307Read(0x01,&mm);      // Read minutes address
     /* HOURS */
     DS1307Read(0x02,&hh);      // Read hours address
     /* DAY */
     DS1307Read(0x04,&dd);      // Read hours address
     /* MONTH */
     DS1307Read(0x05,&nn);      // Read hours address
     /* YEAR */
     DS1307Read(0x06,&yy);      // Read hours address
     for(i=0;i<5;i++)
     {Wait();i++;}

     sec[0]=(0b00001111 & ss);
     sec[1]=((0b01110000 & ss)>>4);
     sec[2]='\0';
     itoa(sec[0],secs,10);

     USART_putstring(secs); // place string in buffer

and the 2 errors:

../main.c:59: warning: passing argument 2 of 'itoa' makes pointer from integer without a cast

../main.c:62: warning: passing argument 1 of 'USART_putstring' makes pointer from integer without a cast

Answer 1

Your compiler is telling you that the function expects a pointer, but you've passed an integer. So it's going to automatically treat your integer value as an address and use that as the pointer.

For example, itoa expects a pointer to a memory location for its second parameter - that's where it stores the resulting string that it builds from the integer you pass it. But you've passed secs for that - a uint16_t. The compiler is warning you that whatever value is in that integer is going to be used as the address where itoa puts its resulting string.

This kind of thing would cause a segfault on most targets, but I'm not familiar with Proteus.

Anyway, as an example, to fix the itoa warning, use something like the following:

char secs[3];
...
itoa(sec[0], secs, 10);

Hope that helps.

Answer 2

It means that the compiler implicitly casts it for you, however, it notifies you it did by emitting a warning so you know that.

Here's an example using numbers:

float f = 1.0;
int i = f;

Depending the platform, language and compiler settings a couple of scenarios are possible:

• compiler implicitly casts float to int without a warning (bad)
• idem but issues a warning (better)
• compiler settings changed to treat warnings as errors (safe, security critical etc...)

Warnings are a good hint on possible bugs or errors and it's generally wise to fix them instead of suppressing or ignoring them.

In your specific case, I've been looking for an USART_pustring and the first I've found was this one :

void USART_putstring(char* StringPtr)

No need to look further, passing an int to a function expecting char* (if this is the case), 'might' produce an unexpected result.

Solution

Read the documentation of USART_putstring and ensure you 'transform' your input data to the correct type it accepts, the warning will vanish by itself.

EDIT:

+1 for Aenimated1

Ensure that you understand what are the differences between 'integer' and 'pointer to integer' too, he explained that rather well :)

Answer 3

Integers are for counting. Pointers are an abstract indication of where a variable may be found.

To keep things clear in your head it is a good idea to not mix up the two, even if you are on a system where the concrete implementation of a pointer is the same as the implementation of an integer.

It is an error to convert integer to pointer or vice versa, unless you write a cast to say "I know what I'm doing here".

Unfortunately some compilers will spit out "warning" and then generate a bogus binary. If possible, see if you can use compiler switches that will make the compiler say "error" for this case.

If you see this error it usually means that you supplied an integer where the compiler was expecting you to supply a pointer.

---

In your code, you do this with itoa(sec[0],secs,10); is a problem. The itoa function signature is:

char * itoa ( int value, char * str, int base );

You supplied secs, which is a uint16_t (a 16-bit integer), for the parameter char * str. This is an error because it expects the address of an object, but you supplied a number.

---

To fix this you need to stop supplying integers for parameters that are pointers.

For assistance with how to convert the output of DS1307Read to a display string, post a question asking about that specifically.

Answer 4

So here's a completely different answer to the question, at a much higher level, and to make the point clear, we're going to take a step back from C programming and talk about building houses. We're going to give instructions to the people building the house, but we're going to imagine we have some rigid, codified way of doing it, sort of like function calls.

Suppose it's time to paint the outside of the house. Suppose there's a "function" paint_the_house() that looks like this:

paint_the_house(char *main_color, char *trim_color);

You decide you want white trim on a yellow house, so you "call"

paint_the_house("white", "yellow");

and the painters dutifully paint the house white with yellow trim. Whoops! You made a mistake, and nobody caught it, and now the house is the wrong color.

Suppose there's another function, finish_the_floors() that looks like this:

finish_the_floors(char *floor_material, char *color)

The floor_material argument is supposed to be a string like "hardwood", "carpet", "linoleum", or "tile". You decide you want red tile floors in your house, so you call

finish_the_floors("red", "tile");

But the guy who installs the floors comes back and says, "Listen, buddy, 'red' is not a floor material, and 'tile' is not a color, so do you want to try that again?" This time, someone caught your mistake.

Finally, suppose there's a function

furnish_the_bathroom(char *bath_or_shower, int number_of_sinks)

where bath_or_shower is supposed to be the string "bathtub" or "shower", and the second argument is supposed to be the number of sinks you want. You decide you want two sinks and a bathtub and, continuing your careless ways, you call:

furnish_the_bathroom(2, "bathtub");

This time, your bogus "function call" doesn't even make it to the guy who's going to build the bathtub. The architect's dim-bulb nephew, who his brother conned him into hiring for the summer, who can't even tell the difference between a toaster oven and a two-by-four, he's been put in charge of relaying instructions from you to the laborers, and even he can see that there's something wrong. "Um, wait a minute," he whines. "I thought the first thing was supposed to be a string, and the second thing was supposed to be a number?"

And now we can go back to your question, because that's basically what's going on here. When you call a function, you have to pass the right arguments in the right order (just like your instructions to the builders). The compiler can't catch all your mistakes, but it can at least notice that you're doing something impossibly wrong, like passing an int where you're supposed to pass a pointer.