Warning pointer targets in passing argument 2 of 'strlcpy' differ in signedness

[GrumpyRez]

Mam Warning
pointer targets in passing argument 2 of 'strlcpy' differ in signedness [-Wpointer-sign]

W

Kod: Zaznacz cały

static int8_t CDC_Receive_FS(uint8_t* Buf, uint32_t *Len)
{
  /* USER CODE BEGIN 6 */
   extern uint8_t USBReceivedDataFlag; // Flaga informujaca o odebraniu danych
   extern uint8_t USBDataRX[50];       // Tablica przechowujaca odebrane dane

   USBD_CDC_SetRxBuffer(&hUsbDeviceFS, &Buf[0]);
   USBD_CDC_ReceivePacket(&hUsbDeviceFS);

     // Wyczyszczenie tablicy odebranych danych
     uint8_t iter;
     for(iter = 0; iter<50; ++iter){
        USBDataRX[iter] = 0;
     }

=> tu  strlcpy(USBDataRX, Buf, (*Len) + 1); // Przekopiowanie danych do naszej tablicy
     USBReceivedDataFlag = 1; // Ustawienie flagi odebrania danych

   return (USBD_OK);
  /* USER CODE END 6 */
}

Nie do końca rozumiem przyczyny tego stanu.

[GrumpyRez]

Nie wiem, czy to nie jest spowodowane tą sumą +1 w wskaźniku :/

[xor]

Komunikat dotyczy zmiennej Buf. strlcpy oczekuje typu char* a otrzymuje uint8_t* który jest typedefem do unsigned char*.
Strlcpy wymaga by string źródłowy był C-stringiem a zawartość Buf przekazywana do CDC_Receive_FS nim nie jest więc ta funkcja się nie nadaje.

[gaweł]

Jak zauważył XOR wyżej, zachodzi tu konflikt typów. Jednak na każdą "koncepcję" kompilatora można znaleźć "anykoncepcję" programisty.
Dla człowieka ciąg znaków jest ciągiem bajtów i h...teczka go obchodzi, czy te bajty mają znak czy nie (w sensie liczb w kodzie U2). Po prostu znak jest znakiem i kropka. Ja osobiście używam znaków jako uint_8, bo to rodzi mniej problemów. Jeżeli znaki są jako int8_t to są problemy w ich komparacji. Przykładowo znaki o kodach >= 128, są zawsze mniejsze od normalnych znaków ASCII (bo liczba ujemna jest zawsze mniejsza od dodatniej → ot taki mały paradoks). Jednak kompilery się czepiają, że przetwarzasz ciągi bajtów ze znakiem czy bez znaku. By wszyscy byli "szczęśliwi" możesz zrobić rzutowanie typu i napisać:

Kod: Zaznacz cały

  strlcpy(USBDataRX, (int8_t *)Buf, (*Len) + 1); // Przekopiowanie danych do naszej tablicy

Buf jest obszarem określonym jako uint8_t *, skoro kompiler chce, by to było jako int8_t * to napisz swoje życzenie wyraźnie. Wtedy kompiler nie ma nic do powiedzenia i zrobi jak ty chcesz (wie, że robisz to świadomie).

[GrumpyRez]

Jak zauważył XOR wyżej, zachodzi tu konflikt typów. Jednak na każdą "koncepcję" kompilatora można znaleźć "anykoncepcję" programisty.
Dla człowieka ciąg znaków jest ciągiem bajtów i h...teczka go obchodzi, czy te bajty mają znak czy nie (w sensie liczb w kodzie U2). Po prostu znak jest znakiem i kropka. Ja osobiście używam znaków jako uint_8, bo to rodzi mniej problemów. Jeżeli znaki są jako int8_t to są problemy w ich komparacji. Przykładowo znaki o kodach >= 128, są zawsze mniejsze od normalnych znaków ASCII (bo liczba ujemna jest zawsze mniejsza od dodatniej → ot taki mały paradoks). Jednak kompilery się czepiają, że przetwarzasz ciągi bajtów ze znakiem czy bez znaku. By wszyscy byli "szczęśliwi" możesz zrobić rzutowanie typu i napisać:

Kod: Zaznacz cały

  strlcpy(USBDataRX, (int8_t *)Buf, (*Len) + 1); // Przekopiowanie danych do naszej tablicy

Buf jest obszarem określonym jako uint8_t *, skoro kompiler chce, by to było jako int8_t * to napisz swoje życzenie wyraźnie. Wtedy kompiler nie ma nic do powiedzenia i zrobi jak ty chcesz (wie, że robisz to świadomie).

Niestety to nic nie zmienia, wręcz pojawiają się kolejne warningi

Komunikat dotyczy zmiennej Buf. strlcpy oczekuje typu char* a otrzymuje uint8_t* który jest typedefem do unsigned char*.
Strlcpy wymaga by string źródłowy był C-stringiem a zawartość Buf przekazywana do CDC_Receive_FS nim nie jest więc ta funkcja się nie nadaje.

Czym zastąpić tą funkcję?


PS. zastąpienie memcpy rozwiązało problem

Kod: Zaznacz cały

memcpy(USBDataRX, Buf, (*Len) + 1);

[j23]

0, 1, 2... A czy przypadkiem nie chodzi o to, że wskaźnik na Len ląduje "w krzakach"? tzn.że numerując argumenty kompilator zaczyna od zera...