SplitStacks - GCC Wiki
http://gcc.gnu.org/wiki/SplitStacks

tak jsem dospěl někam sem:
c - Print out value of stack pointer - Stack Overflow
https://stackoverflow.com/questions/20059673/print-out-value-of-stack-pointer

napadlo mi, že kdyby alokátor seskupoval alokace podle hodnoty stack pointeru v momentě alokace, tak by při prvním volání po návratu z funkce mohl nějak vyhodnotit, které položky může už zahodit - bylo by to překvapivě bezpečné i pro nestandardní způsoby opuštění funkce (longjmp). takovýto "pseudo garbage collection" by šlo iniciovat i mimo volání alokátoru, kdyby bylo potřeba, ale alokátory by ho volaly minimálně pokaždé, když by jim došla pre-alokovaná paměť...

v podstatě by šlo o to vždy označit kus heapu jako asociovaný s aktuální hodotou stack pointeru. přičemž odmazávat by se měla vždy především "poslední předchozí", dle logiky věci.. akorát mi tam hapruje, jak jí odlišit např. od předposlední, která ještě může být platná, pokud se v té poslední nealokovalo nic.

alokátory paměti by pak v podstatě pro běžný život stačily dva, zhruba ekvivalentní prastarým Basicovským levelům "local" a "global" (což mimochodem velmi dobře odpovídá C světu do sebe nevnořovaných funkcí). lokální alokátor by pak podle nejlepších C zvyklostí pro označování privátních a lokálních hodnot mohl začínat podtržítkem...

REDGUY: jak to že tě tady vidím, když tě už mám v ignore? :-(

jinak ano, zamýšlím se nad tím, googlím... a alloca() asi fakt nebude řešením pro moje pokusy o nějakou sadu zásad pro bezstarostné programování v C... ale více nebudu psát v odpovědi pro tebe.

XCHAOS:

man bash

a hledej ulimit, switch -s. A zamysli se nad organizaci pameti a tim, jake dusledky ma pro moznou velikost stacku 8))

ANT_39: no ale jak je to vůbec s velikostí stacku např. v Linuxu? to je tam pořád omezení na fixní limit jako kdysi v DOSu?

XCHAOS: S alloca a VLA je problem, ze pro prilis velky alokace se muzes snadno dostat mimo stack. Tusim v glibc a elfutils jsem normalne videl kod ve stylu if (x > a lot) malloc(x) else alloca(x) (a odpovidajici tomu free nebo nic). V linuxovym kernelu se dela na nahrade vsech pripadu alloca a VLA za alkoace na halde, mimo jine protoze ten stack overrun je potencialni bezpecnostni riziko.

popravdě, jestli ještě budu někdy cokoliv dělat se stringama v C, tak uvažuju o tomto:
Advantages of Alloca (The GNU C Library)
https://www.gnu.org/software/libc/manual/html_node/Advantages-of-Alloca.html

Ahoj, budu vdecny za jakykoliv nazor. Ted zrovna resim, proc mi interaktivni moc nabehne do prazdne obrazovky. Ale nejsem si jisty proc.
Je to prohlizec ans souboru pro utf-8 terminaly. Je to psany tak nejak zbesile, ale pro svoje ucely mi to staci.
http://elinks.xf.cz/pub/ansiu/

ALMAD: Neznal jsem, diky!
XCHAOS: Vo vypada, ze zpatky dostanes promisu.

ALMAD: Sice základní princip, že to mají v paměti, se mi líbí.. tohle ale zní trochu podezřele: Time-traveling RPC: Cap’n Proto features an RPC system that implements time travel such that call results are returned to the client before the request even arrives at the server!
:-)

REDGUY: tenhle kód...
#include "sqlite3-1.c"
#include "sqlite3-2.c"
#include "sqlite3-3.c"
#include "sqlite3-4.c"
#include "sqlite3-5.c"
#include "sqlite3-6.c"
#include "sqlite3-7.c"
....mi popravdě připomíná jeden můj header file :-)

XCHAOS: Jo, jasne, otravovat ostatni, at za tebe udelaji neco, co bys mohl udelat sam. Pozoruhodnej pristup 8)

JANFROG: tak mě šlo o to, jaké struktury v té sdílené paměti mít, že jo :-) asi nějaké zámky, aby do toho mohlo i více vláken zapisovat paralelně... nevím, jak to přesně dělá ten Redis. život mi skutečně naučil, že znovuvynalézání kola bývá pracné...