On Fri, 26 Aug 2022 20:25:57 +0200, Atlantis <m...@w...pl>
wrote:
> Send("Lights on");
> Send("Lightf off");

Tak z ciekawości pytam, czemu opisy stanów jako parametry robocze
mają być stringami? To ma działać na styku z białkiem?

--
Marek

do góry

On 27.08.2022 10:28, Dawid Rutkowski wrote:
[...]
> 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. :-D

do góry

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.


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

w przypadku const char* masz do czynienia ze wskaźnikiem na const char.
Czyli nie wolno ci modyfikować wartości na którą wskazuje wskaźnik, ale
już sam wskaźnik możesz modyfikować. Zabronione jest *aArg='a', ale już
jak najbardziej wykonasz aArg++. Bez tego nie byłoby przecież możliwe
iterowanie po łańcuchach tekstowych w formie const char*.
W C istnieją też wskaźniki char* const - w tym przypadku możesz
modyfikować zawartość, ale już nie wolno zmienić adresu na który
wskazuje wskaźnik.
Dostępna jest też najbardziej restrykcyjna kombinacja: const char* const
- ani nie zmodyfikujesz wartości, ani adresu na który wskazuje wskaźnik.

do góry

sobota, 27 sierpnia 2022 o 12:59:44 UTC+2 Atlantis napisał(a):
> 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.

Piszesz w C.
Nie w asemblerze, który z tego C zrobi kompilator.
Zrobi jak zrobi i może nawet działać.
Ale nie ma pewności.
Inny kompilator, a nawet ten sam z innym -Ox, może zrobić inaczej i działać już nie
będzie.
Jak jest send("tekscik") to po zakończeniu tej funkcji "tekscik" w tym samym miejscu
w pamięci może dalej być, ale nie musi.
Dlatego należy go skopiować - albo dawać wskaźnik na globala.
Tyle z punktu widzenia C.
Wskaźniki nie są do zabawy - bardzo łatwo utrudnić sobie życie.

Cóż, nikt do C nie zmusza - można pusać w assemblerze, możnasobie zmodyfikować język
i kompilator - tylko wtedy już nie będzie to C.

do góry

sobota, 27 sierpnia 2022 o 11:53:58 UTC+2 JDX napisał(a):

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

O, czego to się człowiek nie dowie na starość...
Ale czy to na pewno K&R C?
Nie pamiętam tego z książki (a książka na poziomie "Diuny" ;),
no i nie jest to coś, co jest potrzebne samo z siebie, a dopiero
na komputerach w dzikich krajach, co nie mają ASCII, a jakiś np. ISO646 (no dobra
EDBIC też miał kłopot, ale na IBM360 pusze się w FORTRANie ;)

Ale jest fajne.
Poubarwiam tak niektóre programy ;>

do góry

On Sat, 27 Aug 2022 11:53:20 +0200, JDX wrote:
> On 27.08.2022 10:28, Dawid Rutkowski wrote:
> [...]
>> 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)

Albo send(char * const aArg) :-)

Obie o tyle bezsensowne, ze funkcja i tak dostanie kopie adresu,
nie ma jak zmienic argumentu.
W innym miejscu ma taka deklaracja sens.

J.

do góry

Atlantis <m...@w...pl> wrote:
> 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?

Po co sie martwisz? Kompilator ma to zrobic tak zeby lancuch znakow
zachowywal sie jak stala. W szczegolnosci ma istniec po tym jak
zakonczy sie wykonanie funkcji. Teoretycznie mozna sobie wyobrazic
jakis skomplikowany system ktory przydziela dynamicznie pamiec
a zwalnia ja gdy nie jest potrzebna. Z tego co wiem zaden
kompilator nie robi czegosc takiego. Robia co innego, jak
masz np.

"turn lighths on"

i

"lights on"

kompliator moze jako drugi lancuch uzyc koncowa czesc pierwszego.
Kompilator moze zastapic _uzycie_ lancucha znakow przez sztuczki
w podobnym stylu do tego co sobie wyobrazales. Ale te sztuczki
dzialaja gdy w miejcu uzycia lancuch jest znany.

--
Waldek Hebisch

do góry

On 27.08.2022 16:06, Dawid Rutkowski wrote:
> sobota, 27 sierpnia 2022 o 11:53:58 UTC+2 JDX napisał(a):
>
>>> Ogólnie to są bzdury do męczenia studentów.
>>> C K&R rulez na wieki ;>
>> Zwłaszcza trigraphy. :-D
>
> O, czego to się człowiek nie dowie na starość...
> Ale czy to na pewno K&R C?
Prawie na pewno tak.

> Nie pamiętam tego z książki (a książka na poziomie "Diuny" ;),
> no i nie jest to coś, co jest potrzebne samo z siebie, a dopiero
> na komputerach w dzikich krajach, co nie mają ASCII, a jakiś np. ISO646 (no dobra
EDBIC też miał kłopot, ale na IBM360 pusze się w FORTRANie ;)
Ano. Chyba tylko raz w życiu użyłem trigraph-ów. Było to wtedy, gdy
pisałem jakiś ,,heloł łorld" w C na S/390. :-D

> Ale jest fajne.
> Poubarwiam tak niektóre programy ;>
To zobacz sobie ten niedoceniany język programowania:
https://en.wikipedia.org/wiki/Brainfuck :-D

do góry

sobota, 27 sierpnia 2022 o 20:55:55 UTC+2 JDX napisał(a):
> On 27.08.2022 16:06, Dawid Rutkowski wrote:
> > sobota, 27 sierpnia 2022 o 11:53:58 UTC+2 JDX napisał(a):
> >
> >>> Ogólnie to są bzdury do męczenia studentów.
> >>> C K&R rulez na wieki ;>
> >> Zwłaszcza trigraphy. :-D
> >
> > O, czego to się człowiek nie dowie na starość...
> > Ale czy to na pewno K&R C?
> Prawie na pewno tak.

Wiki twierdzi, że jednak dopiero ANSI C.

> > Nie pamiętam tego z książki (a książka na poziomie "Diuny" ;),
> > no i nie jest to coś, co jest potrzebne samo z siebie, a dopiero
> > na komputerach w dzikich krajach, co nie mają ASCII, a jakiś np. ISO646 (no dobra
EDBIC też miał kłopot, ale na IBM360 pusze się w FORTRANie ;)
> Ano. Chyba tylko raz w życiu użyłem trigraph-ów. Było to wtedy, gdy
> pisałem jakiś ,,heloł łorld" w C na S/390. :-D

I nic dalej?

> > Ale jest fajne.
> > Poubarwiam tak niektóre programy ;>
> To zobacz sobie ten niedoceniany język programowania:
> https://en.wikipedia.org/wiki/Brainfuck :-D

Przemyśliwałem.
Ale moim ulubionym ezoterycznym językiem jest hq9+ (choć nie jest Turing-complete).

do góry

On 27.08.2022 21:43, Dawid Rutkowski wrote:
[...]
>>>>> C K&R rulez na wieki ;>
>>>> Zwłaszcza trigraphy. :-D
>>>
>>> O, czego to się człowiek nie dowie na starość...
>>> Ale czy to na pewno K&R C?
>> Prawie na pewno tak.
>
> Wiki twierdzi, że jednak dopiero ANSI C.
A gdzie konkretnie tak twierdzi? Bo jestem pewien, ze o trigraphach
czytałem kiedyś w książce autorstwa K&R.

>
>>> Nie pamiętam tego z książki (a książka na poziomie "Diuny" ;),
>>> no i nie jest to coś, co jest potrzebne samo z siebie, a dopiero
>>> na komputerach w dzikich krajach, co nie mają ASCII, a jakiś np. ISO646 (no dobra
EDBIC też miał kłopot, ale na IBM360 pusze się w FORTRANie ;)
>> Ano. Chyba tylko raz w życiu użyłem trigraph-ów. Było to wtedy, gdy
>> pisałem jakiś ,,heloł łorld" w C na S/390. :-D
>
> I nic dalej?
W jakim sensie nic dalej?

do góry