rpm 3.0.3 na horyzoncie

[Tomasz Kłoczko]

On Tue, 12 Oct 1999, Jan Rekorajski wrote:

> [poniedziałek, 11 październik 1999], Martin Dalecki napisał(a):
> 
> > Ponadto jeśli chodzi o aplikacje z zakresu usera, to błędy
> > jakie mogą wyniknąć z strict-aliasing powinny powodować, że
> > dana aplikacja na nich się strasznie zwali, czyli są to incydenty
> > *jawne*
> > i trywialnie wykrywalne debuggeren! Radzę w takim wypadku 
> > po prostu poprawić aplikację (albo ją odrzucić, bo jeśli jest tak
> > chłamsko napisana to raczej jest ona też i nic nie warta...)
> 
> ntalk, do boju, popraw. Albo pokaż inny talk daemon.
> 
> > 
> > Jeszcze raz GCC-2.95.1 to krok milowy w porównaniu z rekomendowanym
> > przez wyżej wymienionych 2.7.xx, czy 2.8.xx. Nie ma więc potrzeby
> > rezygnować z optymalizacji kodu.
> 
> A co daje -fstrict-aliasing, na ile wyłączenie tego pogorszy kod?

Artur nie ma czasu teraz sie zając rpm-em więc wyhodzi na to, że ja chyba
zdąże sie nim zajać :) (na dzisiaj mam i tak kilka pakietów które
potrzebuję ASAP więc nie zamierzam się dzisiaj łapać za rpm-a).

Pytanie w takim razie będzie: co będzie miało dla nas większy
pozytywny skutek ? czy globalnie włączenie -fno-strict-aliasing i ukrycie
ewentualnych niedoróbek na poziomie źródeł czy też nie ukrywanie ich po to
żeby wychwycić przy okazji programy które potencjalnie z racji słabej
jakosci kodu mogą także nieść w sobie (potencjalnie) inne nieprzwidziane
skutki błędów w nich zawartych ?

Mi się wydaje w takim razie, że mamy oto możliwość założenia sieci przez
którą może nie przejść kilk pakietów, które znalazwszy sie z tego powodu
na swego rodzaju czarnej liście umożliwiłyby na dłużsża metę w lepszej
stabilizacji całości kodu. Takie pakiety mogłyby dostać reczną korektę na
poziome speca w postaci dodania -fno-strict-aliasing co już samo w sobie
byłoby rejestrem takich podejrzanych pakietów.

Eny koments ? bo podyskutować o tym zanim jeszcze ktoś złapie się za rpm-a
możemy.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*