Re: [Dev-C++] Re: malloc , extra bytes ! Got even more urgent !

[Per W. <pw...@ia...>]

The _msize() you are referring to is part of heap-walk code. They are not
expected to be used for a normal application, but for debug code to verify
memory leaks etc.

There are NO standard method of keeping track of the size of a block of
memory. When you allocate the block, YOU have to assign the size to a
separate variable, in case you want to support dynamic resizing.

However, your malloc() or calloc() call will return your 1000 bytes of
available buffer space, to be used for whatever you want.

You may not assume anything about any extra bytes before the returned
pointer, or after your 1000 bytes of requested data. You may also assume
that - unless you have buffer overflow problems in the code - that you are
the sole owner of these 1000 byte of data, i.e. what you put there will
stay there until your RAM memory fails, or until you put something else
there.

The only thing you might assume, is that p+1000 is a valid pointer value,
even if you may not read/write at that location.

If these limitations are bothersome, they still represents the hard
reality.

/Per W


On Mon, 24 Feb 2003, veenurs wrote:

> Hi PW ,
>  Well , I guessed  it had something to do with the AT Least qualifier
> .But , I just can't help bothoring abt . the extra bytes !
>  It's lioke this- the memory created is used to store bytes of formatted
> data , which are then to be used by another part of application . So ,
> the extra bytes are screwing up the formatting and making 6the data
> useless !!
> The data itself is comming from   decryption  routines , so I cannot be
> sure of the exact size before decryption ( therefore , I NEED the
> malloc- realloc thing , would hate to use arrays .)
>
> MoreOvere , There is no such problem In VC++ ( I have a learner ed.), or
> LCC .
>
> Thanks , any other solution ?
>
> -Rahul.
>
> Per Westermark wrote:
>
> >Stop bothering about the size of the returned memory block.
> >
> >The allocation functions are only required to return AT LEAST the required
> >amount of memory, or a NULL pointer.
> >
> >Internally, they normally add 8-16 byte of internal header for
> >book-keeping on the heap, i.e. to allow the heap manager to walk free and
> >used memory block.
> >
> >Besides, most heap managers performs one of the following:
> >- rounds each block up to the nearest 8 or 16 byte increment.
> >- allocates the nearest larger 2^n size.
> >- uses the buddy system and allocates the nearest larger block size.
> >
> >As a result - for allocation of very small objects, it might often
> >be better to allocate a bunch of objects at a time, and keep pool of
> >evailable objects in a list.
> >
> >In the example below, the calloc call MUST use sizeof(BYTE). The
> >statement calloc(1000,BYTE) doesn't make sense.
> >
> >/Per W
> >
> >On Mon, 24 Feb 2003, Danny Roelofs wrote:
> >
> >
> >
> >>Hi,
> >>
> >>Well i dont realy know what youre doing with it.. and i never used calloc but it seems your allocating memory for 1000 bytes
> >>and a additional 8 bytes..  sizeof(byte) reserves 8 bytes in my opinion. is it perhaps that you have to do this:
> >>
> >>calloc(1000,BYTE) instead of calloc(1000,sizeof(BYTE))
> >>
> >>Well i actualy dont know.. i am just programming in C for just a month or so..
> >>
> >>
> >>  ----- Original Message -----
> >>  From: veenurs
> >>  To: dev...@li... ; ra...@ww...
> >>  Sent: Monday, February 24, 2003 1:16 AM
> >>  Subject: [Dev-C++] Re: malloc , extra bytes ! Somewhat urgent !
> >>
> >>
> >>
> >>
> >>  Hi !
> >>  It seems too simple .But what is it !?
> >>  if( (buffer = ( PBYTE )calloc( 1000 ,sizeof(BYTE) )) == NULL ){
> >>         ------
> >>        -------
> >>  }
> >>    size = _msize( buffer );
> >>
> >>  The size I get it is not 1000 , but 1008  !Same for malloc. Any subsequent call to realloc  does not add  the 8 bytes,though  .
> >>
> >>  [ Dev Cpp Version 4.9.7.0 ]
> >>  What's happening ?
> >>  BTW - "Generate debugging info" is OFF .
> >>  Thanks in advance .
> >>
> >>  -Rahul.
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
>