On 09.08.2022 07:13, JDX wrote:

> Ewidentny błąd - pokazuje dlaczego należy kompilować z -Wall (oraz
> ewentualnie -pedantic) i nie ignorować ostrzeżeń. Aczkolwiek w

Przy próbie kompilacji z -Wall kompilator (xc32-gcc) wywala kilka błędów
w bibliotece GCC, ale dotyczą one takich rzeczy jak niewykorzystane
zmienne albo niejawne rzutowanie z char* na BYTE* w argumencie funkcji.
Do tej konkretnej konstrukcji z pustą listą parametrów się akurat nie
czepia.


> przytoczonym kontekście nie ma znaczenia - zmienna llen ma zasięg
> lokalny ograniczony do wnętrza if-a i poza wywołaniem MQTTReadPacket()
> nigdzie nie jest tam później używana.

Chodziło mi o inne miejsce - od linii 787. Tam zmienna llen jest
przekazywana do funkcji MQTTReadPacket w taki sam sposób, a potem bierze
udział w wyliczaniu indeksów do MQTTBuffer.
Chociaż z drugiej strony wszystkie z tych operacji to sumowanie. Zmienna
llen jest zmienną lokalną, a wiec jest domyślnie inicjalizowana
wartością 0. Jeśli przekazanie jej przez wskaźnik do funkcji o pustej
liście parametrów nie ma żadnego wpływu na jej wartość, to nie będzie
też miało na późniejsze wyliczenia.
Czyżby pozostałość po jakichś wcześniejszych wersjach kodu, gdzie
faktycznie w parametrze był wskaźnik? A potem autor to przepisał, na
wersję bezparametrową i zamiast dać void wyczyścił listę parametrów, nie
poprawiając wcześniejszych wywołań?


> No i proponuję też zamienić
>     switch(rxBF[1]) {   //MQTTBuffer
> na
>     switch(MQTTBuffer[1]) {   //MQTTBuffer

To była pierwsza rzecz jaką sprawdziłem. Wychodzi na to, że:
1) MQTTReadPacket() wołane bezpośrednio przed tym switchem zwraca 2.
2) MQTTBuffer[01] w tym miejscu zwraca wartość 0x02. Zawsze, niezależnie
od tego czy dane do logowania były prawidłowe, czy nie. Postanowiłem
więc sprawdzić co mamy w MQTTBuffer[0] i sprawa się rozjaśniła - mamy
tam 0x20. Razem te dwa bajty stanowią więc prawidłowy nagłówek
wiadomości CONNACK. Dalej powinny iść jeszcze dwa bajty, z których
ostatni stanowi reurn code informujący o stanie autoryzacji. Serwer
istotnie wysyła całą wiadomość - sprawdziłem tcpdump i wiresharkiem.
3) Spróbowałem więc po prostu sprawdzać MQTTBuffer[3] ale niestety - nie
znajduję tam return code. Wygląda to faktycznie tak, jakby
MQTTReadPacket w tym miejscu odczytywało tylko dwa pierwsze bajty, co
zgadzałoby się z wartością zwracaną przez funkcję.