1. Home
  2. Electronics (Polish)
  3. esp8266 i snprintf()

esp8266 i snprintf()

Do tej pory we wszystkich moich projektach, zgodnie z zalecaną praktyką stosowałem funkcję snprintf() zamiast sprintf(), aby uniknąć możliwości przepełnienia bufora. Podobnie z innymi funkcjami z stdio.h i string.h, które posiadają taki odpowiednik.

Jednak z tego co widzę, to w przypadku SDK do ESP8266 nie jest to takie proste. Wśród bibliotek udostępnionych przez producenta znajdują się osobne funkcje do manipulowana łańcuchami tekstowymi, z prefiksem "os_". Zamiast sprintf() należy więc używać os_sprintf. Problem w tym, że w zestawie nie ma funkcji sprawdzających wielkość bufora.

Teoretycznie można w projekcie wykorzystać standardowe biblioteki "stdio.h" albo "string.h", jednak z tego co wyczytałem nie jest to zalecane i wynika to ze specyfiki sprzętu (coś z wyrównywaniem pamięci). Kod się skompiluje i może działać, ale wcale nie musi i nie ma gwarancji, że w pewnym momencie się z tego powodu nie wysypie.

Stąd mam kilka pytań do osób trochę lepiej obeznanych z tą platformą:

1) Czy Arduino Core dla ESP8266 też jest dotknięte tą przypadłością? Jest ono zaledwie nakładką na oficjalne SDK, czy też ktoś przeportował standardowe biblioteki uwzględniając tę kwestię i można bezpiecznie używać snprintf()? Niby nie przepadam szczególnie za Arduino, ale to byłoby jakimś argumentem... 2) Czy istnieje jakiś prosty sposób na uniknięcie tego problemu, przy jednoczesnym korzystaniu z os_sprintf()? Czy też jedynym wyjściem jest wcześniejsze sprawdzanie długości wszystkich elementów składowych, wpisywanych?
Reply to
Atlantis
Loading thread data ...

AFAIK snprintf nie jest w standardzie. Podobnie jak printf_s itp.

I o jakim przepełnieniu mowa? Przecież liczba znaków dla %f itd. jest zawsze znana compile time, a dla %s nikt ci nie zabrania użyć strlen, sizeof itp. Zawsze możesz zapodać szerokość, np. %10s. Albo obciąć ilość znaków w łańcuchu zanim pójdzie do printf.

Reply to
slawek

A tego to nie rozumiem, kompilator pod tą platformę nie umie sobie poradzić z wyrównaniem??

Reply to
Marek

Nie znam szczegółów, ale chodzi o jakąś specyfikę sprzętu. Z tego samego powodu nie zaleca się stosowania standardowych funkcji malloc()/free(). Zamiast tego biblioteki od producenta udostępniają os_malloc()/os_free().

Reply to
Atlantis

zaraz ... a mowisz o kompilatorze dla Arduino, do ktorego tenze ESP jest podlaczony laczem szeregowym, czy kompilatorze na wewnetrzny procesor w tymze ESP ?

J.

Reply to
J.F.

W dniu 23.07.2017 o 18:42, Atlantis pisze:

A nie lepiej (i wydajniej) będzie dodać sobie biblioteczkę z takowymi funkcjami:

formatting link
żywam tego na STM32. Działa.

Reply to
Jakub Rakus

przepraszam, że tak debilnie zapytam: czy wy konstruujecie samoloty?

Reply to
invalid unparseable

Nie wiem co konstruują.

Ale wiem że nie potrafią przeczytać dokumentacji.

Reply to
slawek

Oczywiście, że mówię o kompilatorze na wewnętrzny procesor ESP. Kto normalny używałby jeszcze dzisiaj tych modułów w roli dodatku do AVR-a, sterując nimi przez komendy AT? ;)

Po prostu jakiś czas temu wypuszczony został dodatek do Arduino IDE, umożliwiający programowanie ESP w tym środowisku. Z tego co mi wiadomo, opiera się on na SDK od producenta z pewnymi zmianami. Nie wiem jednak jak daleko posunięte są te zmiany i czy w związku z nimi można bezpiecznie używać stdio.h.

Reply to
Atlantis

Tez wlasnie zaczalem z tego korzystac. Ale za mało dłubałem aby ci cokolwiek wyjaśnić. Ja narazie korzystam ze zwyklych stdio i o ile sam sobie pilnuje aby odpowiednio zaznaczac końce stringów i nie wychodzić poza zakres to jakoś mi tam programy dzialaja...

Reply to
sczygiel

taaaak? a to ciekawe, to jest opisane gdzieś?

P.S. jak i z kogo wycisnąć opis (iwpriv) sdk do rtl8186/1?

Reply to
invalid unparseable

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.