🚀 go-pugleaf

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