Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Wired binary behavior

Reply
Thread Tools

Wired binary behavior

 
 
Richard
Guest
Posts: n/a
 
      08-27-2007
Flash Gordon <(E-Mail Removed)> writes:

> Ark Khasin wrote, On 27/08/07 21:20:
>> CBFalconer wrote:
>>> Ark Khasin wrote:
>>>> Walter Roberson wrote:
>>>>
>>> ... snip ...
>>>>> Therefore, if you happen to be overwriting an array or before the
>>>>> end of an array or writing into free memory, whether you have
>>>>> allocated a variable or not in a certain relative location in the
>>>>> code can affect exactly what happens to be at the place being
>>>>> overwritten, and thus can affect whether you see an obvious crash
>>>>> or not.
>>>> If your assessment is correct, so is my claim that arrays on stack
>>>> are evil. This claim had been thoroughly rebuffed in this NG though.
>>>
>>> No, the thing that is evil is writing into memory that is not part
>>> of the destination object.
>>>

>> [Also to Richard Bos]
>> Let's face it: we mortals are fallible. When we admit that our
>> errors do sometimes go out in the wide world, it's appropriate to
>> think about minimizing the impact of an error. IMHO, corrupting the
>> heap is not as disastrous as corrupting a stack.

>
> IMHO corrupting either is a complete disaster.


Of course. The previous statement is simply ridiculous. The heap could
hold information as important, if not more so, information than the
stack. Not only that but the side effects might take an eon to debug
since it is not immediately apparent - it could manifest itself in one
of a million undefined ways including incorrect mallocs, deallocs, data
reads, password caches etc etc etc. It is far more likely, especially
under the scope of a good debugger, that a prudent programmer would
notice a stack corruption ESPECIALLY since the stack is invariably
dedicated its own inspection window in the debuggers I have used.
 
Reply With Quote
 
 
 
 
Ark Khasin
Guest
Posts: n/a
 
      08-29-2007
Richard wrote:
> Flash Gordon <(E-Mail Removed)> writes:
>
>> Ark Khasin wrote, On 27/08/07 21:20:
>>> CBFalconer wrote:
>>>> Ark Khasin wrote:
>>>>> Walter Roberson wrote:
>>>>>
>>>> ... snip ...
>>>>>> Therefore, if you happen to be overwriting an array or before the
>>>>>> end of an array or writing into free memory, whether you have
>>>>>> allocated a variable or not in a certain relative location in the
>>>>>> code can affect exactly what happens to be at the place being
>>>>>> overwritten, and thus can affect whether you see an obvious crash
>>>>>> or not.
>>>>> If your assessment is correct, so is my claim that arrays on stack
>>>>> are evil. This claim had been thoroughly rebuffed in this NG though.
>>>> No, the thing that is evil is writing into memory that is not part
>>>> of the destination object.
>>>>
>>> [Also to Richard Bos]
>>> Let's face it: we mortals are fallible. When we admit that our
>>> errors do sometimes go out in the wide world, it's appropriate to
>>> think about minimizing the impact of an error. IMHO, corrupting the
>>> heap is not as disastrous as corrupting a stack.

>> IMHO corrupting either is a complete disaster.

>
> Of course. The previous statement is simply ridiculous.


Your righteousness is ridiculous, but in a complex way.

>The heap could
> hold information as important, if not more so, information than the
> stack. Not only that but the side effects might take an eon to debug
> since it is not immediately apparent - it could manifest itself in one
> of a million undefined ways including incorrect mallocs, deallocs, data
> reads, password caches etc etc etc. It is far more likely, especially
> under the scope of a good debugger, that a prudent programmer would
> notice a stack corruption ESPECIALLY since the stack is invariably
> dedicated its own inspection window in the debuggers I have used.

Bugs don't like bright light; they tend to show up when you are not looking.
It is not uncommon in critical apps to wrap malloc so as to allocate
areas with guards on one or both sides.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
VERY WIRED BEHAVIOR OF NERO 7.7.5.1 tanyaru@hotmail.com DVD Video 4 04-06-2007 07:45 AM
Wireless can't see Wired, Wired Can't Access Wireless UFGrayMatter Wireless Networking 0 08-14-2006 01:26 AM
wireless can't access wired. But Wired can access wireless =?Utf-8?B?ZGZhdG92aWM=?= Wireless Networking 5 02-05-2005 08:07 AM
Wired Tools of 2004 from Wired magazine : the Cameras !!! Mike Henley Digital Photography 0 12-06-2004 02:32 AM
undefined behavior or not undefined behavior? That is the question Mantorok Redgormor C Programming 70 02-17-2004 02:46 PM



Advertisments