🚀 go-pugleaf

On Fri, 30 Aug 2019 09:09:43 +0200, Roman Tyczka wrote:
> https://fossbytes.com/nasa-coding-programming-rules-critical/

To raczej ciekawostka, bo do normalnego życia ma się nijak - NASA to 
jednak dewianci są. :)

"Do not use goto"
"Do not use dynamic memory"
"No function longer than 60 lines of code"

Żadne z powyższych do mnie nie przemawia, ale oczywiście gdybym pisał 
programy sterujące rakietami ziemia-jupiter to na pewno też miałbym 
stracha.

Mateusz

Roman Tyczka <noemail@because.no> wrote:

> https://fossbytes.com/nasa-coding-programming-rules-critical/

To lecimy.

1. Restrict all code to very simple control flow constructs - do not use 
goto statements, setjmp or longjmp constructs, and direct or indirect 
recursion.

Z setjmp/longjmp się zgodzę. goto przydaje się w C, gdzie nie masz RAII i 
chcesz wyczyścić zasoby, i IMO tylko w takim przypadku jest uzasadnione.

Rekurencja... czasem prościej jest zrobić coś rekurencją niż iteracją, 
choć każdą rekurencję i tak można zamienić na iterację, a sama rekurencja 
nie jest zła. Jest zła wtedy, kiedy wymyka się spod kontroli. Wszystko 
zależy od konkretnej sytuacji.

2. All loops must have a fixed upper-bound. It must be trivially possible 
for a checking tool to prove statically that a preset upper-bound on the 
number of iterations of a loop cannot be exceeded. If the loop-bound 
cannot be proven statically, the rule is considered violated.

Zgadzam się.

3. Do not use dynamic memory allocation after initialization.

Znów... zależy od konkretnego zastosowania. MISRA C zresztą mówi to samo. 
Widzę w tym logikę, ale nie chciałbym tak pisać :(

4. No function should be longer than what can be printed on a single sheet 
of paper in a standard reference format with one line per statement and one 
line per declaration. Typically, this means no more than about 60 lines of 
code per function.

Zgoda. Zbyt długie i rozbudowane funkcje to rak. Natomiast znów... jestem 
sobie w stanie wyobrazić wyjątki.

5. The assertion density of the code should average to a minimum of two 
assertions per function. Assertions are used to check for anomalous 
conditions that should never happen in real-life executions. Assertions 
must always be side-effect free and should be defined as Boolean tests. 
When an assertion fails, an explicit recovery action must be taken, e.g., 
by returning an error condition to the caller of the function that 
executes the failing assertion. Any assertion for which a static checking 
tool can prove that it can never fail or never hold violates this rule 
(I.e., it is not possible to satisfy the rule by adding unhelpful 
assert(true) statements).

Zgadzam się odnośnie używania asercji, mój kod też jest zwykle nimi 
najeżony. Nie podoba mi się sztuczne narzucanie "assertion density". 
Asercje powinny być używane tam, gdzie są potrzebne, a nie sztucznie, żeby 
osiągnąć minimum dwie asercje na funkcję. Nie podoba mi się też explicit 
recovery action, choć jeśli dopuszczają wyjątki (a skoro piszą w C to nie 
dopuszczają, bo jak?), to jestem w stanie to przełknąć.

6. Data objects must be declared at the smallest possible level of scope.

Zgoda.

7. The return value of non-void functions must be checked by each calling 
function, and the validity of parameters must be checked inside each 
function.

Tu znów odbijamy się od tego, czy to są sztywne zasady, które trzeba 
stosować, czy zbiór sugestii. Są funkcje, których wartość zwracaną celowo 
ignorujemy, bo flow programu nie różni się w zależności od zwróconej 
wartości (wartość zwrócona jest tylko dodatkową informacją, która może, 
ale nie musi, być użyta).

8. The use of the preprocessor must be limited to the inclusion of header 
files and simple macro definitions. Token pasting, variable argument lists 
(ellipses), and recursive macro calls are not allowed. All macros must 
expand into complete syntactic units. The use of conditional compilation 
directives is often also dubious, but cannot always be avoided. This means 
that there should rarely be justification for more than one or two 
conditional compilation directives even in large software development 
efforts, beyond the standard boilerplate that avoids multiple inclusion of 
the same header file. Each such use should be flagged by a tool-based 
checker and justified in the code.

Po części zgoda, bo preprocesor jest tylko parserem tekstu, ale po części 
nie. W czym im przeszkadzają elipsy? Co do warunkowej kompilacji -- w 
sumie zgoda.

9. The use of pointers should be restricted. Specifically, no more than 
one level of dereferencing is allowed. Pointer dereference operations may 
not be hidden in macro definitions or inside typedef declarations. 
Function pointers are not permitted.

Jestem w stanie znaleźć uzasadnienie, ale znów -- to programista odpowiada 
za to, żeby wskaźniki były użyte prawidłowo. Ciekawe też, czemu wskaźniki 
do funkcji nie są dozwolone.

10. All code must be compiled, from the first day of development, with all 
compiler warnings enabled at the compilers most pedantic setting. All code 
must compile with these setting without any warnings. All code must be 
checked daily with at least one, but preferably more than one, 
state-of-the-art static source code analyzer and should pass the analyses 
with zero warnings.

Tu zgoda w 100%.

Ogólnie... nie chciałbym pracować w środowisku, w którym są sztywno 
narzucone takie zasady. To powinny być zalecenia a nie sztywne reguły.

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

On 30 Aug 2019 07:20:10 GMT, Mateusz Viste wrote:

>> https://fossbytes.com/nasa-coding-programming-rules-critical/
> 
> To raczej ciekawostka, bo do normalnego życia ma się nijak - NASA to 
> jednak dewianci są. :)
> 
> "Do not use goto"
> "Do not use dynamic memory"
> "No function longer than 60 lines of code"
> 
> Żadne z powyższych do mnie nie przemawia, ale oczywiście gdybym pisał 
> programy sterujące rakietami ziemia-jupiter to na pewno też miałbym 
> stracha.

Co prawda nie piszę w C, ale pierwszego i trzeciego warunku też
przestrzegam i nikt mi tego nie narzuca, to po prostu pomaga. 
A metody dłuższe niż kilkadziesiąt linii to zmora. 

-- 
pozdrawiam
Roman Tyczka

On Fri, 30 Aug 2019 12:27:37 +0200, Roman Tyczka wrote:
> Co prawda nie piszę w C, ale pierwszego i trzeciego warunku też
> przestrzegam i nikt mi tego nie narzuca, to po prostu pomaga.
> A metody dłuższe niż kilkadziesiąt linii to zmora.

W ogólnym i teoretycznym przypadku - zgadzam się.

W praktyce bywa jednak że trzymanie się takich sztywnych zasad "bo tak" 
sprawia tylko kłopot. Przykład z głowy: funkcja która wykonuje dużą ilość 
sekwencyjnych kroków konfiguracyjnych czegoś tam. Dzielenie jej na siłę 
niekoniecznie jest racjonalne.
Z goto podobnie: w 95% przypadków goto można z zyskiem zastąpić inną 
konstrukcją, ale zostaje te 5% czasu kiedy GOTO sensownie załatwia temat 
a jakieś wymyślanie pętli/funkcji/czegoś to tylko cudowanie dla sztuki 
niemania goto.


/* init thermonuclear engine, returns ptr on success, NULL otherwise */
void *engine_init(void) {
  void *p = NULL;

  p = malloc(ENGINE_MEMSZ);
  if (p == NULL) goto SHITHAPPENS;
  engine_prepare(p);
  engine_thermonuclear_start(p);

  if (rs232_init(COM_BAUDRATE) != 0) goto SHITHAPPENS;
  if (is_it_friday_afternoon() != 0) goto SHITHAPPENS

  return(p);

 SHITHAPPENS: /* smth went south, cleanup and return NULL */
  if (p != NULL) engine_thermonuclear_abort(p);
  free(p);
  rs232_close();

  return(NULL);
}


Powyższe można wykonać na kilka sposobów, i nie ma problemu pozbyć się 
goto - tylko po co? Gdyby ktoś z jakichś swoich powodów zakazał mi goto, 
to opakowałbym całość w do { ... } while(0) i zamiast goto korzystał z 
break - ale to tylko dodatkowa gmatwanina, wcale nie czytelniejsza.

Mateusz

On Fri, 30 Aug 2019 08:06:33 +0000, Queequeg wrote:
> 2. All loops must have a fixed upper-bound. It must be trivially
> possible for a checking tool to prove statically that a preset
> upper-bound on the number of iterations of a loop cannot be exceeded. If
> the loop-bound cannot be proven statically, the rule is considered
> violated.
> 
> Zgadzam się.

Czekaj czekaj, ale większość programów to jedna niekończąca się pętla.

for (;;) {
  wait_input();
  do_job();
}

Czy ja czegoś nie rozumiem, czy ta reguła zabrania takich konstrukcji? A 
jeśli zabrania, to jak inaczej? Przecież goto też zabraniają. :)

> 3. Do not use dynamic memory allocation after initialization.
> 
> Znów... zależy od konkretnego zastosowania. MISRA C zresztą mówi to
> samo. Widzę w tym logikę, ale nie chciałbym tak pisać :(

Logika jest - ale chyba tylko w lotach kosmicznych albo innych 
przemysłowych dziedzinach, gdzie nic nie ma prawa się nie udać. W 
praktyce program graficzny będzie alokował pamięć zależnie od tego, 
jakich rozmiarów dostał plik graficzny do załadowania. Jak user ma mało 
pamięci to i tak może sobie pomalować w 640x480, a przy większych 
bitmapach dostanie zonk.

> 7. The return value of non-void functions must be checked by each
> calling function, and the validity of parameters must be checked inside
> each function.
> 
> Tu znów odbijamy się od tego, czy to są sztywne zasady, które trzeba
> stosować, czy zbiór sugestii.

if (printf("Hello") != 5) NO_I_CO_MAM_ZROBIC();

Ciekawe jaki mają procent zachorowań na depresję wśród programistów. :)

Mateusz

W dniu piątek, 30 sierpnia 2019 10:06:36 UTC+2 użytkownik Queequeg napisał:

> 1. Restrict all code to very simple control flow constructs - do not use 
> goto statements, setjmp or longjmp constructs, and direct or indirect 
> recursion.
> 
> Z setjmp/longjmp się zgodzę. goto przydaje się w C, gdzie nie masz RAII i 
> chcesz wyczyścić zasoby, i IMO tylko w takim przypadku jest uzasadnione.
> 
> Rekurencja... czasem prościej jest zrobić coś rekurencją niż iteracją, 
> choć każdą rekurencję i tak można zamienić na iterację, a sama rekurencja 
> nie jest zła. Jest zła wtedy, kiedy wymyka się spod kontroli. Wszystko 
> zależy od konkretnej sytuacji.

> 3. Do not use dynamic memory allocation after initialization.
> 
> Znów... zależy od konkretnego zastosowania. MISRA C zresztą mówi to samo. 
> Widzę w tym logikę, ale nie chciałbym tak pisać :(

Te reguły wynikają z tego że to jest praktycznie programowanie embeded/raw metal/realtime. Pamięci mało, stosu mało, często nie ma dynamicznej alokacji i kod nie może rzucić błędem 'bo się alokacja nie udała' tylko musi być tak napisany żeby mieć gwarancję że potrzeby dotyczące pamięci zawsze będą spełnione.

AdamK

On Friday, August 30, 2019 at 9:10:03 AM UTC+2, Roman Tyczka wrote:
> https://fossbytes.com/nasa-coding-programming-rules-critical/

Bardzo polecam ten artykuł: https://www.fastcompany.com/28121/they-write-right-stuff

BTW "All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting." używamy, polecam (-Werror jest, wbrew pozorom, wicej niż korzystne)

w.

Tego rodzaju zalecenia (patrz np. MISRA) można rozmaicie rozumieć.

1. Jako totalne kretyństwo, działania pozorne, nijak nie
 wpływające na poprawność programów. Często formułowane przez
 ludzi niekompetentnych, z przerostem ambicji kierowniczych. Kult
 cargo i efekt gołębia.

2. Jako dupochron - kazali coś zrobić, wdrożyć jakieś procedury
 kontroli jakości i bezpieczeństwa - no to zrobi się to i to i
 tamto - i potem będzie można mówić że dołożyło się wszelkich
 starań a nawet bardziej.

3. Jako formę bicza na młodych nieopierzonych pr
ogramistów-stażystów - niby mobbing jest zakazany - ale to nie
 mobbing, prawda?

4. Jako zbiór mądrości mistrzów programowania którzy pisali
 programy w czasach gdy Amerykanie usiłowali dogonić ZSRR (patrz
 film "Ukryte działania" o tym jak się Fortran hartował) - więc
 zalecenia są adekwatne - więcej niż 60 kart dziurkowanych
 niewygodnie trzyma się jedną ręką.

5. Dezinformację przeznaczoną dla ew. konkurencji.

6. Sposób na zrobienie kasy za audyt zgodności, za normy, za
 narzędzia do audytu, za doliczenie do kosztów. 

7. Wnioski z dotychczasowych porażek - bład przez który rakieta
 poleciała na Wenus zamiast na Marsa był w 61 linijce.

Zachęcam do dopisywania...


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

Mateusz Viste <mateusz@wont.tell> Wrote in message:
> Z goto podobnie: w 95% przypadków goto można z zyskiem zastąpić

Goto ZAWSZE można zastąpić. 

Ludzie programują np. w Pythonie - a goto tam nie ma.

Programują w Haskellu - goto nie ma.

Goto jest jak jedzenie chipsów - jedna paczka nie zabija - ale jak
 ktoś lubi chipsy, to jedząc ileś tam paczek rocznie buduje sobie
 złogi cholesterolu. Tak samo goto - jedno nie szkodzi - ale na
 jednym to się nie skończy - i jakoś tak samo z siebie robi się
 ich tuzin. I zaczyna być niebezpiecznie - bo zamiast myśleć
 strukturalnie - człowiek nastawia się na załatwianie wszystkiego
 jakimś kolejnym skokiem.

Jest tylko jedna rzecz gorsza niż goto - long jumps.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

Mateusz Viste <mateusz@wont.tell> Wrote in message:
>  Zgadzam się.Czekaj czekaj, ale większość programów to jedna niekończąca się pętla.for (;;) {  wait_input();  do_job();} Czy ja czegoś nie rozumiem, czy ta reguła zabrania takich konstrukcji? 

I dlatego lepiej że to nie NASA pisze soft do rozruszników serca ;)

IMHO, nie chodzi o pętle w rodzaju while(cond) something(); ale o
 starą dobrą pętlę for taką jak for(i = 0; i < n; i++) { n = i +
 1; } Nota bene, porównaj jak działają pętle for w C, Pascalu i
 Pythonie.

Ogólnie te zalecenia śmierdzą MCU - czyli trochę specyficznie -
 np. nie ma w ogóle OS - nie ma czegoś takiego jak kompaktowanie
 pamięci, stos to jakieś dwa kilobajty. W takich warunkach
 rekurencja i dynamiczna alokacja to jak skok na bungee z
 papierowym sznurkiem.

 3. Do not use dynamic memory allocation after initialization.

To też jest proste - prosty trik na przyspieszenie działania -
 skoro wszystko przydziela się na początku to potem nie ma
 narzutów czasowych na alokację. To trochę jakby odwrócona leniwa
 inicjalizacja.

7. The return value of non-void functions must be checked

Zaszłość z czasów gdy w ten sposób sprawdzana była poprawność
 działania (w C nie ma mechanizmu wyjątków) - trzeba czytać "nie
 lenić się, jeżeli coś może być sprawdzone to zawsze
 sprawdzać".


>Ciekawe jaki mają procent zachorowań na depresję wśród programistów.

Jeżeli dają jakieś odszkodowania to 100%. A jeżeli nie - przecież
 profesjonalne programowanie nie polega na tym że robi się co chce
 i jak chce - ale robi się to co musi się robić i to za pieniądze
 - to pewnie niższy niż firmach robiących gry i wymagających pracy
 30 godzin na dobę.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

Wojciech Muła <wojtek.mula@gmail.com> Wrote in message:
> On Friday, August 30, 2019 at 9:10:03 AM UTC+2, Roman Tyczka wrote:> https://fossbytes.com/nasa-coding-programming-rules-critical/Bardzo polecam ten artykuł: https://www.fastcompany.com/28121/they-write-right-stuffBTW "All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting." używamy, polecam (-Werror jest, wbrew pozorom, wicej niż korzystne)w.

True.

Jednakże...

 Koncepcje kompilacji, błędów kompilacji itp. to trochę zramolałe są.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

Roman Tyczka <noemail@because.no> Wrote in message:
> On 30 Aug 2019 07:20:10 GMT, Mateusz Viste wrote:
>>"Do not use dynamic memory"

No niby ok.

Ale bez dynamicznej alokacji nie da się pisać w Pythonie, w ECMA
 Script, bardzo trudno w Javie (tylko metody statyczne), w C#
 (tylko wartościowe) itd. Pewnie i w Ruby, ale nie znam aż tak
 dobrze Ruby.

Właśnie dlatego używa się C dla MCU bo to język w którym da się
 nie używać pamięci dynamicznej. I dla MCU to ma sens - robiąc
 malloc() zużywa się więcej pamięci (narzut na dodatkowe
 informacje ile tej pamięci jest) niż po prostu definiując jako
 static char buf[SIZEOFBUF]. A free() nie jest do niczego
 przydatne jeżeli nie ma kompaktowania.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

Roman Tyczka <noemail@because.no> Wrote in message:
> https://fossbytes.com/nasa-coding-programming-rules-critical/-- pozdrawiamRoman Tyczka

Ciekawe jest to czego w tym nie ma:

1. Architektura i wzorce projektowe.
2. Statyczna analiza kodu.
3. Testy jednostkowe i integracyjne.
4. Dokumentacja.
5. Audyt. XP
6. Metodyka (waterfall ?!?)

Ot, bajeczki dla nastolatków.




----Android NewsGroup Reader----
http://usenet.sinaapp.com/

On Friday, August 30, 2019 at 2:49:11 PM UTC+2, Mateusz Viste wrote:
> On Fri, 30 Aug 2019 08:06:33 +0000, Queequeg wrote:
> > 2. All loops must have a fixed upper-bound. It must be trivially
> > possible for a checking tool to prove statically that a preset
> > upper-bound on the number of iterations of a loop cannot be exceeded. If
> > the loop-bound cannot be proven statically, the rule is considered
> > violated.
> > 
> > Zgadzam się.
> 
> Czekaj czekaj, ale większość programów to jedna niekończąca się pętla.
> 
> for (;;) {
>   wait_input();
>   do_job();
> }
> 
> Czy ja czegoś nie rozumiem, czy ta reguła zabrania takich konstrukcji? A 
> jeśli zabrania, to jak inaczej? Przecież goto też zabraniają. :)
> 
> > 3. Do not use dynamic memory allocation after initialization.
> > 
> > Znów... zależy od konkretnego zastosowania. MISRA C zresztą mówi to
> > samo. Widzę w tym logikę, ale nie chciałbym tak pisać :(
> 
> Logika jest - ale chyba tylko w lotach kosmicznych albo innych 
> przemysłowych dziedzinach, gdzie nic nie ma prawa się nie udać. W 
> praktyce program graficzny będzie alokował pamięć zależnie od tego, 
> jakich rozmiarów dostał plik graficzny do załadowania. Jak user ma mało 
> pamięci to i tak może sobie pomalować w 640x480, a przy większych 
> bitmapach dostanie zonk.

To też można różnie rozumieć. Może używanie bibliotecznych wektorów, list,
zbiorów, itd nie jest dynamicznym allokowaniem pamięci (po inicjacji)?


> 
> > 7. The return value of non-void functions must be checked by each
> > calling function, and the validity of parameters must be checked inside
> > each function.
> > 
> > Tu znów odbijamy się od tego, czy to są sztywne zasady, które trzeba
> > stosować, czy zbiór sugestii.
> 
> if (printf("Hello") != 5) NO_I_CO_MAM_ZROBIC();
> 
> Ciekawe jaki mają procent zachorowań na depresję wśród programistów. :)

Bez kontekstu można powiedzieć, że powinien zapisać w pliku logu że doszło do
takiej sytuacji, żeby programista szybciej zaczął się zastanawiać nad 
przyczyną problemu.

A tak poza tym, dużo softu ma bezpośredni wpływ na życie, zdrowie, pieniądze;
jeszcze więcej softu ma pośredni wpływ na ważne sfery życia. Nic dziwnego 
że próbuje się podawać skrótowy zestaw reguł pomagający niezbyt zaawansowanym
programistom tworzyć bezpieczny kod. Natomiast kompulsywne trzymanie się
dowolnych skrótowych reguł, zwłaszcza bez dobrych intencji, oczywiście/zawsze 
źle się kończy, np. depresją programistów.

Pozdrawiam

"M.M." <mmarszik@gmail.com> Wrote in message:
> Nic dziwnego że próbuje się podawać skrótowy zestaw reguł pomagający niezbyt zaawansowanymprogramistom tworzyć bezpieczny kod.


Nic dziwnego.

Tyle że cytowane (link) regułki to takie raczej mało poważne jest.
 No i to nie jest gdzieś tam na serwerze NASA, tylko jakiś
 blogasek kogoś o kim - szczerze - pierwsze słyszę. Autorytet z
 niego taki jak z Piotrusia z IIIc. 

Więc nie łykałbym tego niczym młody pelikan. Także dlatego że
 trochę takich manifestów czytałem.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

On Saturday, August 31, 2019 at 10:44:23 PM UTC+2, slawek wrote:
> "M.M." <m@g.c> Wrote in message:
> > Nic dziwnego że próbuje się podawać skrótowy zestaw reguł pomagający niezbyt zaawansowanymprogramistom tworzyć bezpieczny kod.
> 
> 
> Nic dziwnego.
> 
> Tyle że cytowane (link) regułki to takie raczej mało poważne jest.
>  No i to nie jest gdzieś tam na serwerze NASA, tylko jakiś
>  blogasek kogoś o kim - szczerze - pierwsze słyszę. Autorytet z
>  niego taki jak z Piotrusia z IIIc. 
> 
> Więc nie łykałbym tego niczym młody pelikan. Także dlatego że
>  trochę takich manifestów czytałem.

W ogóle każdy krótki tekst na temat ogólnych wytycznych w 
tworzeniu krytycznych dla zdrowia, życia i pieniędzy systemów jest
mało poważny. Natomiast racje Ci przyznam, że poważniej by było, 
gdyby autor dany esej wyprodukował, sprawdził jak zostanie zrozumiany,
skojarzony, oceniony; następnie poprawił i znowu poddał krytyce, dopiero
potem by opublikował. Za trzecim razem powinny zniknąć dwuznaczności, 
czy allokowanie za pośrednictwem vector, też jest dynamicznym allokowaniem.
Racja też, że w NASA mają środki takie weryfikowanie i poprawianie.

Pozdrawiam

On Saturday, August 31, 2019 at 10:44:23 PM UTC+2, slawek wrote:
> "M.M." <m@g.c> Wrote in message:
> > Nic dziwnego że próbuje się podawać skrótowy zestaw reguł pomagający niezbyt zaawansowanymprogramistom tworzyć bezpieczny kod.
> 
> 
> Nic dziwnego.
> 
> Tyle że cytowane (link) regułki to takie raczej mało poważne jest.
>  No i to nie jest gdzieś tam na serwerze NASA, tylko jakiś
>  blogasek kogoś o kim - szczerze - pierwsze słyszę. Autorytet z
>  niego taki jak z Piotrusia z IIIc. 
> 
> Więc nie łykałbym tego niczym młody pelikan. Także dlatego że
>  trochę takich manifestów czytałem.

Tam jest to lepiej uzasadnione, więcej tekstu, większa szansa na 
prawidłowe odczytanie tego co autor miał na myśli:

http://web.eecs.umich.edu/~imarkov/10rules.pdf

Pozdrawiam.

On 2019-08-31 18:42, slawek wrote:
> Tego rodzaju zalecenia (patrz np. MISRA) można rozmaicie rozumieć.

[...]
99% "pokrycia" to 1-6 itp
1% to 7 itp

AK

On 2019-08-30 19:21, Wojciech Muła wrote:
> On Friday, August 30, 2019 at 9:10:03 AM UTC+2, Roman Tyczka wrote:
>> https://fossbytes.com/nasa-coding-programming-rules-critical/
> 
> Bardzo polecam ten artykuł: https://www.fastcompany.com/28121/they-write-right-stuff
> 
> BTW "All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting." używamy, polecam (-Werror jest, wbrew pozorom, wicej niż korzystne)

Eee... Co to są compile warnings? Znam tylko compile errors :(
Slowem b.dobra zasada.

AK

Mateusz Viste <mateusz@wont.tell> wrote:

>> 2. All loops must have a fixed upper-bound. It must be trivially
>> possible for a checking tool to prove statically that a preset
>> upper-bound on the number of iterations of a loop cannot be exceeded. If
>> the loop-bound cannot be proven statically, the rule is considered
>> violated.
>> 
>> Zgadzam się.
> 
> Czekaj czekaj, ale większość programów to jedna niekończąca się pętla.
> 
> for (;;) {
>   wait_input();
>   do_job();
> }
> 
> Czy ja czegoś nie rozumiem, czy ta reguła zabrania takich konstrukcji? A 
> jeśli zabrania, to jak inaczej? Przecież goto też zabraniają. :)

Ok, fakt, nie myślałem o pętli głównej :) Ona często nigdy się nie kończy. 
Ciekawe jak to rozwiązują, jeśli to jest sztywna zasada a nie zalecenie, 
które można ominąć komentarzem: // this is main loop, rule #2 does not 
apply.

>> Znów... zależy od konkretnego zastosowania. MISRA C zresztą mówi to
>> samo. Widzę w tym logikę, ale nie chciałbym tak pisać :(
> 
> Logika jest - ale chyba tylko w lotach kosmicznych albo innych 
> przemysłowych dziedzinach, gdzie nic nie ma prawa się nie udać.

Z drugiej strony... jeśli się nie uda, to i tak powinny być inne 
mechanizmy fail-safe (niekoniecznie w sofcie), które to wyłapią.

> W praktyce program graficzny będzie alokował pamięć zależnie od tego, 
> jakich rozmiarów dostał plik graficzny do załadowania. Jak user ma mało 
> pamięci to i tak może sobie pomalować w 640x480, a przy większych 
> bitmapach dostanie zonk.

No właśnie.

>> 7. The return value of non-void functions must be checked by each
>> calling function, and the validity of parameters must be checked inside
>> each function.
>> 
>> Tu znów odbijamy się od tego, czy to są sztywne zasady, które trzeba
>> stosować, czy zbiór sugestii.
> 
> if (printf("Hello") != 5) NO_I_CO_MAM_ZROBIC();

Tak, m.in. :)

> Ciekawe jaki mają procent zachorowań na depresję wśród programistów. :)

Pewnie nie większy niż wśród programistów w korpo...

Z drugiej strony u mnie codzienne spotykanie się z absurdami i walenie 
prywatną głową w służbowy mur raczej nie skutkuje depresją. Jeśli już 
to wypaleniem. Objawy nawet podobne, ale jednostka (chorobowa?) inna.

Kati Morton (yt) miała cykl na temat wypalenia.

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

M.M. <mmarszik@gmail.com> wrote:

> Bez kontekstu można powiedzieć, że powinien zapisać w pliku logu że doszło do
> takiej sytuacji, żeby programista szybciej zaczął się zastanawiać nad 
> przyczyną problemu.

A zapis w pliku logu może mieć swoje własne błędy...

Z drugiej strony, Linuksowe funkcje openlog(3), syslog(3), closelog(3), 
vsyslog(3) zwracają void.

> A tak poza tym, dużo softu ma bezpośredni wpływ na życie, zdrowie, 
> pieniądze; jeszcze więcej softu ma pośredni wpływ na ważne sfery życia. 
> Nic dziwnego że próbuje się podawać skrótowy zestaw reguł pomagający 
> niezbyt zaawansowanym programistom tworzyć bezpieczny kod.

Czy niezbyt zaawansowani programiści powinni tworzyć krytyczny kod?

> Natomiast kompulsywne trzymanie się dowolnych skrótowych reguł, 
> zwłaszcza bez dobrych intencji, oczywiście/zawsze źle się kończy, np. 
> depresją programistów.

U mnie na zdrowie psychiczne wpływają wszelkie absurdy korpo niemające 
związku z samym programowaniem. Jakby się wszyscy odp...lili i dali mi 
w spokoju robić to, co umiem i za co mi płacą, to nie miałbym na co 
narzekać.

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

Adam Klobukowski <adamklobukowski@gmail.com> wrote:

> Te reguły wynikają z tego że to jest praktycznie programowanie 
> embeded/raw metal/realtime.

Pewnie tak, wynika z kontekstu, ale przy opisie tych reguł nie było to 
napisane.

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

> > https://fossbytes.com/nasa-coding-programming-rules-critical/
> 
> Ot, bajeczki dla nastolatków.

Nie, po prostu ktoś sobie na blogu napisał. Najprostszy standard kodowania MISRA-C ma 230 stron, ostatnio opublikowany z AUTOSAR dla C++ ma 370 stron. Ten blog nie porusza nawet wierzchołka zagadnienia.

Ogólnie, to nie są jakieś dziwne reguły, właśnie takich należy się spodziewać.
Warto też pamiętać, że pomimo wysokiej popularności NASA jako pop-kulturowego brandu, to nie NASA jest frontem walki o jakość - wynika to z faktu, że w tej branży (podobnie jak w wojsku) nie obowiązują reguły certyfikacji czy homologacji takie jak w cywilnych branżach. Tzn. oni oczywiście dbają o pieniądze podatnika (w sensie - szkoda stracić drogą rakietę) i o swoją reputację (w sensie - jak ją stracą, to kolejnego projektu mogą nie mieć), ale poza tymi dwoma wartościami nie mają o co dbać, bo w szczególności pilot rakiety jest w oczach opinii publicznej bardziej żołnierzem, niż obywatelem, więc jego strata jest przez publiczność postrzegana jako godna ofiara na ołtarzu postępu. Przecież wiedział, że może zginąć, nie?

Inaczej mówiąc 1: publiczna akceptacja fakapu w tej branży jest całkiem wysoka, w odróżnieniu od dziedzin, gdzie się zabija niewinnych obywateli.

Inaczej mówiąc 2: pomimo tego, że te kilka reguł wygląda strasznie dla "normalnego" programisty, to typowy projekt NASA mógłby nie przejść rygoru obowiązującego w lotnictwie cywilnym. No, serio, nie wystarczy mieć funkcje krótsze niż 60 linijek, żeby przejść przez proces certyfikacji[*].

[*] Który to proces właśnie traci reputację przez ostatnie lotnicze fakapy. Tak, zgadza się. Trzeba być jeszcze bardziej (!) rygorystycznym.

> Ciekawe jest to czego w tym nie ma:
> 
> 1. Architektura i wzorce projektowe.
> 2. Statyczna analiza kodu.
> 3. Testy jednostkowe i integracyjne.
> 4. Dokumentacja.
> 5. Audyt. XP
> 6. Metodyka (waterfall ?!?)

Ale chyba nie o tym był ten blog. Natomiast warto zauważyć, że standard kodowania jest właśnie po to, żeby zrobić punkt 2 powyżej i żeby sobie ułatwić osiągnięcie jeszcze kilku innych celów jakościowych. I tylko po to. Gorzej, że z powodu takich blogów ludzie potem myślą, że standard kodowania jest jedyną rzeczą, która odróżnia proces krytyczny od "normalnego" i tylko na nim się skupiają. Tymczasem te "straszne" reguły to jest najmniejszy problem. Klepanie kodu to tylko kilka procent wysiłku, nawet z tymi strasznymi regułami.
Więc bez przesady.

-- 
Maciej Sobczak * http://www.inspirel.com

On 2019-09-01 22:55, Maciej Sobczak wrote:

> Tak, zgadza się. Trzeba być jeszcze bardziej (!) rygorystycznym.

Hehe. Smiechu warte.

AK

> > Tak, zgadza się. Trzeba być jeszcze bardziej (!) rygorystycznym.
> 
> Hehe. Smiechu warte.

O, fajna dyskusja będzie. Dlaczego śmiechu warte?

Zanim się rozpędzisz, mały hint: nie napisałem, że takich reguł powinno być jeszcze więcej, albo że funkcje powinny być jeszcze krótsze. Ale nadal twierdzę, że trzeba być bardziej jeszcze bardziej rygorystycznym.
No więc dlaczego śmiechu warte?

-- 
Maciej Sobczak * http://www.inspirel.com

On 2019-09-02 14:16, Maciej Sobczak wrote:
>>> Tak, zgadza się. Trzeba być jeszcze bardziej (!) rygorystycznym.
>>
>> Hehe. Smiechu warte.
> 
> O, fajna dyskusja będzie. Dlaczego śmiechu warte?
> 
> Zanim się rozpędzisz, mały hint: nie napisałem, że takich reguł powinno być jeszcze więcej, albo że funkcje powinny być jeszcze krótsze. Ale nadal twierdzę, że trzeba być bardziej jeszcze bardziej rygorystycznym.

Tak, ale w inny - normalny sposob (wyjasnien nizej).

> No więc dlaczego śmiechu warte?

Dlatego, że zamiast dopracować "nowy" język programowania typu "safety"
(niech to nawet będzie Misra-C/C++, ale jako _jezyk_ a nie zwykle
chore C/C++ z setkami reguł ktore rudno zpamietac, a co dopiero stosowac
(wiem wiem, Parasofty itp super na tym syfie zarabiaja:), albo po prostu
"odkurzyć" i ulepszyć Adę - czy nawet Modulę2 (tak tak wiem - M2 to
bardziej real-time niz safety) to na siłę trzyma się tych C/C++ czyli
języków _skrajnie_ nie nadających się do tzw. "bezpiecznego"
programowania.

PS: Oczywiscie wiem ze Misra(y) to nie tylko j.prog czy AUTOSARowe normy
np. do bilbliotek/APIs, ale czesc tyczaca C/C++ zwyczajnie przyprawia
o wymioty... :(

AK

On Monday, September 2, 2019 at 9:33:41 PM UTC+2, AK wrote:
> On 2019-09-02 14:16, Maciej Sobczak wrote:
> >>> Tak, zgadza się. Trzeba być jeszcze bardziej (!) rygorystycznym.
> >>
> >> Hehe. Smiechu warte.
> > 
> > O, fajna dyskusja będzie. Dlaczego śmiechu warte?
> > 
> > Zanim się rozpędzisz, mały hint: nie napisałem, że takich reguł powinno być jeszcze więcej, albo że funkcje powinny być jeszcze krótsze. Ale nadal twierdzę, że trzeba być bardziej jeszcze bardziej rygorystycznym.
> 
> Tak, ale w inny - normalny sposob (wyjasnien nizej).
> 
> > No więc dlaczego śmiechu warte?
> 
> Dlatego, że zamiast dopracować "nowy" język programowania typu "safety"
> (niech to nawet będzie Misra-C/C++, ale jako _jezyk_ a nie zwykle
> chore C/C++ z setkami reguł ktore rudno zpamietac, a co dopiero stosowac
> (wiem wiem, Parasofty itp super na tym syfie zarabiaja:), albo po prostu
> "odkurzyć" i ulepszyć Adę - czy nawet Modulę2 (tak tak wiem - M2 to
> bardziej real-time niz safety) to na siłę trzyma się tych C/C++ czyli
> języków _skrajnie_ nie nadających się do tzw. "bezpiecznego"
> programowania.
> 
> PS: Oczywiscie wiem ze Misra(y) to nie tylko j.prog czy AUTOSARowe normy
> np. do bilbliotek/APIs, ale czesc tyczaca C/C++ zwyczajnie przyprawia
> o wymioty... :(

Moim zdaniem dobry C++ w rękach dobrego (niekoniecznie bardzo dobrego)
programisty od jakiegoś czasu już nadaje się do bezpiecznego 
programowania.

Pozdrawiam

> Dlatego, że zamiast dopracować "nowy" język programowania typu "safety"

Uniwersytety robią to w tempie 3 języki na rok. Nic z tego. To tak nie działa.

> (niech to nawet będzie Misra-C/C++, ale jako _jezyk_ a nie zwykle
> chore C/C++ z setkami reguł ktore rudno zpamietac, a co dopiero stosowac
> (wiem wiem, Parasofty itp super na tym syfie zarabiaja:), albo po prostu
> "odkurzyć" i ulepszyć Adę - czy nawet Modulę2 (tak tak wiem - M2 to
> bardziej real-time niz safety) to na siłę trzyma się tych C/C++ czyli
> języków _skrajnie_ nie nadających się do tzw. "bezpiecznego"
> programowania.

Masz rację. Ale problem polega na tym, że to właśnie programiści (ogólnie: przemysł) trzymają się tych języków. Przemysł jest zdumimewająco odporny na zmiany w tej dziedzinie, więc jedyne, co można przemysłowi zaproponować, to dokręcanie śruby na tym, co mają. Dlatego powstają standardy kodowania.

I bez przesady z tymi regułami, których się nie da zapamiętać. Wystarczy zrozumimeć, skąd się wzięły, wtedy nie trzeba ich już pamiętać, bo ich stosowanie staje się naturalne. Naprawdę, musisz pamiętać regułę o niestosowaniu goto, żeby nie stosować? Ja nie stosowałem zanim się dowiedziałem, że jest taka reguła gdzieś w jakimś standardzie.

Natomiast prawdą jest też, że są reguły, które faktycznie nie pasują do rzeczywistości. Mnie na tej liście uderzyła reguła, że w kodzie ma być ileś tam assertów. Nie mniej i nie więcej, tylko ileś tam. Bzdura jakaś.
Na szczęście MISRA nie ma takiej reguły. Ani w AUTOSAR. I to też pokazuje, że NASA nie jest wcale wyznacznikiem najlepszej praktyki. Albo ten blog jest od czapy, to też możliwe.

> PS: Oczywiscie wiem ze Misra(y) to nie tylko j.prog czy AUTOSARowe normy
> np. do bilbliotek/APIs, ale czesc tyczaca C/C++ zwyczajnie przyprawia
> o wymioty... :(

Przemysł ma inne zdanie. Nie da się zakazać używania języka C.
I nawet chyba nie należy. Lepiej dać ludziom wytyczne, jakie cele jakościowe mają osiągnąć i niech sobie sami wybiorą, czym je będą osiągać. To jest pole dla konkurencji - tzn. jeśli potrafisz te cele osiągnąć taniej, niż konkurencja używająca języka C, to Twój zysk.
Tylko jakoś nikt się nie wychyla i dalej wszyscy "konkurują" robiąc wszystko tak samo, jak reszta.

-- 
Maciej Sobczak * http://www.inspirel.com

On Tue, 3 Sep 2019 01:58:01 -0700 (PDT), Maciej Sobczak wrote:

> Natomiast prawdą jest też, że są reguły, które faktycznie nie pasują do
> rzeczywistości. Mnie na tej liście uderzyła reguła, że w kodzie ma być
> ileś tam assertów. Nie mniej i nie więcej, tylko ileś tam. Bzdura jakaś.
> Na szczęście MISRA nie ma takiej reguły. Ani w AUTOSAR. I to też
> pokazuje, że NASA nie jest wcale wyznacznikiem najlepszej praktyki. Albo
> ten blog jest od czapy, to też możliwe.

Z asercjami nie jest napisane, że ni mniej ni więcej niż 2, tylko że co
najmniej dwie na funkcję, czyli nie ma górnego limitu.
Inna sprawa, że to pełnej sensowności tej regule nie nadaje.

-- 
pozdrawiam
Roman Tyczka

On 2019-09-03 09:42, M.M. wrote:
> Moim zdaniem dobry C++ w rękach dobrego (niekoniecznie bardzo dobrego)
> programisty od jakiegoś czasu już nadaje się do bezpiecznego
> programowania.

Zwyczajnie bzdużysz/mylisz się o 180st.

AK

> Z asercjami nie jest napisane, że ni mniej ni więcej niż 2, tylko że co
> najmniej dwie na funkcję, czyli nie ma górnego limitu.
> Inna sprawa, że to pełnej sensowności tej regule nie nadaje.

Tak. Można stwierdzić, że w ogóle nie powinno być żadnych asercji w kodzie programu, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli. Nawet jeśli przyjmiemy założenie, że źle działający program należy zabić na miejscu, to nie można obowiązku zabijania nałożyć na ten sam program, o którym właśnie mówimy, że źle działa. To jest bez sensu. Monitor/strażnik, jeśli już, musi być niezależnym bytem.

To, że MISRA-C i AUTOSAR nawet nie wspominają o asercjach nie jest przypadkiem. A to, że AUROSAR wspomina o static_assert też nie jest przypadkiem, bo wykrycie czegoś w czasie kompilacji, czyli przed uruchomieniem, akurat ma sens.

Więc zalecanie, żeby funkcja miała co najmniej dwie asercje, to jakaś pomyłka.

-- 
Maciej Sobczak * http://www.inspirel.com

W dniu wtorek, 3 września 2019 20:49:52 UTC+2 użytkownik Maciej Sobczak napisał:
> > Z asercjami nie jest napisane, że ni mniej ni więcej niż 2, tylko że co
> > najmniej dwie na funkcję, czyli nie ma górnego limitu.
> > Inna sprawa, że to pełnej sensowności tej regule nie nadaje.
> 
> Tak. Można stwierdzić, że w ogóle nie powinno być żadnych asercji w kodzie programu, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli. 

Co za bzdura.

Równie dobrze mógłbyś powiedzieć, że w kodzie programu nie powinno być żadnych komentarzy, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.

Albo że funkcje i zmienne mogą być nazwane byle jak, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.

Wygląda na to, że wśród programistów szeroko jest rozpowszechnione błędne przekonanie, że asercja to "sprawdzenie czegoś w runtimie".

> > Tak. Można stwierdzić, że w ogóle nie powinno być żadnych asercji w kodzie programu, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli. 
> 
> Co za bzdura.
> 
> Równie dobrze mógłbyś powiedzieć, że w kodzie programu nie powinno być żadnych komentarzy, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.

Ale nie równie dobrze, bo komentarze są pożyteczne.
Natomiast asercje to tzw. dead code. Z założenia. To jest kod źródłowy, który pozostawia ślad w kodzie maszynowym, ale którego nie da się pokryć testami. Taki kod jest zabroniony w procesach krytycznych. I tyle.

Powtórzę dla skupienia: MISRA-C i AUTOSAR w ogóle nie poruszają tematu asercji. Co biorąc pod uwagę ilość innych rzeczy, które poruszają, jest co najmniej interesujące.
Otóż rozwiązanie tej zagadki jest bardzo proste: w kodzie krytycznym asercji się nie używa. Bo one stoją w konflikcie z innymi celami, które należy osiągnąć.

> Albo że funkcje i zmienne mogą być nazwane byle jak, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.

Dryfujesz. Komentarze i nazwy są istotne dla czytelności. Mogą być nawet istotne dla śladowania (ang. traceability), wiec czasami nawet nie są sprawą wolnej woli kodera.

Bo jest jeszcze taka możliwość, że potraktujesz asercje jak komentarz. To bardzo dobry pomysł, ale komentarze piszemy w komentarzach.

> Wygląda na to, że wśród programistów szeroko jest rozpowszechnione błędne przekonanie, że asercja to "sprawdzenie czegoś w runtimie".

Dla pewności sprawdziłem jak to opisuje standard C. Otóż właśnie dokładnie tak.

Oczywiście możesz sobie wyobrazić (albo nawet mieć) narzędzie, któro statycznie skanuje kod i sprawdza asercje (efektywnie traktując je jako static_assert), ale takie narzędzie potrafi też wyłuskać adnotacje z komentarzy. Więc nadal twierdzę, że te asercje nie powinny być w kodzie.

Natomiast ja chętnie stosuję asercje w skryptach testowych. Nie chce mi się używać wydumanych frameworków do unit testów a w testach asercje pasują idealnie.
Ale nie w kodzie.

-- 
Maciej Sobczak * http://www.inspirel.com

W dniu środa, 4 września 2019 09:31:05 UTC+2 użytkownik Maciej Sobczak napisał:
> > > Tak. Można stwierdzić, że w ogóle nie powinno być żadnych asercji w kodzie programu, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli. 
> > 
> > Co za bzdura.
> > 
> > Równie dobrze mógłbyś powiedzieć, że w kodzie programu nie powinno być żadnych komentarzy, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.
> 
> Ale nie równie dobrze, bo komentarze są pożyteczne.

Asercje też są pożyteczne.
Asercje są formą komentarza, który dodatkowo można zweryfikować.

> Natomiast asercje to tzw. dead code. Z założenia. To jest kod źródłowy, który pozostawia ślad w kodzie maszynowym, ale którego nie da się pokryć testami.

Asercja to postawa propozycjonalna.
Możesz sobie napisać
#define assert(x) do {} while(0)
i nie masz śladu w kodzie maszynowym.

> Powtórzę dla skupienia: MISRA-C i AUTOSAR w ogóle nie poruszają tematu asercji. Co biorąc pod uwagę ilość innych rzeczy, które poruszają, jest co najmniej interesujące.
> Otóż rozwiązanie tej zagadki jest bardzo proste: w kodzie krytycznym asercji się nie używa. Bo one stoją w konflikcie z innymi celami, które należy osiągnąć.
> 
> > Albo że funkcje i zmienne mogą być nazwane byle jak, bo w systemie krytycznym one nie pełnią tam żadnej sensownej roli.
> 
> Dryfujesz. Komentarze i nazwy są istotne dla czytelności.

Asercje też są istotne dla czytelności.
Po to, żeby programista wiedział:
"aha, ten a ten warunek jest (ma być) tutaj spełniony."
Co może być przydatne przy rozumieniu kodu, jego refaktoryzacji i debugowaniu.

> Bo jest jeszcze taka możliwość, że potraktujesz asercje jak komentarz. To bardzo dobry pomysł, ale komentarze piszemy w komentarzach.

Co jest kiepskim pomysłem, bo błędnego komentarza nie wykryjesz za pomocą narzędzia, a błędną asercję możesz.

> > Wygląda na to, że wśród programistów szeroko jest rozpowszechnione błędne przekonanie, że asercja to "sprawdzenie czegoś w runtimie".
> 
> Dla pewności sprawdziłem jak to opisuje standard C. Otóż właśnie dokładnie tak.

Asercja nie jest pojęciem wprowadzonym przez standard C.

> Oczywiście możesz sobie wyobrazić (albo nawet mieć) narzędzie, któro statycznie skanuje kod i sprawdza asercje (efektywnie traktując je jako static_assert), ale takie narzędzie potrafi też wyłuskać adnotacje z komentarzy. 

?

> Więc nadal twierdzę, że te asercje nie powinny być w kodzie.

No to nie dość, że sam błędnie rozumiesz, to jeszcze próbujesz to swoje błędne rozumienie promować.

> Natomiast ja chętnie stosuję asercje w skryptach testowych. Nie chce mi się używać wydumanych frameworków do unit testów a w testach asercje pasują idealnie.
> Ale nie w kodzie.

A skrypty testowe to nie kod?

On Friday, August 30, 2019 at 9:20:11 AM UTC+2, Mateusz Viste wrote:
> On Fri, 30 Aug 2019 09:09:43 +0200, Roman Tyczka wrote:
> > https://fossbytes.com/nasa-coding-programming-rules-critical/
> 
> To raczej ciekawostka, bo do normalnego życia ma się nijak - NASA to 
> jednak dewianci są. :)
> 
> "Do not use goto"

To jest zalecenie wydane przez Dijkstrę w epoce fortrana łupanego. 
Podstawa programowania strukturalnego i pochodnych.

> "No function longer than 60 lines of code"

Akurat dość dobre, z gatunku czytelności kodu. 
Jesne, jeśli akurat wyjdzie 70 linii niepodzielnego kodu
(jakaś procedura numeryczna) to nie jest to zbrodnia. 

> "Do not use dynamic memory"

"... after inicjaization". Możesz zaalokować tyle, ile trzeba. 
Nie baw się jednak np w dynamicznei rosnącą tablicę.  

To jest specyfika dziedziny. Dość częste zalecenie tam, 
gdzie rzeczy mają być niezawodne, wiec deterministyczne. 
Ale tylko do tych specjalistycznych zastosowań. 

> Żadne z powyższych do mnie nie przemawia, ale oczywiście gdybym pisał 
> programy sterujące rakietami ziemia-jupiter to na pewno też miałbym 
> stracha.

Ogolnie, wszystkie zalecenia to albo estetyka, albo ograniczenie
dostępnych klocków, aby bylo prościej. 
Dziwi mnie rekurencja wsadzona w wzięte z assembleera setjump i longjump.
O ile te ostatenie, razem z goto psują programowania strukturalne,
utrudniają analizę kodu i są zwalczane od kilkudziesiaciu lat,
to co tam robi rekurencja. 
Jesne, rozumiem związane z nią "zagrożenia", na poziomie, gdzie wymagają
dowodliwego ograniczenie na liczbę obrotów pętli, można się bać nieskończonej
rekursji czy skonczenia stosu. Ale to inna kategoria niż goto;-)
Wywalenie rekurencji pośrednio  mocno ogranicza dostępne struktury danych.
Drzewa pisze się znacznie gorzej. Ale znow, to do krytycznych fragmentow 
kodu.


pzdr
bartekltg

AK <nobody@nowhere.net> Wrote in message:
> On 2019-08-30 19:21, Wojciech Muła wrote:> On Friday, August 30, 2019 at 9:10:03 AM UTC+2, Roman Tyczka wrote:>> https://fossbytes.com/nasa-coding-programming-rules-critical/> > Bardzo polecam ten artykuł: https://www.fastcompany.com/28121/they-write-right-stuff> > BTW "All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting." używamy, polecam (-Werror jest, wbrew pozorom, wicej niż korzystne)Eee... Co to są compile warnings? Znam tylko compile errors :(Slowem b.dobra zasada.AK

I tak, i nie.

Nigdy nie zrozumiem dlaczego MS walczy z POSIX i np. utrudnia 
 używanie kbhit(), uważając że tylko _kbhit() jest
 koszerne.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

On 2019-09-04 17:38, slawek wrote:
> I tak, i nie.
> 
> Nigdy nie zrozumiem dlaczego MS walczy z POSIX i np. utrudnia
>   używanie kbhit(), uważając że tylko _kbhit() jest
>   koszerne.

Bo tak (niestety) nakazuje ANSI.
Od zawsze ANSI jest w konflikcie z Posix.
PS: Np. Borland trzymal sie bardziej Posix (kbhit), a MS od pewnego
     (b.dawnego) czasu bardziej ANSI.

AK

> Asercje są formą komentarza, który dodatkowo można zweryfikować.

Kupa różnych narzędzi weryfikuje adnotacje zaszyte w komentarzach. Statycznie. I tak powinno być.

> Asercja to postawa propozycjonalna.

Możliwe, że pomyliłeś grupy.

> Możesz sobie napisać
> #define assert(x) do {} while(0)

Nie, nie mogę. Zabrania tego zarówno MISRA-C jak i AUTOSAR.
Byłoby łatwiej, gdybyś nie spekulował.

> Asercje też są istotne dla czytelności.

Oczywiście. Ale stanowią dead-code, którego się unika z innych powodów. Być może te powody nie są istotne jak się pisze coś innego gdzieś indziej, ale jeśli mówimy o systemach krytycznych (taki wątek się zrobił), to obowiązują pewne reguły. Dużo reguł. Więcej, niż gdzie indziej. W sumie właśnie od tego spostrzeżenia się ta dyskusja wzięła.

> Asercja nie jest pojęciem wprowadzonym przez standard C.

Standard C definiuje dokładnie, co to pojęcie oznacza w języku C. Może gdzieś indziej oznacza coś innego, albo nawet wcześniej. Nie ma to znaczenia.

> > Oczywiście możesz sobie wyobrazić (albo nawet mieć) narzędzie, któro statycznie skanuje kod i sprawdza asercje (efektywnie traktując je jako static_assert), ale takie narzędzie potrafi też wyłuskać adnotacje z komentarzy. 
> 
> ?

Ale czego nie rozumiesz? Której części?

> No to nie dość, że sam błędnie rozumiesz, to jeszcze próbujesz to swoje błędne rozumienie promować.

Dopóki moje rozumienie opiera się na standardach (i to kilku), to będę je promował. Nie do mnie pretensje, nie ja te standardy pisałem.

> A skrypty testowe to nie kod?

Nie musi być. Może to być procedura opisana słownie. Np. w Wordzie. Nie, nie nabijam się. Nieprzypadkiem napisałem wcześniej, że w tej branży klepanie kodu to tylko kilka procent wysiłku.
Natomiast nawet jeśli skrypt testowy będzie kodem w jakimś języku programowania, nawet w tym samym (rzadki przypadek), to tego kodu nie obowiązują takie reguły, jak te dotyczące właściwego kodu programu. Bo i po co.
Dlatego współcześnie popularnym przypadkiem jest użycie Pythona do pisania testów. Tam sobie możesz (a nawet powinieneś) robić asercje ile wlezie.

-- 
Maciej Sobczak * http://www.inspirel.com

W dniu środa, 4 września 2019 23:49:50 UTC+2 użytkownik Maciej Sobczak napisał:
> > Asercje są formą komentarza, który dodatkowo można zweryfikować.
> 
> Kupa różnych narzędzi weryfikuje adnotacje zaszyte w komentarzach. Statycznie. I tak powinno być.

Dlaczego? Bo właśnie do tego służą komentarze?
Jeżeli tak jest, to to wynika co najwyżej z tego, że macierzysty język jest zbyt słaby, żeby wyrazić te rzeczy, które są istotne (i które weryfikują narzędzia, o których mówisz). I dlatego używa się komentarzy jako takiego "haka" na wyrażanie tych rzeczy.
Bo, jak wskazuje nazwa, komentarze służą do komentowania.

A do stwierdzania faktów służą... stwierdzenia.
(Możesz też poszukać synonimów tego słowa. Wśród nich znajdziesz ...)

> > Asercja to postawa propozycjonalna.
> 
> Możliwe, że pomyliłeś grupy.

Hmm. Nazwa grupy zaczyna się od "pl". Jestem raczej przekonany, że to skrót od "polski" i że sugeruje, że używamy tu znaczeń słów takich, jakie mają w języku polskim.

Słowo "asercja" można nawet znaleźć w Słowniku Języka Polskiego, jeśli komuś chce się szukać.

> > Możesz sobie napisać
> > #define assert(x) do {} while(0)
> 
> Nie, nie mogę. Zabrania tego zarówno MISRA-C jak i AUTOSAR.
> Byłoby łatwiej, gdybyś nie spekulował.

Zabawne to, co mówisz. Zamiast powiedzieć, na przykład:

"nie mogę, bo MISRA C zabrania używania identyfikatorów, które pojawiają się w bibliotece standardowej języka C"

wolisz powiedzieć:

"byłoby łatwiej, gdybyś nie spekulował"

Jakby to faktycznie mogło przybliżyć do rozwiązania jakiegokolwiek problemu.

I otóż, jak napisał powyżej kolega, który przedstawił mi się jako "Pier..lisz Głupoty" (śmieszne nazwisko, swoją drogą), możesz zdefiniować symbol NDEBUG przed załączeniem assert.h.

Albo możesz np. zdefiniować

#define certainly(x) do{}while(0)

Wyjdzie w sumie na to samo.

> > Asercje też są istotne dla czytelności.
> 
> Oczywiście. Ale stanowią dead-code, którego się unika z innych powodów.

Asercje nie stanowią martwego kodu.
Być może strategia obsługi fałszywych asercji, którą przyjmuje biblioteka C (bez NDEBUG) generuje w jakichś okolicznościach martwy kod.

> Być może te powody nie są istotne jak się pisze coś innego gdzieś indziej, ale jeśli mówimy o systemach krytycznych (taki wątek się zrobił), to obowiązują pewne reguły. Dużo reguł. Więcej, niż gdzie indziej. W sumie właśnie od tego spostrzeżenia się ta dyskusja wzięła.
> 
> > Asercja nie jest pojęciem wprowadzonym przez standard C.
> 
> Standard C definiuje dokładnie, co to pojęcie oznacza w języku C. Może gdzieś indziej oznacza coś innego, albo nawet wcześniej. Nie ma to znaczenia.

Standard C mówi wyłącznie, w jaki sposób jest zdefiniowane makro "assert".
Nie mówi nic o tym, co oznacza słowo "asercja".

> > > Oczywiście możesz sobie wyobrazić (albo nawet mieć) narzędzie, któro statycznie skanuje kod i sprawdza asercje (efektywnie traktując je jako static_assert), ale takie narzędzie potrafi też wyłuskać adnotacje z komentarzy. 
> > 
> > ?
> 
> Ale czego nie rozumiesz? Której części?

Dajmy na to, że mam taki komentarz:

/* wartośc poniższego enuma służą jako indeksy do tablicy TABLICA */

po którym następuje enum.

I teraz, czy narzędzie sprawdzi mi, czy wartości tego enuma służą jako indeksy do tablicy TABLICA?

> > No to nie dość, że sam błędnie rozumiesz, to jeszcze próbujesz to swoje błędne rozumienie promować.
> 
> Dopóki moje rozumienie opiera się na standardach (i to kilku), to będę je promował. Nie do mnie pretensje, nie ja te standardy pisałem.

Nie wiem, jakie standardy czytałeś, ale jeżeli idzie o te, z którymi ja miałem styczność, to żadna nie rościła sobie pretensji do bycia normatywną w kwestii pojęcia asercji.

> > Kupa różnych narzędzi weryfikuje adnotacje zaszyte w komentarzach. Statycznie. I tak powinno być.
> 
> Dlaczego? Bo właśnie do tego służą komentarze?

Powinno być statycznie.
Natomiast komentarze pozwalają "rozszerzyć" język bez ingerowania w kompilator.

> Jeżeli tak jest, to to wynika co najwyżej z tego, że macierzysty język jest zbyt słaby, żeby wyrazić te rzeczy, które są istotne (i które weryfikują narzędzia, o których mówisz). I dlatego używa się komentarzy jako takiego "haka" na wyrażanie tych rzeczy.

Tak. Tak właśnie jest.
Język C jest słaby, więc używa się jego rozszerzeń w komentarzach, żeby wesprzeć jego weryfikację. Zaletą takiego działania jest transparentność względem kompilatora.

> Słowo "asercja" można nawet znaleźć w Słowniku Języka Polskiego, jeśli komuś chce się szukać.

Ale dryfujesz. Napisałem już kilka razy, dlaczego asercji się nie używa a Ty grzebiesz w SJP, żeby... no właśnie nie wiem po co.

> możesz zdefiniować symbol NDEBUG przed załączeniem assert.h.

I w czym mi to pomoże?
Kod, który załaduję na produkcyjne urządzenie musi być *tym samym* kodem, który przetestowałem, co do bitu. Nie ma opcji, żebym zrobił inaczej. Więc ten NDEBUG musiałbym mieć zdefiniowany również w czasie testów.
To na cholerę mi takie asercje?

> Albo możesz np. zdefiniować
> 
> #define certainly(x) do{}while(0)
> 
> Wyjdzie w sumie na to samo.

Mógłbym. Ale po co miałbym definiować makro, któro nic nie robi?

> Asercje nie stanowią martwego kodu.

One są martwe z założenia. Nigdy się nie wykonują, więc są martwe.

> Standard C mówi wyłącznie, w jaki sposób jest zdefiniowane makro "assert".
> Nie mówi nic o tym, co oznacza słowo "asercja".

Dalej nie kumasz. Asercji nie używa się, bo stoją w konflikcie z innymi celami procesów krytycznych. Twoje własne asercje też takie będą, nawet jeśli je będziesz pisał na podstawie SJP.

> Dajmy na to, że mam taki komentarz:
> 
> /* wartośc poniższego enuma służą jako indeksy do tablicy TABLICA */
> 
> po którym następuje enum.
> 
> I teraz, czy narzędzie sprawdzi mi, czy wartości tego enuma służą jako indeksy do tablicy TABLICA?

Jeśli masz takie narzędzie, to sprawdzi.
Czego tu nie rozumiesz?

Przewiń sobie tą stronę i popatrz na komentarze w przykładach:

https://frama-c.com/acsl_tutorial_index.html

> Nie wiem, jakie standardy czytałeś, ale jeżeli idzie o te, z którymi ja miałem styczność, to żadna nie rościła sobie pretensji do bycia normatywną w kwestii pojęcia asercji.

Wniosek jest taki, że czytaliśmy różne standardy.

-- 
Maciej Sobczak * http://www.inspirel.com

W dniu piątek, 6 września 2019 21:25:18 UTC+2 użytkownik Maciej Sobczak napisał:
> > > Kupa różnych narzędzi weryfikuje adnotacje zaszyte w komentarzach. Statycznie. I tak powinno być.
> > 
> > Dlaczego? Bo właśnie do tego służą komentarze?
> 
> Powinno być statycznie.
> Natomiast komentarze pozwalają "rozszerzyć" język bez ingerowania w kompilator.

Dla ścisłości, formalne wyrażenia zaszyte w komentarzach.
Czyli drugi 'język programowania'. Tylko pewnie z gorszym wsparciem narzędzi.

> > Jeżeli tak jest, to to wynika co najwyżej z tego, że macierzysty język jest zbyt słaby, żeby wyrazić te rzeczy, które są istotne (i które weryfikują narzędzia, o których mówisz). I dlatego używa się komentarzy jako takiego "haka" na wyrażanie tych rzeczy.
> 
> Tak. Tak właśnie jest.
> Język C jest słaby, więc używa się jego rozszerzeń w komentarzach, żeby wesprzeć jego weryfikację. Zaletą takiego działania jest transparentność względem kompilatora.
> 
> > Słowo "asercja" można nawet znaleźć w Słowniku Języka Polskiego, jeśli komuś chce się szukać.
> 
> Ale dryfujesz. Napisałem już kilka razy, dlaczego asercji się nie używa a Ty grzebiesz w SJP, żeby... no właśnie nie wiem po co.

No bo błędnie napisałeś.

> > możesz zdefiniować symbol NDEBUG przed załączeniem assert.h.
> 
> I w czym mi to pomoże?
> Kod, który załaduję na produkcyjne urządzenie musi być *tym samym* kodem, który przetestowałem, co do bitu. Nie ma opcji, żebym zrobił inaczej. Więc ten NDEBUG musiałbym mieć zdefiniowany również w czasie testów.
> To na cholerę mi takie asercje?

Bo po pierwsze, możesz je inaczej interpretować poza swoim procesem.
Po drugie, możesz pewne rzeczy wyrazić w tym samym języku, w którym piszesz program. Po trzecie, na cholerę Ci komentarze? Po czwarte, tak jak masz narzędzia, które parsują formalny język w komentarzach, to mogłyby też tak samo parsować i statycznie weryfikować asercje - bo czemu nie?

> > Albo możesz np. zdefiniować
> > 
> > #define certainly(x) do{}while(0)
> > 
> > Wyjdzie w sumie na to samo.
> 
> Mógłbym. Ale po co miałbym definiować makro, któro nic nie robi?

Po co pisać komentarz, który nic nie robi?

> > Asercje nie stanowią martwego kodu.
> 
> One są martwe z założenia. Nigdy się nie wykonują, więc są martwe.
> 
> > Standard C mówi wyłącznie, w jaki sposób jest zdefiniowane makro "assert".
> > Nie mówi nic o tym, co oznacza słowo "asercja".
> 
> Dalej nie kumasz. Asercji nie używa się, bo stoją w konflikcie z innymi celami procesów krytycznych. Twoje własne asercje też takie będą, nawet jeśli je będziesz pisał na podstawie SJP.
> 
> > Dajmy na to, że mam taki komentarz:
> > 
> > /* wartośc poniższego enuma służą jako indeksy do tablicy TABLICA */
> > 
> > po którym następuje enum.
> > 
> > I teraz, czy narzędzie sprawdzi mi, czy wartości tego enuma służą jako indeksy do tablicy TABLICA?
> 
> Jeśli masz takie narzędzie, to sprawdzi.

Nie mam takiego narzędzia.

> Czego tu nie rozumiesz?

Nie rozumiem w jaki sposób magiczne narzędzia mają nagle czytać moje komentarze ze zrozumieniem. W komentarzach mogę pisać cokolwiek. Jak narzędzie mi sprawdzi, że nie kłamię?

> Przewiń sobie tą stronę i popatrz na komentarze w przykładach:
> 
> https://frama-c.com/acsl_tutorial_index.html

No to wygląda mi na takie rzeczy, które mogę wyrazić w asercjach.

> > Nie wiem, jakie standardy czytałeś, ale jeżeli idzie o te, z którymi ja miałem styczność, to żadna nie rościła sobie pretensji do bycia normatywną w kwestii pojęcia asercji.
> 
> Wniosek jest taki, że czytaliśmy różne standardy.

No to dajesz cytaty.

> > Napisałem już kilka razy, dlaczego asercji się nie używa a Ty grzebiesz w SJP, żeby... no właśnie nie wiem po co.
> 
> No bo błędnie napisałeś.

W jakim sensie błędnie? W takim, że się ich używa?

> > To na cholerę mi takie asercje?
> 
> Bo po pierwsze, możesz je inaczej interpretować poza swoim procesem.

Nie rozumiesz. Nie ma rzeczy poza moim procesem. I nawet nie chodzi o to, że nikt mi za nie nie zapłaci. Chodzi wręcz o to, że ze względów zrozumiałych bardziej dla prawników, niż inżynierów, rzeczy poza procesem są zabronione.

> Po co pisać komentarz, który nic nie robi?

Komentarz nie jest dead-codem. To właśnie ten aspekt sprawia, że asercji się nie używa.

> > > I teraz, czy narzędzie sprawdzi mi, czy wartości tego enuma służą jako indeksy do tablicy TABLICA?
> > 
> > Jeśli masz takie narzędzie, to sprawdzi.
> 
> Nie mam takiego narzędzia.

Spodziewałem się. Ale powinieneś rozumieć, że takie narzędzie można mieć. I ten fakt sprawia, że z takimi argumentami oddalasz się od jakkolwiek rozumianego sukcesu w tej dyskusji.

> W komentarzach mogę pisać cokolwiek.

Dalej nie rozumiesz. Za pisanie czegokolwiek wylatuje się z pracy.
Ale jak napiszesz coś mądrego, to co innego.

> Jak narzędzie mi sprawdzi, że nie kłamię?

Czyli nie zajrzałeś do tego linka, którego podałem do Frama-C. Szkoda.

> > https://frama-c.com/acsl_tutorial_index.html
> 
> No to wygląda mi na takie rzeczy, które mogę wyrazić w asercjach.

Jednak zajrzałeś. Ale nie zrozumiałeś. Tych rzeczy nie da się wyrazić w asercjach języka C - stąd pomysł na taki produkt. Ktoś tego nawet używa.
Być może w innym (hipotetycznym?) języku można by było to mieć w asercjach i bez dodatkowego narzędzia, ale jakoś ten język nie robi furory w tej branży. Więc jest tak, jak pokazałem.

> > Wniosek jest taki, że czytaliśmy różne standardy.
> 
> No to dajesz cytaty.

Czyli nawet w tej warstwie nic nie rozumiesz.
Cytowanie tych standardów jest zabronione. Prawa autorskie i takie tam.

Mógłbym ewentualnie podać numer paragrafu, to jest dozwolone. Ale wtedy musiałbyś sam sobie to otworzyć i przeczytać. No, ale skoro możesz sam otworzyć i przeczytać, to po co mam dawać cytaty? Ctrl-F, "assert", Enter.

No i serio - o co teraz walczysz, tak konkretnie?

-- 
Maciej Sobczak * http://www.inspirel.com

W dniu sobota, 7 września 2019 17:21:32 UTC+2 użytkownik Maciej Sobczak napisał:
> > > Napisałem już kilka razy, dlaczego asercji się nie używa a Ty grzebiesz w SJP, żeby... no właśnie nie wiem po co.
> > 
> > No bo błędnie napisałeś.
> 
> W jakim sensie błędnie? W takim, że się ich używa?

W takim sensie, jak pisałem na początku.
Czyli odnośnie tego, czym jest asercja w ogóle.
Asercja to uznanie jakiegoś sądu za prawdziwy. Oto znaczenie tego słowa.
Niekiedy tym słowem określa się ślad, jakiego dokonujemy, uznając dany sąd za prawdziwy -- na przykład jeśli w kodzie źródłowym napiszemy

assert(jakiś_sąd)

to takie wyrażenie określamy mianem asercji (ale określamy w sposób metonimiczny).
Natomiast to, że w języku C assert to makro, i że owo makro w pewnych okolicznościach będzie generowało kod sprawdzający prawdziwość owego sądu i w przypadku negatywnego wyniku powodowało wywalenie programu, nie jest asercją.
Pewnie można to nazwać "pewną strategią obsługi asercji fałszu", ale to już się nie mieści w znaczeniu słowa "asercja".

> > > To na cholerę mi takie asercje?
> > 
> > Bo po pierwsze, możesz je inaczej interpretować poza swoim procesem.
> 
> Nie rozumiesz. Nie ma rzeczy poza moim procesem. I nawet nie chodzi o to, że nikt mi za nie nie zapłaci. Chodzi wręcz o to, że ze względów zrozumiałych bardziej dla prawników, niż inżynierów, rzeczy poza procesem są zabronione.

Jest bardzo dużo rzeczy poza Twoim procesem.
Na przykład całe Twoje wcześniejsze doświadczenie.

> > Po co pisać komentarz, który nic nie robi?
> 
> Komentarz nie jest dead-codem. To właśnie ten aspekt sprawia, że asercji się nie używa.

Asercja też nie jest dead-codem. W szczególności jak skompilujesz z -DNDEBUG, to nie jest żadnym kodem.

> > W komentarzach mogę pisać cokolwiek.
> 
> Dalej nie rozumiesz. Za pisanie czegokolwiek wylatuje się z pracy.
> Ale jak napiszesz coś mądrego, to co innego.

Z reguły to nie tak wygląda.
Raczej jest tak, że programista napisze relewantny komentarz, potem inny programista zrefaktoryzuje kod, ale zapomni o aktualizacji komentarza, i komentarz przestaje być relewantny.

> > Jak narzędzie mi sprawdzi, że nie kłamię?
> 
> Czyli nie zajrzałeś do tego linka, którego podałem do Frama-C. Szkoda.
> 
> > > https://frama-c.com/acsl_tutorial_index.html
> > 
> > No to wygląda mi na takie rzeczy, które mogę wyrazić w asercjach.
> 
> Jednak zajrzałeś. Ale nie zrozumiałeś. Tych rzeczy nie da się wyrazić w asercjach języka C

No to spróbujmy pierwszy przykład:

/*@ ensures \result >= x && \result >= y; 
    ensures \result == x || \result == y; 
*/ 
int max (int x, int y) { return (x > y) ? x : y; } 

int max (int x, int y) {
  int result = (x > y) ? x : y;
  assert(result >= x && result >= y);
  assert(result == x || result == y);
  return result;
}

Udało się.

> Ktoś tego nawet używa.
> Być może w innym (hipotetycznym?) języku można by było to mieć w asercjach i bez dodatkowego narzędzia, ale jakoś ten język nie robi furory w tej branży. Więc jest tak, jak pokazałem.
> 
> > > Wniosek jest taki, że czytaliśmy różne standardy.
> > 
> > No to dajesz cytaty.
> 
> Czyli nawet w tej warstwie nic nie rozumiesz.
> Cytowanie tych standardów jest zabronione. Prawa autorskie i takie tam.

,,Czy możemy w swoich pracach korzystać z fragmentów cudzych utworów, a w przypadku roszczeń zasłaniać się dozwolonym użytkiem? Odpowiedź jest prosta i brzmi: tak, jeżeli wykorzystanie fragmentu cudzego utworu, będzie uzasadnione jednym z celów bezpośrednio wskazanych w treści przepisów – „wyjaśnianie, polemika, analiza krytyczna lub naukowa, nauczanie lub prawa gatunku twórczości.”.''
https://prawo.gazetaprawna.pl/artykuly/1127356,opydo-kontra-uniwersal-cytat-czy-naruszenie-praw-autorskich.html

> Mógłbym ewentualnie podać numer paragrafu, to jest dozwolone. Ale wtedy musiałbyś sam sobie to otworzyć i przeczytać. No, ale skoro możesz sam otworzyć i przeczytać, to po co mam dawać cytaty? Ctrl-F, "assert", Enter.

To podaj chociaż tytuły dokumentów.

Ja zaglądałem tutaj:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

i było w dokumencie kilka użyć słowa "assert" w normalnym angielskim znaczeniu, a poza tym było jedynie wyjaśnienie pewnych charakterystyk definicji makra assert.

> No i serio - o co teraz walczysz, tak konkretnie?

Z błędnym użyciem słowa "asercja".

> > W jakim sensie błędnie? W takim, że się ich używa?
> 
> W takim sensie, jak pisałem na początku.

No to od początku:

1. W kodzie krytycznym nie używa się asercji (w takim sensie, w jakim do tego pojęcia dobrnęliśmy od początku dyskusji[*]), bo
2. w przetestowanym kodzie tworzą dead-code, którego się unika z innych powodów.
3. Przesłanki do tego stwierdzenia widać też w dwóch najpoważniejszych standardach kodowania dla tej branży, które w ogóle nie zajmują się tematem asercji.

[*] Co ja interpretuję jako popularne użycie makra assert. Po ponownej lekturze linka z początku stwierdzam, że nie musiało chodzić o to makro, autorowi mogło chodzić też o inny mechanizm, bo wspominał o wracaniu do wołającej funkcji.

Nie pokałeś niczego, co by zaprzeczało tym stwierdzeniom albo rzucało nową lub inną perspektywę. Zamiast tego przerzucamy się wrażeniami z lektury Słownika Języka Polskiego i innymi zlepkami nie na temat. Nic to nie wnosi do dyskusji o tym, jak się pisze systemy krytyczne.

> > Nie rozumiesz. Nie ma rzeczy poza moim procesem.
> 
> Jest bardzo dużo rzeczy poza Twoim procesem.

W branży krytycznej nie ma.

> Na przykład całe Twoje wcześniejsze doświadczenie.

No właśnie. Nie na temat.

> Raczej jest tak, że programista napisze relewantny komentarz, potem inny programista zrefaktoryzuje kod, ale zapomni o aktualizacji komentarza, i komentarz przestaje być relewantny.

Nie, nie zapomni. W szczególności, to, co nazwałeś "refaktoryzacją" to nie jest coś, co sobie robi "inny programista", bo ma akurat taką inspirację. W szczególności, jeśli komentarze wykorzystywane są w takim celu jak pokazałem (z analizą statyczną), to ewentualne błędy zostaną autmatycznie wykryte.

> ,,Czy możemy w swoich pracach korzystać z fragmentów cudzych utworów,

Nadal nie na temat.

> To podaj chociaż tytuły dokumentów.

Standard języka C, MISRA-C, AUTOSAR. Pisałem już.
I nawet jeśli na siłę wyłuskasz z nich jakieś użycia słowa "assertion" nie na temat, to będą one, no właśnie, nie na temat.

> > No i serio - o co teraz walczysz, tak konkretnie?
> 
> Z błędnym użyciem słowa "asercja".

Rozumiem. Ale mi się nie chce. Wolę dyskutować o programowaniu.

-- 
Maciej Sobczak * http://www.inspirel.com

> No to spróbujmy pierwszy przykład:
> 
> /*@ ensures \result >= x && \result >= y; 
>     ensures \result == x || \result == y; 
> */ 
> int max (int x, int y) { return (x > y) ? x : y; } 
> 
> int max (int x, int y) {
>   int result = (x > y) ? x : y;
>   assert(result >= x && result >= y);
>   assert(result == x || result == y);
>   return result;
> }
> 
> Udało się.

Nie udało się, z czterech powodów.

Po pierwsze, asercje (nazwijmy je raczej warunkami weryfikacji) w tych przykładach są właściwością deklaracji funkcji a nie jej ciała. Oznacza to, że są użyteczne zarówno przy weryfikacji ciała funkcji jak i przy weryfikacji kodu wołającego. Twoje asserty w ciele pełnią tylko tą pierwszą rolę, co je bardzo ogranicza.

Po drugie, warunki w komentarzach, gdzie są analizowane przez zewnętrzne narzędzie, nie podlegają ograniczeniom języka C i mogą korzystać nie tylko z szerszej składni, ale w ogóle z innego paradygmatu.

Po trzecie, na tym *pierwszym* przykładzie kończą się Twoje możliwości w tym zakresie. Niezbyt imponująco. Dalsze przykłady są ciekawsze (co nawiązuje do poprzedniego punktu).

Po czwarte wreszcie, Twoja wersja ma dead code. Mam nadzieję, że to nie wymaga ponownego wyjaśnienia.

-- 
Maciej Sobczak * http://www.inspirel.com

On Sunday, September 8, 2019 at 10:17:20 PM UTC+2, Maciej Sobczak wrote:
> > No to spróbujmy pierwszy przykład:
> > 
> > /*@ ensures \result >= x && \result >= y; 
> >     ensures \result == x || \result == y; 
> > */ 
> > int max (int x, int y) { return (x > y) ? x : y; } 
> > 
> > int max (int x, int y) {
> >   int result = (x > y) ? x : y;
> >   assert(result >= x && result >= y);
> >   assert(result == x || result == y);
> >   return result;
> > }
> > 
> > Udało się.
> 
> Nie udało się, z czterech powodów.
> 
> Po pierwsze, asercje (nazwijmy je raczej warunkami weryfikacji) 

Dlaczego warto wprowadzać takie rozróżnienie nazewnicze, dlaczego nie używać
określenia asercj a warunków weryfikacyjnych?

Pozdrawiam

> > Po pierwsze, asercje (nazwijmy je raczej warunkami weryfikacji) 
> 
> Dlaczego warto wprowadzać takie rozróżnienie nazewnicze, dlaczego nie używać
> określenia asercj a warunków weryfikacyjnych?

Bo określenie "asercja" ma zbyt wiele znaczeń i u niektórych generuje chęć dyskusji nie na temat. :-)

No i termin "verification condition" jest bardziej sexy, niż "assertion" i skupia uwagę na temacie poprawności. Wpisz w Googlu jedno i drugie i porównaj wyniki. Od razu widać, że "verification condition" jest bardziej na temat.
;-)

-- 
Maciej Sobczak * http://www.inspirel.com

On Wednesday, September 11, 2019 at 9:21:07 AM UTC+2, Maciej Sobczak wrote:
> > > Po pierwsze, asercje (nazwijmy je raczej warunkami weryfikacji) 
> > 
> > Dlaczego warto wprowadzać takie rozróżnienie nazewnicze, dlaczego nie używać
> > określenia asercj a warunków weryfikacyjnych?
> 
> Bo określenie "asercja" ma zbyt wiele znaczeń i u niektórych generuje chęć dyskusji nie na temat. :-)
> 
> No i termin "verification condition" jest bardziej sexy, niż "assertion" i skupia uwagę na temacie poprawności. Wpisz w Googlu jedno i drugie i porównaj wyniki. Od razu widać, że "verification condition" jest bardziej na temat.
> ;-)

A konkretnie, co jest na temat a co nie jest i na jaki? Nie wiem co to
jest "verification condition". Verification condition to te adnotacje, a
asercje to te marka/funkcje?

Pozdrawiam

> A konkretnie, co jest na temat a co nie jest i na jaki?

Pół dyskusji w tym wątku było nie na temat tego wątku.

> Nie wiem co to
> jest "verification condition".

To jest coś, co zakładamy[1], że jest prawdą albo co musi być wykazane[2], że jest prawdą, żeby program uznać za poprawny.

[1] Przykładem takiego założenia jest np. zakres wartości typu int. Tego się nie udowadnia, to się przyjmuje i dane z tego założenia są WEjściem dla innych rozważań.
[2] Przykładem takiego warunku jest np. to, co było pokazane dla funkcji max, albo to, że funkcja sortująca faktycznie sortuje albo to, że funkcja abs nigdy nie zwróci wartości ujemnej, itd. Takich rzeczy nie wiemy z góry, ale możemy je wykazać (albo im zaprzeczyć) wnioskując na podstawie informacji, które już znamy.

Fachowo, dowiedzenie, że VC (verification condition) jest spełnione nazywa się "discharge". Ale po polsku najlepiej powiedzieć, że jest "spełnione", bo "rozładowywanie warunków" brzmi głupio. Dowody mogą być automatyczne albo ręczne.

I teraz ciekawostka: asercja napisana przy użyciu makra "assert" może być traktowana jako warunek do wykazania *oraz* jako nowe założenie dla dalszych rozważań. W niektórych językach do tego drugiego celu służy konstrukcja "assume" i stosuje się ją wtedy, kiedy wiedza na jakiś temat pochodzi z zewnątrz - np. z tego, jak i gdzie dany program jest użytkowany.

-- 
Maciej Sobczak * http://www.inspirel.com

On Thursday, September 12, 2019 at 9:21:42 AM UTC+2, Maciej Sobczak wrote:
> > A konkretnie, co jest na temat a co nie jest i na jaki?
> 
> Pół dyskusji w tym wątku było nie na temat tego wątku.
> 
> > Nie wiem co to
> > jest "verification condition".
> 
> To jest coś, co zakładamy[1], że jest prawdą albo co musi być wykazane[2], 
> że jest prawdą, żeby program uznać za poprawny.

Na razie rozumiem, że "verification condition" to jest cokolwiek z czego
prawdziwości wynika poprawność programu, albo czego prawdziwości jest 
tożsama z poprawnością programu. Coś w rodzaju 
X => Y
X <=> Y
Gdzie X to jest poprawny verification condition, a Y oznacza poprawność 
programu. 

Zwykle stosuję słabsze wnioskowanie, np. że z NIE prawdziwości warunków 
testowych wynika że program jest nie poprawny. 

> [1] Przykładem takiego założenia jest np. zakres wartości typu int. Tego się 
> nie udowadnia, to się przyjmuje i dane z tego założenia są WEjściem dla 
> innych rozważań.

Tak, to chyba wynika z prawdziwości zdania "kompilator nie ma błędów".


> [2] Przykładem takiego warunku jest np. to, co było pokazane dla funkcji max, 

Tak, tamto zrozumiałem, choć do składni w adnotacjach bym musiał przywyknąć.


> albo to, że funkcja sortująca faktycznie sortuje albo to, że 
> funkcja abs nigdy nie zwróci wartości ujemnej, itd. 

Abs i sortowanie stanowią stosunkowo łatwe przykłady. Zwykle nie wiem 
jak mam zrobić warunki, gdy mam okienko dialogowe np. z 20ma polami i
piszę parser czy użytkownik nie wpisał blędnych wartości? Czy parser 
przepuści jakiś przypadek błędnych danych wejściowych dla programu? 
Niby sam parser jest takim warunkiem, działa na zasadzie: dane złe, to
warunek je wychwyci.


> Takich rzeczy nie wiemy z góry, ale możemy je wykazać (albo im 
> zaprzeczyć) wnioskując na podstawie informacji, które już znamy.
> 
> Fachowo, dowiedzenie, że VC (verification condition) jest spełnione nazywa się "discharge". Ale po polsku najlepiej powiedzieć, że jest "spełnione", bo "rozładowywanie warunków" brzmi głupio. Dowody mogą być automatyczne albo ręczne.
> 
> I teraz ciekawostka: asercja napisana przy użyciu makra "assert" może być
> traktowana jako warunek do wykazania *oraz* jako nowe założenie dla 
> dalszych rozważań. 

O jakie założenie i o jakie rozważania chodzi?

> W niektórych językach do tego drugiego celu służy konstrukcja "assume" i stosuje się ją wtedy, kiedy wiedza na jakiś temat pochodzi z zewnątrz - np. z tego, jak i gdzie dany program jest użytkowany.

Nie używałem assume. Widzę że w C/C++ microsofcie coś dodali:
https://docs.microsoft.com/en-us/cpp/intrinsics/assume?view=vs-2019

A w GCC zalecają sztuczki:
https://stackoverflow.com/questions/25667901/assume-clause-in-gcc
https://stackoverflow.com/questions/6031819/emulating-gccs-builtin-unreachable

Nie rozumiem, jakie są korzyści z dodania pustej funkcji, albo z operacji
bitowej AND z samymi jedynkami:
x = x & (~0);

Chociaż bezpieczniej byłoby OR z zerami:
x = x | 0;

Pozdrawiam
> 
> -- 
> Maciej Sobczak * http://www.inspirel.com