Commit itt.
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Plusz pont a képért
- A hozzászóláshoz be kell jelentkezni
Ezt nem értem. Az összes modulra is vonatkozik? Én most 5.4-ben dolgozom, és abban az általam használt modulok rengeteg warning-ot dobnak. Azokat mind ki kellene pucolni, különben nem fognak lefordulni. 5.15-ben már ennyivel tisztább lenne a kód?
- A hozzászóláshoz be kell jelentkezni
but make it a config option so that broken environments can disable it when required.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
És mivel az emberiségnek van egy olyan általános törekvése, hogy két megoldás közül mindig az egyszerűbbet választja, ezért ... :-)
- A hozzászóláshoz be kell jelentkezni
Szerintem 10+ éve nem fordítottam se Linux, se BSD kernelt, de akkoriban mindig rácsodálkoztam, hogy a Linux kernel fordítása mennyit "szemetel" egy BSD kernel fordításához képest. Manapság nem tudom mi a helyzet.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Manapság nekem nem sok warning-ot dob, de egy részük feltételezés a fordító részéről, ami vagy igaz, vagy nem...
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
- A hozzászóláshoz be kell jelentkezni
Nagyon jo lesz, amikor valaki egyel ujabb/regebbi gcc verzioval probalja meg leforditani, mint amivel a maintainerek teszteltek, es akkor szerencsetlen user keresgelheti az opciot hogy hol kell azt a k*va -Wall-t letiltania.
Igen, mar nem egyszer belefutottam hogy random program by default -Werror-al van forditva, aztan nem fordul mert egy ujabb gcc-ben van valami extra warning ami korabbiban nem volt, vagy valami random dependency-ben valami random fuggveny deprecated lett vagy ilyenek.
I hate myself, because I'm not open-source.
- A hozzászóláshoz be kell jelentkezni
Hat kerem, mielott kijon az uj fordito, mondjuk affele tesztkent leporgethetik vele a kernelt es utana megvivhatnak Linus-szal, hogy most akkor torjek-e el a kernel buildet vagy kezeljek csak diagnostic-kent a warning-ot. Mindket kimenetel lehet pozitiv.
- A hozzászóláshoz be kell jelentkezni
Mindez nagyon szep es jo, ha van egy idogeped, kulonben kicsit nehez megoldani hogy a mar kireleaselt kod warning mentesen forduljon egy olyan forditoval, ami a release pillanataban meg nem is letezett. A warning-ot meg nem lehet diagnostic-kent kezelni, mert a -Werror azt mondja hogy minden warning error. Amit lehetne hogy -Werror=akarmi-kkal csak bizonyos warningokat felvenni errornak, es akkor ha egy uj compilerben van egy vadi uj warning, akkor az nem lesz error. De az ellen ez se ved, ha pl. az a logika ami megtalalja az unused variableket abban javitanak valamit, es egy uj verzioban mar olyan eseteket is megtalal amit egy korabbi nem,
TL;DR -Werror-nak van ertelme, a fejleszo gepen. Viszont ugy kiadni a kodot hogy defaultban ott legyen ez a flag, az a felhasznalok szandekos szopatasa. (Aztan a csucs amikor ehhez Makefile-t kell patchelni, mert a fejleszto amikor 3 evvel ezelott kiadta a debian-jan levo akkor mar 5 eves gcc-vel meg lehet warning mentesen fordult...)
I hate myself, because I'm not open-source.
- A hozzászóláshoz be kell jelentkezni
Nalunk a tesztet meg a release elott szoktak lefuttatni, nem kell ehhez idogep. Szoval meg mielott kijon az uj csodagcc, hozzacsapjak a testsethez a kernelt is (ha nincs mar ott eleve). Ha elhasal az uj fordito, akkor lehet menni panaszra a kerneldevekhez, hogy most torjon a kernel vagy ne torjon.
Amugy vihar a biliben a kerdes, mert a futo linuxok jelentos resze *nem* a legujabb gcc-vel forditott, *nem* legujabb verzioju kernelt hasznal. Mire a disztrofejlesztok elkezdenek hozzanyulni csomagolni a kernelt es a forditot, ezek a problemak regen megoldodnak. Akinek meg szerencsetlensegbol kifolyolag bleeding edge cuccot kell hasznalnia, ezeket a problemakat rutinosan fogja workaroundolni.
- A hozzászóláshoz be kell jelentkezni
Ertem, tehat nem johet ki uj gcc ha felvesznek valami uj warningot ami barmelyik a vilagon valaha kireleaselt kodra warningolni fog. Valoszinu. Amugy meg a gcc fejlesztok pont leszarjak mi van a linux tajan, lasd pl -fstrict-aliasing.
*nem* a legujabb gcc-vel forditott, *nem* legujabb verzioju kernelt hasznal.
Na igen, pont itt lesz a baj, amikor valamelyik random distroban ugy jon ossze a csillagallas hogy a gcc pont fel evvel ujabb mint a kernel.
I hate myself, because I'm not open-source.
- A hozzászóláshoz be kell jelentkezni
Egyfelol, ha annyi rugalmassag van bennuk, mint benned, akkor deadlock-ba lehet kerulni, dehat ez nem az emberiseg normalisabb felenek a problemaja. Amugy meg sehol nem irtam, hogy a valaha volt osszes kodot be kellene emelni a tesztek koze. De mondjuk a linux kernelt be lehetne, merthat reprezentativ peldaja a "kernel kodnak". Az meg, hogy a gcc fejlesztok leszarjak a linux projektet, szinten nem rolam allit ki szegenysegi bizonyitvanyt. Tudom, hogy opensource berkekben csucsmeno mindenbe beleszarni es releaselni majd flamelni, ha nem mukodik, de ebbol normat gyartani eleg necces.
A random disztro majd megoldja a nyugjeit, ha ilyen ezoterikus dolgokba kezd, a legegyszerubb feladata lesz a build scriptbol kiszedni a -werror-t.
Bottom line: erdemes-e egy gcc meretu projektnek figyelnie egy linux kernel meretu/jelentosegu projektre es vica-versa? Igen, szerintem igen, mert mindketto *sok* felhasznalo szamara relevans.
- A hozzászóláshoz be kell jelentkezni
Erdemes-e a gcc fejlesztoknek a linux kernellel foglalkozni? Valoszinuleg. Libreoffice-szal? Szinten. Random hacker444 2 star-al rendelkezo github projectje? Nem. Jo, akkor hol a hatar? Attol hogy linux kernelre felveszunk egy extra kivetelt, az lehet hogy meg fogja oldani a linux kernel bajat, de a maradek open source szoftver 99.9%-anal meg ugyan ugy problema marad. Ilyen szempontbol ertheto, hogy gcc-sek nem akarnak kulon kiveteleket tenni egy (szamukra) random projekt miatt. Meg ugye itt az is problema hogy melyik verzioju kernelt kene a gcc fejlesztoknek tesztelnuk? Git master? Utolso stable release? Osszes LTS? Osszes elmult 1 evben kiadott release? Milyen architekturan? A kernel 28000 config opciojat mire allitsak? Az osszes 3^28000 opciot nyilvan nem lehet kiprobalni. Nyilvan, lehetne valami minimal configot kernel fejlesztoeknek osszedobni (ha sikerul a gcc-sekbol minimalis hajlandosagot kisajtolni), ami a problemak 98%-at megfogja, de akkor megint ott leszunk hogy az a 2% fog szopni aki nem common hw-n hasznalja a kernelt.
Random disztro megoldja, igen. Nem azt mondom hogy linux-nal ez oriasi problema lesz, sokan hasznaljak, azert valoszinuleg hamar kiderul ha valami nem oke, aztan ha valakinel megse oke, fel perc google es megtalalja a megoldast. Az ilyen kisebb projektek, amik sokszor be se kerulnek semmilyen disztro csomagtarolojaba, na ott szoktak ezek bajosak lenni, mert ott nem mondhatod a usernek hogy szedje le a nem letezo binarist, meg google se biztos fog ertelmes valaszt adni, hogy a random xyz csomag + abc buildrendszer kombinacioban milyen custom flaget kell beadni hogy ne legyen -Werror.
I hate myself, because I'm not open-source.
- A hozzászóláshoz be kell jelentkezni
bar nem ismerem a gcc development workflow-t, de nem hiszem hogy a fejleszto reggel kikel az agybol es kommitol egy warningolo ellenorzest. elotte jo esetben atragjak hogy azt most valoban erdemes warningra rakni, a linux fejlesztok kozul meg valszeg olvassa jopar ezeket az emaileket, igy tudnak rola hogy lesz egy warning, esetleg ha szerintuk az nem warning akkor ervelnek ezert. ha megis bekerul egy ilyen warning uzenet akkor meg az valid, es jo lenne ha nem is lenne ilyen a kernelben, igy nekik kell javitani.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Mindez szep es jo, es valoszinuleg tenyleg >0 olyan ember van aki linux es gcc fejlesztesben is valamennyire benne van, de amit mondtam felul hogy pl talalnak egy bugot valamelyik warningban es javitjak, arrol valoszinuleg nem lesz nagyon hosszas levelezes hogy ezt megis miert. Tovabba azert gcc-be egy uj warning felvetel az nem olyan amihez ossze kell hivni a c commitee-t, nem ilyen sok evre elore kitalalt valami. Es akkor itt jon be a
ha megis bekerul egy ilyen warning uzenet akkor meg az valid, es jo lenne ha nem is lenne ilyen a kernelben, igy nekik kell javitani.
Igen, itt az idogep bajom, a mar kireleaselt kernelek ettol nem fognak magikusan megjavulni. Vagy ezentul minden kernel release melle oda fogjak irni hogy pontosan melyik gcc verziokat tamogatnak, se regebbit se ujabbat? Vannak helyek ahol meg 2.6.3x kernel-t futtatnak (bar teny, ok valami hasonlo frissessegu gcc-t is fognak hasznalni), de azert ennel egy fokkal kevesbe durva verziot el tudok kepzelni (kicsit regi kernelen van, mert az uj kernelen valami nem mukodik, viszont gcc-bol meg fennt van neki az uj, mert kel valami szuper c++huszonsok programhoz, vagy akarmi. Nem azt mondom hogy ez a jellemzo, de azert elo tud fordulni.
Amire ki akarok lyukadni, eleg sok kellemetlen tapasztalatom volt mar abbol mert valaki berakott wgy Werror-t, aztan valamelyik disztroban levo gcc-vel meg epp dobott valami warningot. (Aztan hogy rosszabb legyen a helyzet, ugye disztrok meg szeretnek is belepatchelni neha, legyen-e default -fstack-protector meg tarsai, nem tudom warningokkal jatszanak-e ilyet, de nem lepodnek meg.) Nyilvan, a Linux kernelnek nem nagyon van kulso dependencyje, meg nagyon sokan hasznaljak, igy kevesbe valoszinu hogy ebbol baj legyen, de azert nem kizarhato.
I hate myself, because I'm not open-source.
- A hozzászóláshoz be kell jelentkezni
Vagy ezentul minden kernel release melle oda fogjak irni hogy pontosan melyik gcc verziokat tamogatnak, se regebbit se ujabbat?
Ennek lenne értelme, igen. Ha nem is adott MAJOR.MINOR.PATCH verziót, de legalább egy MAJOR.MINOR - MAJOR.MINOR tartományt. A GCC fejlesztőitől meg elvárható lenne, hogy egy új warning bevezetése, vagy egy meglévő warning scopejának növelése minimum a MINOR verzió növelését vonja maga után.
Nem tudom, C/C++ fejlesztésnél mennyire jellemző, hogy különböző projectek különböző verziójú toolchaint követeljenek meg. Magasabb szintű nyelveknél és runtimeoknál ez azért elő szokott fordulni, ezért vannak is rá megoldások. Én azt gondolnám, hogy ezt meg lehet oldani C/C++ projecteknél is.
- A hozzászóláshoz be kell jelentkezni
Ha nem is adott MAJOR.MINOR.PATCH
A gcc verziozasa mostanaban MINOR.PATCH.CONSTANT_0, utobbi 10 evben mindenki elfelejtette hogy mire jo a verzioszam, nem csak a webbrowser fejlesztok :( De igen, az elvarhato hogy patch verzioba uj warning ne keruljon bele, de ha esetleg kiderul hogy egy bug miatt valamelyik warning neha nem warningolt, akkor ezt megjavithatjak?
Nem tudom, C/C++ fejlesztésnél mennyire jellemző, hogy különböző projectek különböző verziójú toolchaint követeljenek meg.
Ceges kornyezetben szokott inkabb ilyen elofordulni, opensource projekteknel nem annyira. Mert hat ugye ha egy szabanynak megfelelo programot irsz, akkor az barmilyen a szabvanyt implementalo compilerrel pontosan ugyan olyan tokeletesen kell mukodjon :) Na de viccet felreteve Pale Moon-t leszamitva most nem tudnek mondani olyan opensource programot amit igy kulonosebben erdekelne melyik verzioju compilered van, azt leszamitva hogy minimum x. Azert a C-nel komolyan veszik a backward compatibilityt (c++-nal mar kevesbe), nem ugy mint python meg rust meg tarsai ahol minden uj release 50000 dolgot eltor, ugyhogy emiatt valoszinuleg amugy is kisebb szukseg van ra. Ha valami nem mukodik egy uj compilerrer, akkor vagy eleve hibas volt a kod, vagy bugos a compiler.
Nyilvan, egy kernel az azert mas kategoria mint egy random userspace cucc, sokkal tobb low level hakolas kell bele, ugyhogy azert itt egy fokkal vallalhatobb hogy kicsit jobban dependel a compileren. Mar az eleve gcc specifikus hogy hogy csinalsz olyan binarist ami igy egy nyers ize, es nem egy ELF vagy PE vagy akarmi amit egy OS be fog tolteni, de azert a libgcc funkcionalitasa legyen meg.
I hate myself, because I'm not open-source.
- A hozzászóláshoz be kell jelentkezni
Teljesen jogosak a kerdesek, amiket felvetsz, es egy valamirevalo projektnek adott mereten belul tudni is kell ezekre valaszolni (es lehetoleg valami erdemi alapokon nyugvo valaszt adni pl. cost/benefit). Majd csiszolni a valaszokat a tapasztalatok es a valtozasok fenyeben. Mert ezek a valaszok jelentosen hozzajarulnak ahhoz, hogy az opensource okoszisztema mennyire lesz integralhato.
- A hozzászóláshoz be kell jelentkezni
"Az osszes 3^28000 opciot nyilvan nem lehet kiprobalni."
BTW, na most az akarajatok modani, hogy valaki be tudja loni 28000 opciot,
de egy Werror -t nem tud kikapcsolni ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Mire a disztrofejlesztok elkezdenek hozzanyulni csomagolni a kernelt es a forditot
How about Gentoo? ;-)
- A hozzászóláshoz be kell jelentkezni
Ez nem így megy, a kernel adott GCC főverziókat támogat. Van olyan, hogy az újabb támogatását backportolják, de attól, hogy kijön a gcc még nem lesz támogatott.
- A hozzászóláshoz be kell jelentkezni
Hát, apt/yum/yay kernel. Majd megoldja más.
- A hozzászóláshoz be kell jelentkezni
Ezért best practice jobb helyeken, hogy standard fordítót használnak. Jobb hely: Android, BSD, Apple. :)
PS: Köszönjük Drupal, hogy nem sikerült a megfelelő helyre írni a választ.
- A hozzászóláshoz be kell jelentkezni
Azt nem értem, hogy miért kell olyan sz*r kódot írni, ami warningos a fordítási időben. Az elmúlt 40 év alatt megtanultam, hogy a warning mindig jelent valamit :) ...és minden IF-nek legyen ELSE ága is :)
- A hozzászóláshoz be kell jelentkezni
...és minden IF-nek legyen ELSE ága is :)
Így gondolod? :)))
int elempos(elem *a, int l, elem e)
{
int i;
if (a == NULL)
{
return -1;
}
for (i = 0; i < l; ++i)
{
if (a[i] == e)
{
return i;
}
else
{
continue; // :P
}
}
return -1;
}- A hozzászóláshoz be kell jelentkezni
Nem, meg a for ciklust is beletenne egy else agba ;) ! Nem irigylem, akinek review-znia kell a 40 evnyi rutinnal osszerakott kodjait...
- A hozzászóláshoz be kell jelentkezni
Jajdevarjal, mert meg egyszer bele lesz kotve a kodba, hogy 1-nel tobb 'return' van benne fuggvenyenkent. Egyes dogmavezerelt helyeken azert is jar a koki meg a saller.
- A hozzászóláshoz be kell jelentkezni
Sebaj, megcímkézem az egyetlen return-t és oda goto-zok. ;)
- A hozzászóláshoz be kell jelentkezni
Akkor jovan.
- A hozzászóláshoz be kell jelentkezni
Bocsi, annyi meg marad, hogy a goto elott a visszateresi erteket el kell tenni egy valtozoba, de ez mar igazan semmiseg.
- A hozzászóláshoz be kell jelentkezni
Abban mi a kihívás? Kirakom globális változóba, a return meg visszaad, amit akar. :]
- A hozzászóláshoz be kell jelentkezni
Könnyű reviewzni: reject.
- A hozzászóláshoz be kell jelentkezni
Már az első sor nem menne át egy rendes review-n (beépített típusokat nálunk pl. kötelező inicializálni). A continue ágért járna a brick is.
- A hozzászóláshoz be kell jelentkezni
Nem tűnt fel, hogy szarkazmus volt?
- A hozzászóláshoz be kell jelentkezni
Még a -ansi opciót is defaulttá tehetné, akkor lenne igazán nagy borulás :D
(de legalábbis a gnu extension-öket sem kellene benne hagyni)
- A hozzászóláshoz be kell jelentkezni
Eselytelen, tul sok helyen vannak hasznalva. Meg clang-al is vannak problemak, hivatalosan asszem meg mindig nem tamogatott, pedig az azert implementalja a gnu extensionok nagy reszet.
I hate myself, because I'm not open-source.
- A hozzászóláshoz be kell jelentkezni
Nincs ezzel semmi gond. Eddig is Linus döntötte el, hogy mikor kész egy kiadás. Legfeljebb kicsit hosszabb lesz egy időablak - vagy kevesebb commit lesz beemelve adott időablak alatt. Valószínűleg jót tenne a Linuxnak, ha kicsit kevésbé rohannának a kernelfejlesztők.
(Közismert legenda, hogy a - ma már DragonflyBSD-s, akkor FreeBSD-fejlesztő - Matthew Dillon bekapcsolt valami assert -> kernel panic jellegű beállítást a 4.x FreeBSD make world-jében, aminek hatására esett-kelt a rendszer, de egy rövid idő után szépen kihullottak a hibák :-) )
- A hozzászóláshoz be kell jelentkezni
Nekem nem nyom a kernelfordítás warningokat, igaz csak lehet azért, mert nem volt bekapcsolva a kijelzése a make scriptben. De igazából ez a warning fetisizmus hülyeség, egy olyan portábilis szoftvernél, mint a Linux kernel, hogy nem tudom hány architektúrán, hányféle fordítóval (gcc, clang), azok rengeteg félre verziójával mind le kell forduljon, ezen a szinten nem kéne a warningoknak túl nagy figyelmet szentelni.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Biztos sok a "felesleges" warning, de van jó pár, ami pl egy újabb szemléletű nyelv alatt már nem warning, hanem fordítási hiba. Azért lennének a warningok, hogy a rossz beidegződéseket, gyakran hibát okozó gyakorlatokat kivezessék és legyen egyfajta kódminőség és egységesség, ami mellett ugyan még bőven lehet hibaforrás, de talán a lefordított szoftver minőségére is kihat(hat). Egy projekt vezetője, lásd Linus, joggal várja el, hogy minden lehetséges módon (egyik módja a warningok kigyomlálása) törekedjenek a minőségi kódbázisra. Szerintem.
- A hozzászóláshoz be kell jelentkezni
aztan ezek a warningok egy resze szokott kesobb atalakulni cve-kke :D
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Aztán meg sírássá, hogy nem a régi az Arch sem, mert hol az új bleeding edge kernel, hát nyaralnak ezek?! ;)
- A hozzászóláshoz be kell jelentkezni
A magam részéről azért tértem át rolling release disztróra, hogy mindig a legújabb fordítókkal dolgozhassak, és ha megjelenik egy új gcc/clang warning azzal én találkozzak először. A warningokat kijavítom, mielőtt még mások találkoznának vele (legalábbis ez a cél). A sok warning azért nem jó, mert a sok szemét között nem veszed észre, ha megjelenik egy újabb, ami tényleg fontos.
Lógok a szeren (K. Frigyes)
Lógok az ereszen (Sz. József)
- A hozzászóláshoz be kell jelentkezni