49 ms·
you could of course alloca(1) which would also give you the address of the end of the stack plus one byte, but this time using functionality that's inside the s
by pilif 15y ago
you could of course alloca(1) which would also give you the address of the end of the stack plus one byte, but this time using functionality that's inside the specification of alloca()
- FooBarWidget 15y agoThat's what I did, I replaced alloca(0) with alloca(sizeof(void *)). Unfortunately llvm-gcc still emitted wrong code in other parts of the program which caused Ruby to crash in strange ways. The post is not so much a complaint about alloca(0), it was just an example of where I thought llvm-gcc is broken.
- kenferry 15y agollvm-gcc is not going to be globally broken or not broken. Like all software, it has bugs, and the bugs may or may not affect you. An 'example' that is actually a bug in the program is not very convincing of generic broken-ness. Try again if you want to make that case. Do you want __builtin_frame_address, by the way? Still target specific, but explicit.
- FooBarWidget 15y agoIt is not just one example. Take a look at http://llvm.org/bugs/show_bug.cgi?id=9891 http://llvm.org/bugs/show_bug.cgi?id=9891 which is marked as WONTFIX. Shipping an unmaintained compiler certainly screams broken to me. __builtin_frame_address looks interesting, I'll take a look.