Zachowanie kompilatora C przy użyciu łańcuchów tekstowych w funkcji send()?

Mam pytanie do osób w większym stopniu niż ja ogarniających zachowanie
kompilatorów języka C. Właściwie chcę się upewnić, że moje rozumowanie
jest słuszne.

Pisze obecnie pewną bibliotekę, której głównym elementem będzie maszyna
stanów. Jednym z jej głównych zadań będzie przetwarzanie i przesyłanie
dalej wiadomości wrzucanych do bufora pierścieniowego.

Od strony użytkownika będzie to wyglądało w ten sposób, że w dowolnym
momencie w programie będzie musiał wywołać funkcję, która będzie
wyglądała mniej więcej tak:

send(const char* str);

Wskaźnik str zostanie zapisany w buforze cykliczny, gdzie będzie czekał
do momentu, aż maszyna stanów będzie gotowa go odczytać i przesłać
dalej. W przypadku danych zapisywanych w RAM-ie siłą rzeczy trzeba
będzie więc zadbać, żeby żyły odpowiednio długo i np. nie znikły ze
stosu. Konieczne będzie więc używanie tablic globalnych albo lokalnych
statycznych.

A co w sytuacji, kiedy będę chciał wysłać po prostu wartość podaną
wprost w argumencie funkcji, np.?

send("przykladowy tekst");

Co w takiej sytuacji zrobi kompilator?

1. Zapisze tekst bezpośrednio we flashu i przekaże funkcji wskaźnik na
początek łańcucha zapisanego w pamięci nieulotnej.
2. Przed wywołaniem skopiuje wartość z flasha na stos i przekaże
wskaźnik do miejsca w pamięci RAM - po zwinięciu się stosu zawartość
może zostać nadpisana.
3. Zachowanie nie jest jasno zdefiniowane i zależy od innych czynników.

Oczywiście mówimy o w miarę współczesnym, 32bitowym mikrokontrolerze, z
jedną przestrzenią adresową dla flasha/RAM-u.

Najbardziej logiczna wydaje mi się opcja pierwsza, ale jak mówię - wolę
się upewnić.

W AVR - i pewnie w innych harvardach - jest możliwość zrobienia tak,
że nie będzie używany RAM - send(PSTR("tekscik z ROMu"));
a jako argument leci wskaźnik - ale do flasha.

Moje pytanie dotyczyło czegoś innego - chciałem się upewnić, czy
faktycznie łańcuch zdeklarowany jako argument funkcji (a nie jawnie,
jako globalna stała z kwalifikatorem const) zawsze będzie zapisany we
flashu. Wyobraźmy sobie np. hipotetyczną sytuację:

Send("Lights on");
Send("Lightf off");

Czy nie istnieje np. ryzyko, że kompilator spróbuje to niejawnie
zoptymalizować i zdefiniuje sobie we flashy łańcuchu "Lights ", "on"
oraz "off", a potem będzie tworzył ich kombinacje na stosie, przed
przekazaniem w argumencie funkcji?

On 26.08.2022 16:40, Dawid Rutkowski wrote:

W AVR - i pewnie w innych harvardach - jest możliwość zrobienia tak,
że nie będzie używany RAM - send(PSTR("tekscik z ROMu"));
a jako argument leci wskaźnik - ale do flasha.
Tak to było robione na części ośmiobitowych mikrokontrolerów, takich jak
PIC16/PIC18 albo właśnie AVR (i w związku z tym również większość płytek
Arduino). Żeby uniknąć kopiowania do RAM-u, trzeba było deklarować
łańcuchy tekstowe za pomocą specjalnych makrodefinicji. Istniały też
specjalne wersje funkcji do operacji na łańcuch, przygotowane z myślą o
nich.

W przypadku nowoczesnych układów 32bitowych (STM32, PIC32,
ESP8266/ESP36) nie ma już takiej potrzeby, bo zarówno flash jak i RAM
stanowią część tej samej przestrzeni adresowej i można się do nich
odwoływać za pomocą tych samych wskaźników, a łańcuchy zdefiniowane jako
const char* trafiają do flasha.
Oczywiście trzeba uważać na to co się robi, bo np. próba zapisu pod
adres we flashu spowoduje rzucenie wyjątku.

Moje pytanie dotyczyło czegoś innego - chciałem się upewnić, czy
faktycznie łańcuch zdeklarowany jako argument funkcji (a nie jawnie,
jako globalna stała z kwalifikatorem const) zawsze będzie zapisany we
flashu. Wyobraźmy sobie np. hipotetyczną sytuację:

Send("Lights on");
Send("Lightf off");

Czy nie istnieje np. ryzyko, że kompilator spróbuje to niejawnie
zoptymalizować i zdefiniuje sobie we flashy łańcuchu "Lights ", "on"
oraz "off", a potem będzie tworzył ich kombinacje na stosie, przed
przekazaniem w argumencie funkcji?

Moje pytanie dotyczyło czegoś innego - chciałem się upewnić, czy
faktycznie łańcuch zdeklarowany jako argument funkcji (a nie jawnie, jako
globalna stała z kwalifikatorem const) zawsze będzie zapisany we flashu.
Wyobraźmy sobie np. hipotetyczną sytuację:
Send("Lights on");
Send("Lightf off");
Czy nie istnieje np. ryzyko, że kompilator spróbuje to niejawnie
zoptymalizować i zdefiniuje sobie we flashy łańcuchu "Lights ", "on" oraz
"off", a potem będzie tworzył ich kombinacje na stosie, przed przekazaniem
w argumencie funkcji?

Moje pytanie dotyczyło czegoś innego - chciałem się upewnić, czy
faktycznie łańcuch zdeklarowany jako argument funkcji (a nie jawnie,
jako globalna stała z kwalifikatorem const) zawsze będzie zapisany we
flashu. Wyobraźmy sobie np. hipotetyczną sytuację:

Send("Lights on");
Send("Lightf off");

Czy nie istnieje np. ryzyko, że kompilator spróbuje to niejawnie
zoptymalizować i zdefiniuje sobie we flashy łańcuchu "Lights ", "on"
oraz "off", a potem będzie tworzył ich kombinacje na stosie, przed
przekazaniem w argumencie funkcji?

Ale wymyśliłeś... Ogólnie należy przypomnieć sobie C - i niezależnie,
co zrobi kompilator, taka zmienna będąca argumentem funkcji ma
gwarantowany czas życia tylko do wyjścia z tego konkretnego wywołania
tej funkcji (a jeszcze może chciałbyś "reentrant"?). Tak jest w C i
tyle.

On 26.08.2022 22:19, Dawid Rutkowski wrote:

Ale wymyśliłeś... Ogólnie należy przypomnieć sobie C - i niezależnie,
co zrobi kompilator, taka zmienna będąca argumentem funkcji ma
gwarantowany czas życia tylko do wyjścia z tego konkretnego wywołania
tej funkcji (a jeszcze może chciałbyś "reentrant"?). Tak jest w C i
tyle.
Jeśli już proponujesz przypomnienie sobie C, to należałoby sobie
przypomnieć czym jest const char* (albo char*) w tym języku. Tutaj nie
mamy do czynienia z czymś takim jak String C++ albo innych językach
wysokiego poziomu. To nie jest obiekt albo kontener na dane, podczas
tworzenia którego zachodziłaby alokacja pamięci.
To jest po prostu zwykły wskaźnik, który przechowuje jedną, jedyną
informację - adres początku łańcucha znaków w pamięci.

Żeby pokazać różnicę, wyobraźmy sobie następną sytuację w C:


const char* globalny_wskaznik = NULL;

void foo(const char* str) {
globalny_wskaznik=str;
}

Z następującą sytuacją w C++:

std::String globalny_string;

void bar(std::String str) {
globalny_string = str;
}


Co się stanie po wywołaniu pierwszej funkcji? Otrzyma ona wskaźnik z
adresem na jakiś obszar w pamięci. Adres ten zostanie przekopiowany do
globalnego wskaźnika, a sam str zostanie zdjęty ze stosu. To co się
będzie działo z samymi danymi na które wskazywał nie jest w żaden sposób
określone - wszystko zależy od tego o jakim typie pamięci mówimy. Mogą
rezydować wiecznie we flashu, mogą być cały czas dostępne jako zmienna
globalna w RAM-ie, ale mogą też zniknąć w wyniku zdjęcia ze stosu albo
dealokacji ze sterty w innej części programu.

Co się natomiast dzieje w drugim przykłaadzie? Wywołanie funkcji
powoduje utworzenie obiektu klasy std::String, który zostaje
zainicjowany konkretnym tekstem i utworzy swoją instancję w pamięci. W
skutek użycia operacji przypisania zostanie wywołany konstruktor
kopiujący, który utworzy osobną kopię zawartości str w obiekcie
globalny_string. Po wyjściu z funkcji bar zostanie wywołany destruktor
obiektu str, jednak jego globalna kopia będzie nadal istniała.

Send("Lights on");
Send("Lightf off");

A co do send(const char *aArg)
to nigdy nie potrafiłem zapamiętać, czy zabronione jest zmienianie
wartośvi aArg czy też wartości wskazywanej...
Czyli czy nie wolno:
aArg=b;
Wolno.

czy
aArg[3]=c;
Nie wolno.

Bo była chyba jeszcze konstrukcja, która nie pozwalała na to inne podstawienie.
Nadal jest: send(const char * const aArg)

Ogólnie to są bzdury do męczenia studentów.
C K&R rulez na wieki ;
Zwłaszcza trigraphy.

Przy wywołaniu send("tekscik"), gdy send(const char *aArg),
"tworzony" jest zarówno wskaźnik aArg jak i anonimowa tablica z zawartością "tekscik".
I obie te zmienne mają czas życia do zakończenia wywołania tej funkcji.

A co do send(const char *aArg)
to nigdy nie potrafiłem zapamiętać, czy zabronione jest zmienianie
wartośvi aArg czy też wartości wskazywanej...

On 27.08.2022 10:28, Dawid Rutkowski wrote:
Przy wywołaniu send("tekscik"), gdy send(const char *aArg),
"tworzony" jest zarówno wskaźnik aArg jak i anonimowa tablica z zawartością "tekscik".
I obie te zmienne mają czas życia do zakończenia wywołania tej funkcji.
Tutaj nie masz racji, a przynajmniej opisywane przez Ciebie zachowanie
nie jest żadną uniwersalną regułą. Nie ma żadnej zasady która mówiłaby,
że anonimowa tablica jest tworzona na stosie tuż przed utworzeniem
wskaźnika, który by na nią wskazywał.
Takie ciągi znaków zwykle są zbierane podczas kompilacji i umieszczone w
rodata (czyli w przypadku mikrokontrolerów najczęściej we flashu) i
potem po prostu wskaźnik będzie inicjowany wartością wskazującą na
początek odpowiedniego ciągu znaków.
Widać to chociażby w HEX-ach wsadów do starszych systemów
mikroprocesorowych (Z80, 8051) gdzie wszystkie teksty są zebrane w
jednym miejscu.
Problemy pojawiają się w przypadku niektórych architektur, gdzie
kompilator (o ile nie poinformujemy go, by robił inaczej) będzie przy
starcie programu kopiował dane do RAM-u, bo wskaźnik na dane w RAM-ie i
we flashu to nie to samo. Nawet wtedy ciągle jednak będą one istniały
cały czas w formie zmiennych globalnych, a nie zostanę ulokowane na stosie.

Moje pytanie odnosiło się do czegoś innego - chciałem się upewnić, czy
przypadkiem w pewnych sytuacjach program w sposób niejawny nie zrobi mi
niespodzianki i np. zamiast użyć wskaźnika wprost do ciągu w rodata w
sposób niejawny nie wygeneruje tymczasowego tekstu na stosie, złożonego
z fragmentów innych tekstów, w ramach optymalizacji.

Ogólnie to są bzdury do męczenia studentów.
C K&R rulez na wieki ;
Zwłaszcza trigraphy.