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?

do góry

On Sun, 23 Jul 2017 18:42:29 +0200, Atlantis <m...@w...pl>
wrote:
> stosowałem funkcję snprintf() zamiast sprintf()

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.

do góry

On Sun, 23 Jul 2017 18:42:29 +0200, Atlantis <m...@w...pl>
wrote:
> 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).

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

--
Marek

do góry

On 24.07.2017 11:49, Marek wrote:

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

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().

do góry

Użytkownik "Atlantis" napisał w wiadomości grup
dyskusyjnych:5975e339$0$663$6...@n...neostrada.
pl...
On 24.07.2017 11:49, Marek wrote:
>> A tego to nie rozumiem, kompilator pod tą platformę nie umie sobie
>> poradzić z wyrównaniem??

>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().

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

J.

do góry

W dniu 23.07.2017 o 18:42, Atlantis pisze:

> 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.

A nie lepiej (i wydajniej) będzie dodać sobie biblioteczkę z takowymi
funkcjami:
https://github.com/cjlano/tinyprintf
Używam tego na STM32. Działa.

--
Pozdrawiam
Jakub Rakus

do góry

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

do góry

On Mon, 24 Jul 2017 20:13:25 +0200, wół, wół roboczy, wół dojno
roboczo obronny 'POPIS/EU<N...@g...pl> wrote:
> przepraszam, że tak debilnie zapytam: czy wy konstruujecie samoloty?

Nie wiem co konstruują.

Ale wiem że nie potrafią przeczytać dokumentacji.

do góry

On 24.07.2017 14:58, J.F. wrote:

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

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.

do góry

W dniu wtorek, 25 lipca 2017 12:59:06 UTC+2 użytkownik Atlantis napisał:
> On 24.07.2017 14:58, J.F. wrote:
>
> > zaraz ... a mowisz o kompilatorze dla Arduino, do ktorego tenze ESP jest
> > podlaczony laczem szeregowym,
> > czy kompilatorze na wewnetrzny procesor w tymze ESP ?
>
> 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.

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...

do góry