logs archiveBotHelp.net / Freenode / #2f30 / 2015 / August / 13 / 1
Evil_Bob
https://www.youtube.com/watch?v=iq_d8VSM0nw
FRIGN
yo, Hitljo
can you give me an update on the scc progress?
I've seen dozens of commits, but what's the overall progress?
gn8
k0ga
FRIGN: at this moment the declarations are finished, except initializers and bit fields
expressions are finished too
FRIGN
cool!
what is still missing for C99?
k0ga
I was talking about c89 !!!!
missed things for c99?, VLA
I discarded long time complex types
s/complex/ago /&/
stateless
lol
FRIGN
k0ga: okay, that may sound dumb, but when people specify a VLA
why not just substitute it with a pointer + malloc and then a free at the end of the function
?
given how VLA's behave, the malloc is unchecked
k0ga
FRIGN: yes, but it is faster and easier to handle
FRIGN
yeah sure
I mean as a preprocessing step ;)
so you support VLA's
if you encounter a VLA:
k0ga
the problem with VLAs for the compiler is sizeof
FRIGN
what do you mean?
k0ga
you have to store the size in some hidden part of the VLA
stateless
FRIGN, you don't know the size at compile time, not always that is
k0ga
int v[n];
sizeof(v);
stateless
has to grab n from somewhere yes
FRIGN
ah okay, k0ga
k0ga
what is the value of this sizeof?
FRIGN
k0ga: afaik, for arrays it's n
stateless
k0ga, is the size stored on the stack, let's say before v?
k0ga
stateless: this is typical implementation I guess
stateless
FRIGN, the problem is that n is not known at compile time, it is not the same as int v[5]; so you have to store n on the stack
I suppose this complicates the compiler
FRIGN
THAT'S BULLSHIT YO!
k0ga
stateless: think what happens when you do something like:
stateless
so every time you use sizeof(v) in the code it has to reference the value on the stack that gives the size
FRIGN
btw, why did they invent VLA's?
they make no sense
stateless
FRIGN, to avoid malloc
FRIGN
that's so retarded
stateless
same reason alloca existed
FRIGN
what is the general vibe btw?
avoid VLA's?
stateless
yes
k0ga
uhmmm, I don't find the example
FRIGN
okay well, I'm okay with the compiler just saying: well, fu*k you dude. remove those VLA's already :P
k0ga
but there are problems when you pass this VLA to a function, because you break the rule that any pointer inside of the buffer is a valid pointer
FRIGN
VLA's are just broken
k0ga
the made VLA's optional in C11
and complex types too
another thing that is missed now in scc is compound literals
stateless
k0ga, so how does that work then? does the compiler assume that any pointer inside the buffer must be valid?
atmc
VLA's shouldn't be needed for any use case
stateless
given that it doesn't know the size
k0ga
stateless: I don't know
stateless
even if the pointer is outside of the buffer
it is probably easier to just use alloca
if you want VLAs
:P
k0ga
yeah
stateless
it doesn't put any burden on the compiler at least
well it is not standardized but it is retarded to do so anyway (and as you say VLAs are optional in C11)
k0ga
and you can do things with alloca that are not possible with VLA's
stateless
like?
k0ga
while (p = input()) {new = alloca(sizeof(*new); list->next = new; new->f = p; list = new;}
stateless
FRIGN, also VLAs + alloca were deemed useful when doing longjmp or siglongjmp because you could unwind lots of stack frames without having to cleanup all memory allocations between the target and source stack frame
ah yes
k0ga, linked lists on the stack :P
k0ga
shorter description ^^!
stateless
you can do that recursively I think without alloca and without VLAs with compound literals
k0ga
yes, but then you use more stack spae
stateless
yes
k0ga
s/spae/space/
stateless
well that's what you get
if you want to be ultra portable
:P
k0ga
yeah, nothing is free
FRIGN
alloca is for people who are too dumb to reuse their buffers :P
stateless
I think kernel programmers are more inclined to use alloca
coming from a 4kB kernel stack to a 8MB stack
you are like fu*k it, I will put it on the stack
k0ga
I come from assembly programming, and for me it is the logical way when sizes are small
stateless
if it is guaranteed to be bounded just allocate the maximum size without the VLA
if it is not guaranteed to be bounded, use malloc
quake 2 doesn't have a single alloca
quake 1 doesn't either
FRIGN
stateless: thing is, just always use alloca. malloc can handle small buffers efficiently in the backend
this is a premature optimization we shouldn't be responsible for.
stateless
FRIGN, yeah
you mean always use malloc :P
k0ga
there is a portable implementation of alloca
FRIGN
ah yeah
stateless
FRIGN, ideally you would use malloc only when required and use static sized buffers on the stack otherwise (not VLAs just char path[PATH_MAX] type of thing)
FRIGN
malloc
stateless
too much malloc sucks
FRIGN
stateless: it's dynamic ;)
« prev 1 2 3 4 5 6 next »