Re: [OT] What kind of data is is returned by 'new' ?
Re: [OT] What kind of data is is returned by 'new' ?
- Subject: Re: [OT] What kind of data is is returned by 'new' ?
- From: Dirk Stegemann <email@hidden>
- Date: Sun, 10 Jul 2005 14:08:20 +0300
Hello,
Am 09.07.2005 um 20:19 schrieb Bill Bumgarner:
On Jul 8, 2005, at 4:26 PM, Dirk Stegemann wrote:
Actually, this is great because I thought of using such buffers as
seed to a random function. So, I'm wondering if it's posssible for
someone hassling around with my app to circumvent this randomising
mechanism by somehow telling the system to *always* make 'new'
return zero'd buffers... e.g., in DEBUG mode compiled applications
will get allocated memory filled with 0xCC values (on Win32 systems).
The bytes aren't random. They are very much predetermined values
based upon the state of your application prior to that call to
malloc(). They may seem random, but it is very likely a rather
small set of values.
See the 'urandom' man page. If you want a good random seed, open /
dev/random (or /dev/urandom) and read however much data you might
want.
You're right, of course.
On the other hand, though the quality of such "randomized" memory may
not proof best, for my program it seems far better to use data that
isn't as reliably random as other well-known high-quality random
sources can privide than using such sources by accessing public APIs.
My application does read and write data from and to memory very
frequently, and sometimes treating e.g. a 128-byte allocated non-
initialised buffer as 1024 bit-value might seem far less obvious to
an adversary who was just breaking for my random() calls, I guess.
---
Am 09.07.2005 um 17:10 schrieb Clark Cox:
It is still possible that new will return a zero filled buffer if, for
instance, there is not enough memory in the currently allocated pools
to satisfy your request.
Ok, that's an important piece of information!
It might work now, but you have no guarantee that it will continue to
do so. You should *never* rely on the values of uninitialized memory.
At the moment I'm happy that I don't have to rely on *always* getting
zero'd memory... ;-]
---
Again, thanks for all the input.
Dirk Stegemann
BTW:
It's kind of sad that one has to "reply-all" to ensure that a mail
gets sent to the list; I got some more useful postings to this
discussions as were received by the other list members. It would be
nice to receive the list postings via the <xcode-
email@hidden> mail address, so simply replying will send a
response directly to the list... I'm aware, though, that this topic
has risen once in a while without leading to a change, so I suppose
it's a way to cut down traffic...?
_______________________________________________
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