Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Static memory overrun help

Reply
Thread Tools

Static memory overrun help

 
 
spoc
Guest
Posts: n/a
 
      08-30-2004
I am using VC++6 and Numega bounds checker and have been getting many STATIC
MEMORY OVERRUN errors (boundschecker) while trying to track down bugs. An
example is below:

void func()
{
static int midSection[ 10 ][ 10 ];

memset(&midSection, 0, sizeof(midSection));
}

For the life of me I can't see why this should cause an error. I also get
the error for the following:


void func()
{
static char f[ 100 ];

strcpy(f, funcb() ); // where funcb() is guaranteed to return a string <
100
}

Maybe it's just bounds checker? Anyone help?


 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      08-30-2004
spoc wrote:
> I am using VC++6 and Numega bounds checker and have been getting many STATIC
> MEMORY OVERRUN errors (boundschecker) while trying to track down bugs. An
> example is below:
>
> void func()
> {
> static int midSection[ 10 ][ 10 ];
>
> memset(&midSection, 0, sizeof(midSection));
> }
>
> For the life of me I can't see why this should cause an error. I also get
> the error for the following:
>
>
> void func()
> {
> static char f[ 100 ];
>
> strcpy(f, funcb() ); // where funcb() is guaranteed to return a string <
> 100
> }
>
> Maybe it's just bounds checker? Anyone help?


There is nothing in this code that would suggest memory overrun. However,
if you intended to just _initialise_ 'midSection' in the first 'func', you
shouldn't memset it every time the function runs. You just need to do

static int midSection[10][10] = { 0 };

which initialises it to 0s. Although, IIRC, even that is unnecessary due
to the fact that all objects of static storage duration are zero-
initialised anyway. Again, that's if you just needed it to initialise. If
you do need it cleaned up every time, your code is fine.

If I were to nit-pick, I'd change

memset(&midSection, ...

to

memset(&midSection[0][0], ...

but it really shouldn't make any difference in the execution because the
address of an array and the address of the first element of the array are
the same (although their types are different).

Victor
 
Reply With Quote
 
 
 
 
ma740988
Guest
Posts: n/a
 
      09-02-2004
[....]
>
> If I were to nit-pick, I'd change
>
> memset(&midSection, ...
>
> to
>
> memset(&midSection[0][0], ...
>
> but it really shouldn't make any difference in the execution because the
> address of an array and the address of the first element of the array are
> the same (although their types are different).
>

Could you elaborate on the type differences here? I think I'm
following you but ....

> Victor

 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      09-04-2004
"ma740988" <(E-Mail Removed)> wrote...
> [....]
> >
> > If I were to nit-pick, I'd change
> >
> > memset(&midSection, ...
> >
> > to
> >
> > memset(&midSection[0][0], ...
> >
> > but it really shouldn't make any difference in the execution because the
> > address of an array and the address of the first element of the array

are
> > the same (although their types are different).
> >

> Could you elaborate on the type differences here? I think I'm
> following you but ....


If 'a' is declared as

T a[N];

then its type is "array of N T". The expression '&a' then has the type
"a pointer to an array of N T". The expression 'a[0]' has the type "T&",
and '&a[0]' has the type "pointer to T", which is, incidentally, the type
of the expression a. The name of an array decays to the pointer to the
type of the element of the array.

With a two- and more-dimensional arrays, the address where the array
begins is the address of the first element, and if you need to iterate
over those elements using a pointer arithmetic, it's better to use the
pointer to an element than a pointer to the entire array. T* when
incremented will point to the next element. T (*)[N] when incremented
will point past the end of the array.

For memset there is no need to worry because it operates in terms of
bytes internally. But if you somehow encounter a function template,
then correct types can be very important.

Victor


 
Reply With Quote
 
Old Wolf
Guest
Posts: n/a
 
      09-05-2004
Victor Bazarov <(E-Mail Removed)> wrote:
> spoc wrote:
> > I am using VC++6 and Numega bounds checker and have been getting many STATIC
> > MEMORY OVERRUN errors (boundschecker) while trying to track down bugs. An
> > example is below:
> >
> > void func()
> > {
> > static int midSection[ 10 ][ 10 ];
> > memset(&midSection, 0, sizeof(midSection));
> > }

>
> If I were to nit-pick, I'd change
>
> memset(&midSection, ...
> to
> memset(&midSection[0][0], ...
>


Why? The first is fine, the second is technically UB (you are
passing it a pointer to one int, and you overflow bounds by
writing 100 ints to that pointer).
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      09-06-2004
"Old Wolf" <(E-Mail Removed)> wrote...
> Victor Bazarov <(E-Mail Removed)> wrote:
> > spoc wrote:
> > > I am using VC++6 and Numega bounds checker and have been getting many

STATIC
> > > MEMORY OVERRUN errors (boundschecker) while trying to track down bugs.

An
> > > example is below:
> > >
> > > void func()
> > > {
> > > static int midSection[ 10 ][ 10 ];
> > > memset(&midSection, 0, sizeof(midSection));
> > > }

> >
> > If I were to nit-pick, I'd change
> >
> > memset(&midSection, ...
> > to
> > memset(&midSection[0][0], ...
> >

>
> Why? The first is fine, the second is technically UB (you are
> passing it a pointer to one int, and you overflow bounds by
> writing 100 ints to that pointer).


This is nonsense. Since there are 100 ints at that address, there
is no overflow of any bounds and there is no UB.

V


 
Reply With Quote
 
Old Wolf
Guest
Posts: n/a
 
      09-08-2004
"Victor Bazarov" <(E-Mail Removed)> wrote:
> "Old Wolf" <(E-Mail Removed)> wrote...
> > Victor Bazarov <(E-Mail Removed)> wrote:
> > > spoc wrote:
> > > > void func()
> > > > {
> > > > static int midSection[ 10 ][ 10 ];
> > > > memset(&midSection, 0, sizeof(midSection));
> > > > }
> > >
> > > If I were to nit-pick, I'd change
> > > memset(&midSection, ...
> > > to
> > > memset(&midSection[0][0], ...

> >
> > Why? The first is fine, the second is technically UB (you are
> > passing it a pointer to one int, and you overflow bounds by
> > writing 100 ints to that pointer).

>
> This is nonsense. Since there are 100 ints at that address, there
> is no overflow of any bounds and there is no UB.


That doesn't answer the first question: why do you prefer
midSection[0] (equivalent to &midSection[0][0]) to &midSection?
For me, the least error-prone method of using the mem* functions
is to pass the address of the object that is being set.
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      09-08-2004
Old Wolf wrote:
> "Victor Bazarov" <(E-Mail Removed)> wrote:
>
>>"Old Wolf" <(E-Mail Removed)> wrote...
>>
>>>Victor Bazarov <(E-Mail Removed)> wrote:
>>>
>>>>spoc wrote:
>>>>
>>>>>void func()
>>>>>{
>>>>> static int midSection[ 10 ][ 10 ];
>>>>> memset(&midSection, 0, sizeof(midSection));
>>>>>}
>>>>
>>>>If I were to nit-pick, I'd change
>>>> memset(&midSection, ...
>>>>to
>>>> memset(&midSection[0][0], ...
>>>
>>>Why? The first is fine, the second is technically UB (you are
>>>passing it a pointer to one int, and you overflow bounds by
>>>writing 100 ints to that pointer).

>>
>>This is nonsense. Since there are 100 ints at that address, there
>>is no overflow of any bounds and there is no UB.

>
>
> That doesn't answer the first question: why do you prefer
> midSection[0] (equivalent to &midSection[0][0]) to &midSection?
> For me, the least error-prone method of using the mem* functions
> is to pass the address of the object that is being set.


I prefer using &midSection[0][0] because it has the correct type --
a pointer to int. Not a pointer to an array of 10 arrays of 10 ints,
not a pointer to an array of 10 ints.

See my reply to the OP earlier in this thread.

Victor
 
Reply With Quote
 
Old Wolf
Guest
Posts: n/a
 
      09-09-2004
Victor Bazarov <(E-Mail Removed)> wrote:
> >>"Old Wolf" <(E-Mail Removed)> wrote...
> >>>Victor Bazarov <(E-Mail Removed)> wrote:
> >>>>spoc wrote:
> >>>>
> >>>>> void func()
> >>>>> {
> >>>>> static int midSection[ 10 ][ 10 ];
> >>>>> memset(&midSection, 0, sizeof(midSection));
> >>>>> }
> >>>>
> >>>>If I were to nit-pick, I'd change
> >>>> memset(&midSection, ...
> >>>>to
> >>>> memset(&midSection[0][0], ...
> >>>
> >>>Why?

> I prefer using &midSection[0][0] because it has the correct type --
> a pointer to int. Not a pointer to an array of 10 arrays of 10 ints,
> not a pointer to an array of 10 ints.
>
> See my reply to the OP earlier in this thread.


"pointer to int" isn't the correct type. You aren't filling a
block of ints with int 0. You are filling an object with char 0.
memset fills byte by byte (even though the memset function takes
a parameter of type int for the fill char, it converts it to a
char in order to fill).

You mentioned needing correct types for template functions: the
equivalent of memset is std::fill_n<charT *, size_t, charT>().
If you call std::fill_n(ptr, 100, '\0') then ptr should be a
pointer to char (not a pointer to int).

I interpret memset as "fill an object (given a pointer to it
and its size). So passing a pointer to the object (ie. &midSection)
is correct.

This is of course all moot, as memset takes a (void *) and the
standard practically guarantees that (void *)&midSection ==
(void *)&midSection[0][0].
 
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
input error - type overrun nunyo.dambidness@gmail.com Cisco 17 07-24-2009 10:56 PM
Overrun errors on Etherchannel Interfaces Tecmessa Cisco 1 07-16-2008 09:07 PM
buffer overrun error Peter Computer Support 7 04-28-2007 09:53 PM
SECURITY ADVISORY [PSF-2006-001] Buffer overrun in repr() for UCS-4encoded unicode strings Anthony Baxter Python 0 10-12-2006 07:31 AM
Problem with nested class or array overrun. J. Campbell C++ 7 08-17-2004 04:15 AM



Advertisments