Re: I have a 0-day exploit, but don't want to tell you what it is
Re: I have a 0-day exploit, but don't want to tell you what it is
- Subject: Re: I have a 0-day exploit, but don't want to tell you what it is
- From: Michael Crawford <email@hidden>
- Date: Tue, 30 Jul 2013 14:12:09 +0000
There are some things that are easy or at least sensible in one
language, that in the other are difficult or even impossible.
For example, in Objective-C, one could prompt the user to enter the
name of a selector, then just call that selector directly, without any
particular requirement of knowing when the code was written, that that
selector was actually implemented anywhere in the program.
To do something conceptually similar in C++, one would have to use
some manner of string matching to look up a pointer to a function in a
table, then dereference that function pointer. While I can conceive
of ways to grow that table after the binary is published, to actually
do so would be difficult.
There are many nice aspects to Objective-C's dynamic nature, as well
as that of the original Smalltalk upon which Objective-C is based.
But IMHO, Apple's overwhelming reliance on Objective-C, Cocoa and
Cocoa Touch is misplaced. "When all you have is a hammer, everything
looks like a nail".
The ability of C++ to unwind the stack when you throw an exception is
very helpful. From time to time I use C++ exceptions for purposes
_other_ than error reporting, say to send a message from deep within
some code, to the enclosing code. If you write exception-safe code,
you can do such things as repeatedly throw the same exception without
leaking any memory, locks, file handles, sockets or other resources,
while repeatedly retrying the same code, for example to try out
different input parameters, whose ultimate effect cannot be easily
predicted in advance.
When I worked with Haim Zamir (http://www.baliset.com/) at Live
Picture, he implemented an algorithm that yielded better results if it
used more memory, but whose actual memory consumption was not possible
to predict from his algorithms input parameters. The Macs of the day
- 1997 - often had quite limited memory, and could not always be
counted upon to have Virtual Memory enabled. So if any of his
allocations ever failed, he would safely throw an exception, then
retry the entire algorithm, but with different inputs that were likely
to use less memory.
It's not exactly easy to write exception-safe C++, but the methods are
well documented. Most of the required methods are easy. But in my
actually experience, very little of the C++ code I've ever found
written by others, comes anywhere close to being exception-safe.
Mike Crawford
email@hidden
http://www.warplife.com/
Available for mobile development work in or near Portland, Oregon.
On Tue, Jul 30, 2013 at 1:29 PM, Scott Ribe <email@hidden> wrote:
> On Jul 30, 2013, at 7:16 AM, Willie Pierce <email@hidden> wrote:
>
>> wouldn't mixing the code like that lead to a lot more headache down the line.
>
> Done carelessly, yes.
>
> Well-designed and carefully controlled, no. You can wind up with simpler code, and, my reason for it in many cases, much faster code.
>
> --
> Scott Ribe
> email@hidden
> http://www.elevated-dev.com/
> (303) 722-0567 voice
>
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden