XCHAOS: Mne ani to C++ nevadi kdyz je to rozumnej subset, bez zbesilyho template metaprogramovani a boostu a podobnych veci.

ANT_39: Mne maintenance nevadi, honit bugy me docela bavi :) ... navic delat na free/open source projektech mne osobne i dava smysl.

(http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/ )

WILD_A: Red Hat tenhle druh pozic polopravidelne miva, ale velka cast te prace byva maintenance, takze a) novyho kodu clovek typicky moc nepise, a b) nejakej cas urcite stravis Red Hatima procesama a praci s internima nastrojema; oboji je celkem stejna otrava jako v kazde jine firme.

Zase jsi ale placenej za praci na zajimavych codebase, nedavno treba hledali maintainera pro Python na sekundarnich architekturach (powerpc, s390, ARM), coz mas prakticky garantovany, ze se zvrtne v neco zajimaveho :) A treba kolega se dostal na QA pozici, a behem snad dvou, tri let presel na vyvoj GCC, a ted pise UBsan.

WILD_A: určitě je to vhodný se tady zeptat. já bych o takovou práci taky stál... ale je vzácností narazit na to, že hledají fakt C a ne C/C++ ... já mám ten problém, že C++ prostě nestravuju.

XCHAOS: Ja to nepouzil stylem AS IS ale vykopiroval a modifikoval jsem co jsem potreboval, takze primej example nemam.

WILD_A: existuje někde example využití C API k tomuhle? (já ve zdrojácích hledal jen jejich dynamická pole, a dost mi zklamala, popravdě)

(pokud tuhle debatu sleduješ dýl, možná tušíš, že já fandím spojovým seznamům...)

XCHAOS: Neni to json parser, ale vlastne generator kodu, kterej to cpe do struktur, ktery se v komentarich nejak popisou.

Jinak asociativni pole v C je imho nejlepsi obslehnout z Pythonu jejich dictionary object, aspon ja to tak udelal, rychly a dostatecne obecny.
http://svn.python.org/projects/python/trunk/Include/dictobject.h
http://svn.python.org/projects/python/trunk/Objects/dictobject.c

jinak pole proměnné délky vzniká (pokud to dobře chápu) na stacku, takže ho nejde například vrátit z funkce, ne? což samozřejmě znemožňuje napsat intuitivní konkatenační funkci... ta musí pořád alokovat... (taky v dokumentaci to používají jako náhradu za alloca(), tzn lokální alokaci na stacku)

WILD_A: neznám?

XCHAOS: Docela sikovny, v kodu C99 to pouzivam, vubec C99 vidim jako posun do predu, akorat teda prenositelnost je mistama slabsi. Ale jinak C99 preferuju ve spolupraci s Pythonvskym pycparserem se pak daji delat pekny veci, jako generovat kod z komentaru a pod.

ha... pole proměnné délky v C99? (místo alokace...)
GNU C Language Extensions
http://tigcc.ticalc.org/doc/gnuexts.html#SEC76

http://stackoverflow.com/...s-the-worst-real-world-macros-pre-processor-abuse-youve-ever-come-across

baví mi např.:
#define ever (;;)
for ever {
...
}

ale já raději používám
#define loop while(TRUE)
:-)

jinak tohle
http://chaos-pp.cvs.sourceforge.net/chaos-pp/order-pp/example/bottles.c?revision=1.10&view=markup
pro mě určitě bude mocný zdroj inspirace :-) ale řekl bych, že moje nápady jsou stručnější:

http://chaos-pp.cvs.sourceforge.net/...vc/chaos-pp/order-pp/inc/order/rec.h?revision=1.6&view=markup

jinak samozřejmě, dostal jsem se k tomu přes hledání tohohle :)

https://gist.github.com/jcromartie/238308

ale samozřejmě, nemám tak nízké cíle.

BTW $ v názvech maker gcc toleruje kvůli nějaké historické kompatibilitě s VMS (a jde to zakázat, ale defaultně je to povolené)

Torvalds: I Made Community-Building Mistakes With Linux - Slashdot
http://linux.slashdot.org/...14/10/16/2214216/torvalds-i-made-community-building-mistakes-with-linux

uselessd vypada nadejne, uvidime jestli to adoptuje FreeBSD pak by to melo sanci.

no, tak vlastně první bugreport na systemd (resp. debian Jessie) je právě ten, že noťas (Eee, už dost obstarožní) mi nastartuje jen se zapojeným zdrojem, na baterky se to kousne (právě ve chvíli kdy se zavede kernel a startuje systemd). baterky jsou celkem v dobrým stavu, vydrží to na ně (když už to jednou nastartuje) skoro 4 hodiny.

asi s tím půjdu do fóra Debian, hmm