On Saturday, September 7, 2019 at 5:04:15 PM UTC+2, Maciej Sobczak wrote:
> > Z tego co słyszałem testuje się na wyrywki.
>
> Można, ale to słaba metoda. "Wyrywki" zakładają, że jakiś zbiór jest jednakowo
czuły w swoich różnych punktach, co właściwie nigdy nie jest prawdą. Dotyczy to
dowolnej konstrukcji inżynierskiej, nie tylko w programowaniu.
> Dlatego testuje się równoważne klasy i ich brzegi. Jeśli np. coś ma zakres od 10 do
100, to zamiast zrobić 20 testów na wyrywki lepiej jest zrobić testy np. dla 9, 10,
11, 50, 99, 100, 101.

Tak, oczywiście. Dawanie danych całkowicie losowo to tak jakby
punkt wyjścia. Jeśli mamy procedurę która trywialnym algorytmem
traktuje duży przedział, to warto dla tej procedury zaprojektować
dane o specjalnym rozkładzie prawdopodobieństwa.

Np.:

int funkcja( int x, int y ) {
if( x >= 100 || x <= -100 || y >= 100 || y <= -100 ) {
return 0;
}
return trudne_obliczenia;
}

To warto częściej losować w 'trudny przedział'.


>
> > Napisanie oprogramowanie
> > do sterowania rakietą zlecano ośmiu kompletnie niezależnym zespołom.
>
> Był kiedyś taki pomysł, ale odchodzi się od niego,

Z tego co słyszałem z niezależnych źródeł, to tak się robiło. Natomiast
'sam dla siebie' robiłem tak często, czasami miałem trzy wersje jednej
procedury. Jedna wersja to wersja napisana na szybko po wstępnym
przemyśleniu, druga to po poprawieniu czytelności, a trzecia to po
optymalizacji - o ile optymalizacja była robiona. Wszystkie wersje
trzymałem w kodzie:

typ funkcja( argumenty ) {
#ifdef debug
old_value = old_funkcja( argumenty );
#endif
// nowy kod
#ifdef debug
assert( value == old_value );
#endif
return value;
}




> bo okazało się, że problemem wcale nie jest poprawność oprogramowania,
> tylko kompletność wymagań.

Nie wypowiem się, nie mam tylu danych i doświadczeń aby wyrobić sobie zdanie.


// Po co robić 8 tak samo złych programów?

Tak to oczywiście nie ma sensu.

> Stosuje się oczywiście redundancję, ale po to, żeby uchronić się przed zjawiskami
sprzętowymi. Czyli zobaczysz np. dwa identyczne komputery z *identycznym*
oprogramowaniem (czyli jest 1 projekt a nie 8), ale umieszczone w *różnych miejscach*
rakiety albo samolotu i to np. pozwala rozwiązać problemy powodowane przez
przypadkowe promieniowanie albo zpełnie normalne awarie sprzętu.

Tak, ale na awarie sprzętu taka metoda jest tak jakby standardowa i oczywista.


> Ale pomysł na różne wersje oprogramowania okazał się być
> nieużyteczny i niepotrzebnie kosztowny.

Czy ja wiem... Jakby od zera do końca projektu prowadzić niezależnie 8 zespołów
to faktycznie drogo i ciężko. Ale jak projekt mamy (prawie) ukończony, to
nie jest aż tak bardzo kosztowne, aby wybrać z niego kluczowe procedury,
dobrze udokumentować i zlecić napisanie innym zespołom tylko tych procedur.

Mnie się metoda wydaje ciekawa, gdy sam sobie pisałem różne wersje tych
samych procedur, to kilka upierdliwych błędów wychwyciłem, szczególnie na
etapie optymalizacji.

Pozdrawiam

do góry

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-autorski
ch.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/n125
6.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".

do góry

On 2019-09-07 01:48, g...@g...com wrote:
> W dniu piątek, 6 września 2019 17:06:15 UTC+2 użytkownik AK napisał:
>> On 2019-09-06 10:33, Mateusz Viste wrote:
>>> On Fri, 06 Sep 2019 01:12:39 -0700, M.M. wrote:
>>>> A uzasadnienia i tak i tak nie będzie.
>>>
>>> AK to mistrz krytyki, ale na tym jego talent zdaje się kończyć... nie
>>> widziałem by kiedykolwiek sam cokolwiek mądrego napisał.
>>
>> Piszę same mądre (czyli prawdziwe) rzeczy :).
>> Nie moja wina, że głupcy ich nie dostrzegają.
>
> A może jednak Twoja, Pierdoliszu.

No ladnej cie Rodzice kulturki nauczyli :)

> Może gdybyś był prawdziwie mądry, umiałbyś pisać swoje rzeczy w taki sposób, żeby
ci biedni głupcy potrafili ujrzeć blask Twej mądrości.

No to jeszcze raz.
Standard C okresla wyraznie, ze aseerty w C "wstawiane sa" (czyli tez
wykonuja sie) _jedynie_ w trybie debug.
Oczywiscie mozna napisac swoje asserty (tylko po co? Te z assert.h sa
wystarczajace), ale _musza byc one zgodne ze standardem czyli:
1. byc zgodne w sensie API z tymi z assert.h
2. byc z nimi zgodne "semantycznie" i "behawioralnie" (czyli m.in.
_rowniez_ musza byc "wstawiane" w trybie debug.
Bez spelnienia tych zalozen to sa "robotki domowe" a nie asserty w
sensie jezyka C.

> Może jestem głupcem

"Moze" jest niepotrzebne.

> A kiedy ja, kaleka umysłowy, próbuję sformułować myśl, to Ty, Pierdoliszu, zamiast
próbować ją jakoś zinterpretować, zamiast pomóc mi sformułować ją tak, żeby miała
sens dla nas obu, stwierdzasz, że "pieprzę 3po3", w czym mój pożałowania godny
zawistny umysł doszukuje się takiej ewentualności, że może dlatego wydaje Ci się, że
"pieprzę 3po3", że sam nie jesteś w stanie moich słów zinterpretować, i dlatego
wolisz je zdyskredytować.

No a co mam powiedziec jesli zwyczajnie "pi..lisz" majac standard C (a
to _jest wyrocznia_) zwyczajnie w d.. ?

AK

do góry

W dniu niedziela, 8 września 2019 08:13:54 UTC+2 użytkownik AK napisał:

> >> Piszę same mądre (czyli prawdziwe) rzeczy :).
> >> Nie moja wina, że głupcy ich nie dostrzegają.
> >
> > A może jednak Twoja, Pierdoliszu.
>
> No ladnej cie Rodzice kulturki nauczyli :)

Zwracam się do Ciebie tak, jak mi się przedstawiłeś

> > Może gdybyś był prawdziwie mądry, umiałbyś pisać swoje rzeczy w taki sposób, żeby
ci biedni głupcy potrafili ujrzeć blask Twej mądrości.
>
> No to jeszcze raz.
> Standard C okresla wyraznie, ze aseerty w C "wstawiane sa" (czyli tez
> wykonuja sie) _jedynie_ w trybie debug.

To jeżeli określa wyraźnie, to może po prostu przytocz tu odpowiedni cytat i będzie
po sprawie. Ale jeżeli asercjami nazywasz makra assert (czego standard nie robi), to
standard nigdzie nie używa określeń 'wstawiane są' ani 'wykonują się' w odniesieniu
do użyć tego makra. Nigdzie też nie mówi, że makro 'assert' jest jedyną dopuszczalną
metodą robienia asercji w kodzie.

Jeżeli idzie o makra, to makra co najwyżej 'rozwijane są do'.
I standard mówi jawnie, że jak masz NDEBUG, to makro assert rozwija się do ((void)
0). Nie mówi nic w stylu 'asercja jest wstawiana', bo to programista wstawia asercje,
ani 'asercja wykonuje się', bo to niedorzeczność.

> Oczywiscie mozna napisac swoje asserty (tylko po co? Te z assert.h sa
> wystarczajace), ale _musza byc one zgodne ze standardem czyli:
> 1. byc zgodne w sensie API z tymi z assert.h
> 2. byc z nimi zgodne "semantycznie" i "behawioralnie" (czyli m.in.
> _rowniez_ musza byc "wstawiane" w trybie debug.
> Bez spelnienia tych zalozen to sa "robotki domowe" a nie asserty w
> sensie jezyka C.

Przeoczyłeś chyba moje pytanie o STATIC_ASSERT, Pierdoliszu.

> > Może jestem głupcem
>
> "Moze" jest niepotrzebne.
>
> > A kiedy ja, kaleka umysłowy, próbuję sformułować myśl, to Ty, Pierdoliszu,
zamiast próbować ją jakoś zinterpretować, zamiast pomóc mi sformułować ją tak, żeby
miała sens dla nas obu, stwierdzasz, że "pieprzę 3po3", w czym mój pożałowania godny
zawistny umysł doszukuje się takiej ewentualności, że może dlatego wydaje Ci się, że
"pieprzę 3po3", że sam nie jesteś w stanie moich słów zinterpretować, i dlatego
wolisz je zdyskredytować.
>
> No a co mam powiedziec jesli zwyczajnie "pi..lisz" majac standard C (a
> to _jest wyrocznia_) zwyczajnie w d.. ?

Jest sobie słowo. Tym słowem jest 'asercja' w języku polskim (albo 'assertion' po
angielsku). To słowo ma swoje określone znaczenie.
Nawet standard C w paru miejscach używa tego słowa w tym znaczeniu.


Otwórz i zobacz sam, Pierdoliszu Głupoty.

https://sjp.pl/asercja

do góry

On 2019-09-08 08:58, g...@g...com wrote:

>>> Może jestem głupcem
>>
>> "Moze" jest niepotrzebne.

"Moze" na 100% jest niepotrzebne.

>> No a co mam powiedziec jesli zwyczajnie "pi..lisz" majac standard C (a
>> to _jest wyrocznia_) zwyczajnie w d.. ?
>
> Jest sobie słowo. Tym słowem jest 'asercja' w języku polskim (albo 'assertion' po
angielsku). To słowo ma swoje określone znaczenie.
> Nawet standard C w paru miejscach używa tego słowa w tym znaczeniu.

Ales ty guuupi :)

AK

do góry

On Sunday, September 8, 2019 at 8:13:54 AM UTC+2, AK wrote:
> On 2019-09-07 01:48, ...@...m wrote:
> > W dniu piątek, 6 września 2019 17:06:15 UTC+2 użytkownik AK napisał:
> >> On 2019-09-06 10:33, Mateusz Viste wrote:
> >>> On Fri, 06 Sep 2019 01:12:39 -0700, M.M. wrote:
> >>>> A uzasadnienia i tak i tak nie będzie.
> >>>
> >>> AK to mistrz krytyki, ale na tym jego talent zdaje się kończyć... nie
> >>> widziałem by kiedykolwiek sam cokolwiek mądrego napisał.
> >>
> >> Piszę same mądre (czyli prawdziwe) rzeczy :).
> >> Nie moja wina, że głupcy ich nie dostrzegają.
> >
> > A może jednak Twoja, Pierdoliszu.
>
> No ladnej cie Rodzice kulturki nauczyli :)

Czas nie jest z gumy, ten czas który straciliście na tę czy inną
awanturę już jest stracony, już w tym czasie nic dobrego nie zrobicie.


> > Może gdybyś był prawdziwie mądry, umiałbyś pisać swoje rzeczy w taki sposób, żeby
ci biedni głupcy potrafili ujrzeć blask Twej mądrości.
>
> No to jeszcze raz.
> Standard C okresla wyraznie, ze aseerty w C "wstawiane sa" (czyli tez
> wykonuja sie) _jedynie_ w trybie debug.

Ale standard nie zabrania pisania swojego dowolnego (byle poprawnego)
kodu diagnostycznego. Z ogólnego tematu pisania absolutnie bezbłędnego
kodu, zabrnęliśmy w straszny szczegół jakim są asercje i to w dodatku
rozmawiamy TYLKO o asercjach z biblioteki standardowej lub ze standardów
C/C++! Temat tworzenia bezbłędnego kodu jest fascynujący, po co tracić
czas na duperel i szczegół?


> Oczywiscie mozna napisac swoje asserty (tylko po co? Te z assert.h sa
> wystarczajace),
Jeśli są wystarczające, to znaczy że czegoś nie wiem o standardowych
asercjach. Jak (łatwo i wygodnie) zrobić przy pomocy standardu zrzut do
pliku logu komplet wszystkiego tego co może być pomocne? Można chyba
zrzucić wyrażenie (jako string), plik i numer linii. Ja chcę (przynajmniej)
jeszcze zrzucić datę kompilacji, wersję programu, datę wystąpienia problemu i
co najważniejsze wszystkie wartości zmiennych z funkcji. Poza tym chcę mieć w
logu stos wywołań dla każdego wątku? W Qt mam klasę qdebug:

https://doc.qt.io/qt-5/qdebug.html

QDebug trochę przypomina moje metody logowania i testowania, ale moje są
wygodniejsze, przynajmniej dla mnie.

> ale _musza byc one zgodne ze standardem czyli:
> 1. byc zgodne w sensie API z tymi z assert.h

Jaką zgodność masz na myśli?


> 2. byc z nimi zgodne "semantycznie" i "behawioralnie" (czyli m.in.
> _rowniez_ musza byc "wstawiane" w trybie debug.

Oczywiście, po co assert bez wstawiania?


> Bez spelnienia tych zalozen to sa "robotki domowe" a nie asserty w
> sensie jezyka C.

Ehhh.


> > A kiedy ja, kaleka umysłowy, próbuję sformułować myśl, to Ty, Pierdoliszu,
zamiast próbować ją jakoś zinterpretować, zamiast pomóc mi sformułować ją tak, żeby
miała sens dla nas obu, stwierdzasz, że "pieprzę 3po3", w czym mój pożałowania godny
zawistny umysł doszukuje się takiej ewentualności, że może dlatego wydaje Ci się, że
"pieprzę 3po3", że sam nie jesteś w stanie moich słów zinterpretować, i dlatego
wolisz je zdyskredytować.
>
> No a co mam powiedziec jesli zwyczajnie "pi..lisz" majac standard C (a
> to _jest wyrocznia_) zwyczajnie w d.. ?

Można napisać dlaczego ma standard w d. Ale temat standardu to też tylko
(ważny) szczegół tworzenia bezpiecznego oprogramowania.


Pozdrawiam

do góry

W dniu niedziela, 8 września 2019 11:20:03 UTC+2 użytkownik AK napisał:

> > Jest sobie słowo. Tym słowem jest 'asercja' w języku polskim (albo 'assertion' po
angielsku). To słowo ma swoje określone znaczenie.
> > Nawet standard C w paru miejscach używa tego słowa w tym znaczeniu.
>
> Ales ty guuupi :)

Bo...?

A, wiem.
"Bo piszę głupoty".

Szkoda mi czasu na taki "poziom argumentacji".

Przykładowo, ISO/IEC 9899:TC3 [http://www.open-std.org/jtc1/sc22/wg14/www/docs/n12
56.pdf], strona 111

EXAMPLE 1 The file scope declarations

int * restrict a;
int * restrict b;
extern int c[];

assert that if an object is accessed using one of a, b, or c, and that object is
modified anywhere in the program, then it is never accessed using either of the other
two.

Możesz zobaczyć, że pierwszym słowem następującym po fragmencie kodu jest słowo
"assert". I mogę Ci podpowiedzieć, że to nie jest makro w C. Frazę "assert that"
przetłumaczyłbym w tym miejscu jako "stwierdzają, że".

do góry

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

do góry

> 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

do góry

On 2019-09-08 12:13, g...@g...com wrote:
> W dniu niedziela, 8 września 2019 11:20:03 UTC+2 użytkownik AK napisał:
>
>>> Jest sobie słowo. Tym słowem jest 'asercja' w języku polskim (albo 'assertion' po
angielsku). To słowo ma swoje określone znaczenie.
>>> Nawet standard C w paru miejscach używa tego słowa w tym znaczeniu.
>>
>> Ales ty guuupi :)
>
> Bo...?
>
> A, wiem.
> "Bo piszę głupoty".

Tak. To na dole w pełni moją opinię potwierdza.
(zajmij sie filologią a nie programowaniem).

> Szkoda mi czasu na taki "poziom argumentacji".
>
> Przykładowo, ISO/IEC 9899:TC3 [http://www.open-std.org/jtc1/sc22/wg14/www/docs/n12
56.pdf], strona 111
>
> EXAMPLE 1 The file scope declarations
>
> int * restrict a;
> int * restrict b;
> extern int c[];
>
> assert that if an object is accessed using one of a, b, or c, and that object is
modified anywhere in the program, then it is never accessed using either of the other
two.
>
> Możesz zobaczyć, że pierwszym słowem następującym po fragmencie kodu jest słowo
"assert". I mogę Ci podpowiedzieć, że to nie jest makro w C. Frazę "assert that"
przetłumaczyłbym w tym miejscu jako "stwierdzają, że".
>

AK

do góry