Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #32905 > unrolled thread

Jak to robią w NASA

Back to article view | Back to pl.comp.programming

Contents

  Jak to robią w NASA Roman Tyczka <noemail@because.no> - 2019-08-30 09:09 +0200
    Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-08-30 07:20 +0000
      Re: Jak to robią w NASA Roman Tyczka <noemail@because.no> - 2019-08-30 12:27 +0200
        Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-08-30 11:09 +0000
          Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 18:42 +0200
            Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-01 10:01 +0200
          Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 18:52 +0200
        Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 19:43 +0200
      Re: Jak to robią w NASA bartekltg <bartekltg@gmail.com> - 2019-09-04 07:39 -0700
    Re: Jak to robią w NASA queequeg@trust.no1 (Queequeg) - 2019-08-30 08:06 +0000
      Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-08-30 12:49 +0000
        Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 19:17 +0200
        Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-08-31 13:14 -0700
          Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 22:44 +0200
            Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-08-31 13:54 -0700
            Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-08-31 14:15 -0700
          Re: Jak to robią w NASA queequeg@trust.no1 (Queequeg) - 2019-09-01 17:21 +0000
        Re: Jak to robią w NASA queequeg@trust.no1 (Queequeg) - 2019-09-01 17:17 +0000
      Re: Jak to robią w NASA Adam Klobukowski <adamklobukowski@gmail.com> - 2019-08-30 10:20 -0700
        Re: Jak to robią w NASA queequeg@trust.no1 (Queequeg) - 2019-09-01 17:23 +0000
    Re: Jak to robią w NASA Wojciech Muła <wojtek.mula@gmail.com> - 2019-08-30 10:21 -0700
      Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 19:21 +0200
      Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-01 10:05 +0200
        Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-09-04 17:38 +0200
          Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 19:10 +0200
    Re:Jak to robią w NASA slawek <x.y@org.org> - 2019-08-31 20:03 +0200
      Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-01 13:55 -0700
        Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-02 08:30 +0200
          Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-02 05:16 -0700
            Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-02 21:33 +0200
              Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-03 00:42 -0700
                Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-03 18:34 +0200
              Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-03 01:58 -0700
                Re: Jak to robią w NASA Roman Tyczka <noemail@because.no> - 2019-09-03 16:28 +0200
                  Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-03 11:49 -0700
                    Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-03 12:33 -0700
                      Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-04 00:31 -0700
                        Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-04 00:53 -0700
                          Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 19:04 +0200
                            Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 19:07 +0200
                            Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-04 10:54 -0700
                              Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 21:07 +0200
                                Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-04 14:05 -0700
                                  Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-05 04:37 -0700
                                  Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-06 07:31 +0200
                                    Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-06 01:12 -0700
                                      Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-09-06 08:33 +0000
                                        Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-06 03:06 -0700
                                          Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-09-06 10:57 +0000
                                          Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-06 06:42 -0700
                                            Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-09-06 14:06 +0000
                                              Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-06 12:03 -0700
                                                Re: Jak to robią w NASA Mateusz Viste <mateusz@wont.tell> - 2019-09-06 19:12 +0000
                                                  Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-07 01:55 -0700
                                                    Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-07 08:04 -0700
                                                      Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-07 10:35 -0700
                                        Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-06 17:06 +0200
                                          Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-06 16:48 -0700
                                            Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-08 08:13 +0200
                                              Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-07 23:58 -0700
                                                Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-08 11:19 +0200
                                                  Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-08 03:13 -0700
                                                    Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-09 17:56 +0200
                                              Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-08 02:36 -0700
                                      Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-06 17:11 +0200
                                        Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-06 09:22 -0700
                                    Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-06 10:14 -0700
                                      Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-06 11:28 -0700
                                        Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-06 14:59 -0700
                          Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-04 14:49 -0700
                            Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-06 09:29 -0700
                              Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-06 12:25 -0700
                                Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-06 14:00 -0700
                                  Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-07 08:21 -0700
                                    Re: Jak to robią w NASA godek.maciek@gmail.com - 2019-09-07 15:18 -0700
                                      Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-08 08:32 -0700
                                      Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-08 13:17 -0700
                                        Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-10 22:30 -0700
                                          Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-11 00:21 -0700
                                            Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-11 11:32 -0700
                                              Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-12 00:21 -0700
                                                Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-12 03:05 -0700
                                                  Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-12 23:14 -0700
                                        Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-11 20:09 +0200
                      Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 19:00 +0200
                Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-03 18:35 +0200
                  Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-03 11:51 -0700
                    Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 18:43 +0200
                Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-03 18:43 +0200
                  Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-03 11:04 -0700
                    Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-03 20:26 +0200
                      Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-03 23:32 -0700
                        Re: Jak to robią w NASA AK <nobody@nowhere.net> - 2019-09-04 18:52 +0200
                          Re: Jak to robią w NASA "M.M." <mmarszik@gmail.com> - 2019-09-05 00:20 -0700
                  Re: Jak to robią w NASA Maciej Sobczak <see.my.homepage@gmail.com> - 2019-09-03 12:05 -0700
                Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-09-04 18:11 +0200
        Re: Jak to robią w NASA slawek <x.y@org.org> - 2019-09-04 18:00 +0200

Page 1 of 5  [1] 2 3 4 5  Next page →

#32905 — Jak to robią w NASA

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

-- 
pozdrawiam
Roman Tyczka

[toc] | [next] | [standalone]

#32906

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

[toc] | [prev] | [next] | [standalone]

#32908

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

[toc] | [prev] | [next] | [standalone]

#32909

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

[toc] | [prev] | [next] | [standalone]

#32915

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/

[toc] | [prev] | [next] | [standalone]

#32928

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

[toc] | [prev] | [next] | [standalone]

#32916

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/

[toc] | [prev] | [next] | [standalone]

#32919

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/

[toc] | [prev] | [next] | [standalone]

#32964

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

[toc] | [prev] | [next] | [standalone]

#32907

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

[toc] | [prev] | [next] | [standalone]

#32910

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

[toc] | [prev] | [next] | [standalone]

#32917

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/

[toc] | [prev] | [next] | [standalone]

#32923

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

[toc] | [prev] | [next] | [standalone]

#32924

"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/

[toc] | [prev] | [next] | [standalone]

#32925

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

[toc] | [prev] | [next] | [standalone]

#32926

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.

[toc] | [prev] | [next] | [standalone]

#32931

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

[toc] | [prev] | [next] | [standalone]

#32930

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

[toc] | [prev] | [next] | [standalone]

#32911

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

[toc] | [prev] | [next] | [standalone]

#32932

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | pl.comp.programming

csiph-web