sizeof([ALLOCATED MEMORY])

[ballpointpenthief]

If I have malloc()'ed a pointer and want to read from it as if it were
an array, I need to know that I won't be reading past the last index.

If this is a pointer to a pointer, a common technique seems to be
setting a NULL pointer to the end of the list, and here we know that
the allocated memory has been exhausted. All good.

When this is a pointer to another type, say int, I could have a
variable that records how much memory is being allocated and use that
to track the size of the 'array'.
Alternatively, we could set the end of the 'array' to some kind of
error-code, such as 99 or MAX_INT.
I don't like either of these techniques.

So, what is a good way to stop a loop reading or writing past the
memory allocated to a pointer?
Or if possible, what is a good way of determining the size of memory
allocated to a pointer?

Cheers,
Matt

[Default User]

CBFalconer wrote:

"Tomás" wrote:

CBFalconer posted:

Apologies to Tomas.

No problem.

(Which reminds me I've to upgrade to the lastest version of XNews
some time soon... )

Your posts are invariably threaded to the wrong parent, and I
suspect the reference headers are fouled and incorrectly
truncated. This could well be caused by Xnews, which I understand
to be fairly reliable in general. So I encourage the upgrade.

Hmmm. Doing a quick look at the entire thread, Tomas's messages seem to
be properly threaded for me.


Brian

[CBFalconer]

Default User wrote:

CBFalconer wrote:

"Tomás" wrote:

CBFalconer posted:

> Apologies to Tomas.

No problem.

(Which reminds me I've to upgrade to the lastest version of XNews
some time soon... )

Your posts are invariably threaded to the wrong parent, and I
suspect the reference headers are fouled and incorrectly
truncated. This could well be caused by Xnews, which I understand
to be fairly reliable in general. So I encourage the upgrade.

Hmmm. Doing a quick look at the entire thread, Tomas's messages seem to
be properly threaded for me.

I now suspect it is netscapes fault here. My reply to Tomas has 21
references, your reply to me has 20 references. References are
supposed to be cut off at 20, by deleting the 2nd oldest, and it
appears NS has not done this. Then Tomas's reply ignored the last
ref linking to me, and cut things back correctly.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell. org/google/>
Also see <http://www.safalra.com/special/googlegroupsrep ly/>

[ais523]

Ion Gaztañaga wrote:

<snip>

I don't know any malloc implementation that does not store the size.

<snip>

IIRC, DOS has system calls that act identically to malloc, realloc, and
free, except that they only accept sizes that are multiples of 16
octets (which is the alignment of the resulting pointer). It would seem
reasonable for a DOS implementation of malloc to use these system calls
to do the allocation, rounding up sizes. From the C library, unless the
size was stored separately (which would impose a performance penalty),
the size of a malloc would be impossible to determine after the malloc
had been done. Although presumably the DOS kernel itself would be
keeping track of the size somewhere, there is no portable (within DOS)
method of determining what it is. (I don't know if this method was ever
used in practice on a DOS implementation. )

(Despite the OS-specifity, I think this is ontopic because a malloc
implementation which doesn't store the size was requested.)

[Ben Pfaff]

"ais523" <ai****@bham.ac .uk> writes:

Ion Gaztaqaga wrote:

<snip>

I don't know any malloc implementation that does not store the size.

<snip>

IIRC, DOS has system calls that act identically to malloc, realloc, and
free, except that they only accept sizes that are multiples of 16
octets (which is the alignment of the resulting pointer).
[...]

Most implementations round up to some granularity, but they store
the rounded size. DOS does this too, if I recall correctly.
--
"I don't have C&V for that handy, but I've got Dan Pop."
--E. Gibbons

[CBFalconer]

ais523 wrote:

Ion Gaztañaga wrote:

<snip>

I don't know any malloc implementation that does not store the size.

<snip>

IIRC, DOS has system calls that act identically to malloc, realloc, and
free, except that they only accept sizes that are multiples of 16
octets (which is the alignment of the resulting pointer). It would seem
reasonable for a DOS implementation of malloc to use these system calls
to do the allocation, rounding up sizes. From the C library, unless the
size was stored separately (which would impose a performance penalty),
the size of a malloc would be impossible to determine after the malloc
had been done. Although presumably the DOS kernel itself would be
keeping track of the size somewhere, there is no portable (within DOS)
method of determining what it is. (I don't know if this method was ever
used in practice on a DOS implementation. )

(Despite the OS-specifity, I think this is ontopic because a malloc
implementation which doesn't store the size was requested.)

And you haven't found one. The DOS system stores the size in the
16 bytes immediately preceding the assigned memory, so everything
is accessible via a segment register.

--
Some informative links:
news:news.annou nce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html