Frust der Woche "strcpy"

[oberallgeier]

.. Ein char ist ja eigentlich im Prinzip das gleiche wie ein uint8_t .. Eventuell hat ja mal wer das gleiche Problem.

Stimmt, jetzt, da ich das lese - darüber bin ich auch schon gestolpert - und wohl auch in Studio7. Im Studio4 läuft fast alles das ich code. ICH hatte das damals auf meine äusserst dünnen Kenntnisse der Sprache C zurückgeführt. Übrigens hatte ich ähnliche Probleme mit einer Definitionsbibliothek (Peter Dannegger, "mydefs.h"), soweit ich mich erinnern kann damit:

  typedef unsigned char   u8;
  ..
  typedef uint16_t       u16;   //typedef unsigned short u16;
  typedef  int16_t       s16;   //typedef   signed short s16;

[HaWe]

http://www.cplusplus.com/reference/cstring/strcpy/

function
<cstring>
strcpy

char * strcpy ( char * destination, const char * source );

Copy string
Copies the C string pointed by source into the array pointed by destination, including the terminating null character (and stopping at that point).

(...)

Die Definition verlangt also char*.

so klappt es bei mir immer, sowohl per gpp auf Arduino als auch GCC und gpp auf Raspberry Pi /Linux und Borland C++ und devcpp auf Windows PC

PS
char ist auf 8-bit AVRs ein signed char, nur auf 32bit-cpus ist char unsigned, hat also auch keine über alle Plattformen hinweg fest definierte Bedeutung
Da avr-gcc aber da etwas eigen ist in Bezug auf stdint.h und string.h (Arduino g++ ebenfalls), ist man da in Beug auf strcpy etc. ziemlich auf char eingeschränkt.
u.U. (pure Spekulation) hilft der Compilerschalter -fpermissive, um außer char auch die stdint-Typen zu erlauben, ist aber sicher ebenfalls Compiler- und Plattform-abhängig.

-fpermissive
Downgrade some diagnostics about nonconformant code from errors to warnings. Thus, using -fpermissive will allow some nonconforming code to compile.

Bottom line: don't use it unless you know what you are doing!