Should I be worried about this warning?

I've got an issue with a program and interrupts.
In trying to sort it out, I've been trying to decipher a warning and want to know if it is something I should be worried about, or just ignore it.

ARDUINO-V01.ino:318:63: warning: invalid conversion from 'volatile void*' to 'void*' [-fpermissive]

       memcpy(&COMM_SEND_BUFFER[1], &g.cur_pos, bytes_to_send++);

                                                               ^

In file included from C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/Arduino.h:25:0,

                 from sketch\ARDUINO-V01.ino.cpp:1:

c:\program files (x86)\arduino\hardware\tools\avr\avr\include\string.h:191:14: note: initializing argument 1 of 'void* memcpy(void*, const void*, size_t)'

 extern void *memcpy(void *, const void *, size_t);

The warning is complaining about a buffer I'm using for TwoWire comms.
I've defined the buffer as :

volatile byte COMM_SEND_BUFFER[BUFFER_LENGTH];

and later in the code, I use memcpy to transfer data into it, ready to send out as needed

  ....
  COMM_SEND_BUFFER[0] = I2C_MOTOR_POSITION;
  char bytes_to_send = sizeof(g.cur_pos);
  memcpy(&COMM_SEND_BUFFER[1], &g.cur_pos, bytes_to_send++);
  ....

** The above is only one instance of how I use the array. Other calls stuff different data in to the array.

Everything appears to work correctly, in that I can see the data that's stuffed into it at one end, and read the same data back on the other end when it gets received.

The array is declared as volatile because it also gets updated in the Wire.onRequest ISR

Should I not worry about declaring it as volatile as I do update the buffer in my main code as well?

I have another byte array, also volatile, for the receive portion. Similarly, there are warnings for that one as well.

Offering only snippets make it hard to help.

Is COMM_SEND_BUFFER really changed by an ISR?

If not, just drop the volatile.

Whandall:
Offering only snippets make it hard to help.

Is COMM_SEND_BUFFER really changed by an ISR?

If not, just drop the volatile.

Yes, the buffer is changed.

/************************************************************************************************************************/
/*                                                                                                                      */
/* I2C Request event interrupt routine                                                                                  */
/*                                                                                                                      */
/************************************************************************************************************************/

void espWifiRequestEvent() {

  // ESP has asked for something.
  // Send off COMM_SEND BUFFER
  Wire.write((byte *)COMM_SEND_BUFFER, BUFFER_LENGTH);
  // Set byte 0 of COMM_SEND_BUFFER to I2C NULL.
  COMM_SEND_BUFFER[0] = I2C_NULL;
  

}

The last line ensures that COMM_SEND_BUFFER is not updated elsewhere until the last request has transferred to the I2C master.

Warnings generally tend to indicate where you might have problems compiling the same code with another compiler. By declaring a variable volatile, it ensures the compiler's optimization doesn't omit it when it is recognized as not being used by the main program. In practice, when you build a library that demands the user's code to include a variable declaration for use by the library, that variable is going to be volatile. If you omit that you run the risk of having it optimized out. In theory, it doesn't hurt to declare a variable volatile unless you're dealing with complex code on a severely memory constrained platform where every bit of saved space is valuable. In practice, if you develop code according to NASA or MISRA guidelines, any warning under the most pedantic compilation, will result in your code being rejected. Back to reality, while a warning of that type should never cause you a problem, all warnings should be treated as deal-breakers and be dealt with. Change your code or change the library. Just because somebody declared a variable as volatile, doesn't necessarily mean it needs to be. Often this will be done simply to bring to your attention the fact that there is a potential issue that needs to be addressed.

DKWatson:
...
By declaring a variable volatile, it ensures the compiler's optimization doesn't omit it when it is recognized as not being used by the main program.

Does the fact that I do actually modify the contents of the array in the main code then mean that I do not have to declare it as volatile?

Change your code or change the library. Just because somebody declared a variable as volatile, doesn't necessarily mean it needs to be. Often this will be done simply to bring to your attention the fact that there is a potential issue that needs to be addressed.

Changing the library is not really an option here I think :wink: so I'm hoping that the second sentence in the above is applicable in this case

I would introduce a volatile flag to block the access to the buffer and not use the first buffer element.

If you can not make structural changes,
I think you could just cast the volatile attribute away to get rid of the warning.

'Does the fact that I do actually modify the contents of the array in the main code then mean that I do not have to declare it as volatile?'

Again, in theory yes. Examine how you use it though. The pre-processor is very clever (and sneaky). Depending on the level of optimization, it will try to reduce or eliminate as much as possible. As long as the PP is convinced that you need that variable, it will leave it alone. It doesn't cost you anything however, to declare it volatile just to get rid of the warning.

Whandall:
I think you could just cast the volatile attribute away to get rid of the warning.

That did it.
Compiled (and tested) okay.

Thanks