(This, by the way, refers to nested functions in C code. A gcc extension)
"gcc's implementation of nested functions involves placing code on the stack and then executing it. Stack execution is a common operation in malicious code, particularly as a side effect of buffer overflows. While the proper fix is of course to not make buffer overflows possible in the first place, disabling stack execution decreases the likelihood that a buffer overflow or other stack-smashing attack will be exploitable."
"In future releases of Mac OS X, we may disable stack execution. (Obviously we'll have to keep binary compatibility in mind when or if we do that.) Nested functions were disabled to help prepare for that change."
"As for whether nested functions will be re-enabled, if someone contributes a patch to GCC to change the nested function implementation to not rely on stack execution, presumably there'd be a chance they'd be re-enabled."
Are Apple evil or awesome for doing this? (discussion!)
How would you go about implementing nested functions without using stack execution? (technical challenge!)
Or we could go back to flaming Java.
Name:
Anonymous2006-01-03 19:41
i've never seen nested functions used in C code, nor did i know that any compiler even had that feature.
so who's complaining about this, anyway?
Name:
Anonymous2006-01-03 20:53
Why do you want that?
BTW, I don't think it'd work on x86 or x86-64 processors (like AMD's Athlon 64) with the NX bit in use by the OS either.
The ages of dynamic machine code, self-modifying code, etc. are gone. Now all you want that is to exploit the crap out of stupid MSIE users. It's better to give up on these techniques.
Name:
Anonymous2006-01-04 22:39
>>1
Someone may eventually commit this patch, because nested functions don't work on OpenBSD or embedded targets either.
Name:
Anonymous2006-01-04 23:01
not like anyone uses nested funs anyway
Name:
Anonymous2006-01-05 2:56
>>1
You can implement nested functions without executing from the stack by just always inlining them (but it won't work for recursive functions).
Or just implement them like regular functions (that is, put them in the text section, etc), and make sure at compile time that they only get called by whoever they are nested in.
Name:
Anonymous2006-01-05 3:26
Name mangling should do the trick. If there's a function foo() nested in function bar(), parse it as foo$bar() or something, with extra arguments to pass bar()'s local variables.
Name:
Anonymous2006-01-05 6:01
>>1
LOL you fags still use macs? The only thing keeping that shitty company alive is the iPod! AHHAHAAHaHahahahahhaha
Name:
Anonymous2006-01-05 6:43
>>8
2005 was one of the two best years for Mac sales ever :confused:
Name:
Anonymous2006-01-05 6:45
>>6
The difficult part is that you're allowed to pass the nested function around as a pointer, and it has to be able to access variables of its parent as necessary, and it has to be thread-safe, and you can't secretly add new arguments to every function that's going to call it.
Name:
Anonymous2006-01-05 8:56
>>9
You need to learn to recognize random trolls and just ignore them.
Name:
Anonymous2006-01-05 10:13
>>9
iPod is actually considered a "Mac" so that would explain it...but only if that were actually true though
Name:
Anonymous2006-01-05 16:40
Welp, I suppose teh mac won't be supporting any languages that rely on trampolines for other reasons either. That's that for the likes of e.g. forth and... well I'm sure there are others, trampolines are just too good a technique to pass up. Maybe there needs to be a, you know, second stack in the ABI that's used exclusively for trampolines, is not connected to the ordinary stack in any way and thus can't be used for stack smashing attacks?
Then again I've been up for 35 hours now, if this sort of thing makes sense to me then it likely looks like fucking crap to the rest of you...
Name:
Anonymous2006-01-06 7:30 (sage)
Mac OS X is what we call an "operating system", it is not a "programming language" and there is no such thing as a function in an "operating system."
Name:
Anonymous2006-01-06 10:45 (sage)
>>14
If you had any insight into the matter at all, you'd know "nested functions are not supported on MacOSX" is an exact quote of the error message Apple's fork of gcc gives when faced with a nested function in C.
Mmmm... nested functions in C? Why? I've never needed to use them. Fuck them, fuck them in the bellybutton.
Name:
Anonymous2011-07-28 19:32
I have no idea why people have so much trouble avoiding buffer overflows. It's like not knowing how big your car is when you're driving. Maybe it has to do with teaching languages like Java where memory is regarded as infinite.
Name:
Anonymous2011-07-28 21:03
Nested functions in GCC are stupid and non-standard. Dynamic execution from the stack is retarded.
Apple is dropping GCC completely from Mac OS X in the near future--they aren't investing tons of effort into Clang/LLVM for nothing. So even if a patch is introduced, don't except it to be availabe on OS X. Hell, even FreeBSD is transitioning completely to Clang/LLVM.
Recent versions of Clang are capable of performing numerous tail-call optimizations in almost all circumstances, the only restriction is it doesn't work on functions with variadic argument lists (such printf(char const* f, ...);).
C++0x/C++1x has lambdas/closures, and Clang also supports Apple's blocks extensions which is a somewhat simpler and more restricted implementation of lambdas/closures than the C++11 version.
There's no reason to use GCC style nested functions when the alternatives are superior.
>>24 There's no reason to wear my sister's black leggings when I already have a raging boner.
Name:
Anonymous2011-07-28 22:13
>>25
You can purchase your own pair for like $8.00 at Target.
Name:
Anonymous2011-07-28 22:18
>>24
Nested functions are a form of information hiding and are useful for dividing procedural tasks into sub tasks which are only meaningful locally; it avoids cluttering other parts of the program with functions, variables, etc. unrelated to those parts. Nested functions therefore complement other structuring possibilities such as records and objects.
In languages with nested functions, functions may normally also contain local constants, and types (in addition to local variables, parameters, and functions), encapsulated and hidden in the same nested manner. This may further enhance the code structuring possibilities.
that doesn't even sound possible to me, as two different invokations of the parent function could return a pointer to a nested function somewhere, and then the code executing the nested function pointer doesn't have the information needed to find the appropriate parent stack frame/or however its local variables are stored. Some extra information would need to be stored with the function pointer right? Is this even possible to do without forcing a new type for a nested function pointer?
>>27
Right, so with lambdas/blocks there is no point in nested functions. As GCC's implementation required an executable stack, that's two fewer problems.
It is an alternative to using global variables, or continuously passing in a reference or pointer to a needed variable into the calls of the nested function. It can be nice if you have a parent function which then calls some other function which is recursive, but the recursive function needs to modify variables local to the parent function while they run. A good example would be the time variable in the typical text book version of Depth First Search, which is supposed to increment every time a node is discovered, and used as a stamp value for their discovery and finish times.