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

[Zara]

On Tue, 16 May 2006 07:58:28 GMT, "Tomás" <NU**@NULL.NULL > wrote:

while ( *dest = *source ) ++dest, ++source;

This one doesn't do a redundant final incrementation.

for(;*dest = *source;++dest, ++source);

Nor does this one.

while ( *dest++ = *source++ );

This one does however.

for(;*dest++ = *source++;);

As does this one.
-Tomás

Dont jump too fast to conclusions:

for(;*dest=*sou rce;++dest,++so urce);

is compiled under one very popular compiler as the following flow in
pseudo-code

JUMPTO :TEST:
:LOOP:
READ dest
INC
STORE dest
READ source
INC source
STORE source
:TEST:
READ source
READ @source
READ dest
STORE @dest
IFNOTZERO JUMPTO :LOOP:

for(;*dest++=*s ource++;);

is compiled under same compiler as the following flow in pseudo-code

:LOOP:
READ source
READ @source
INC source
STORE source
READ dest
STORE @dest
INC dest
STORE @dest
IFNOTZERO JUMPTO :LOOP:

Which is more optimized in code-size and, probably, also in time.
"Let the profiler tell you" is good advice, always.

Best regards,

Zara

[CBFalconer]

"Tomás" wrote:

pete posted:

There are some style guidlines against writing code like this:
while (*dest++ = *source++);
because it looks like an accident.

while (*dest++ = *source++); /* Not an accident */

Not only have you fouled up the attributions, but you have fouled
the quote. It is considered very bad form to edit quotations. I
actually wrote:

while (*dest++ = *source++) continue;

as an analogy to something else.

--
"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/>

[Flash Gordon]

Tomás wrote:

while ( *dest = *source ) ++dest, ++source;

This one doesn't do a redundant final incrementation.

for(;*dest = *source;++dest, ++source);

Nor does this one.

while ( *dest++ = *source++ );

This one does however.

for(;*dest++ = *source++;);

As does this one.

Yet as was noted by the person posting them, they all produced the same
machine code thus illustrating that there is no point in selecting one
for reasons of efficiency. At least, not unless you have verified that
on your implementation it really will be more efficient.

No doubt this was in a situation where dest and source were not used
after the loop.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[Flash Gordon]

CBFalconer wrote:

"Tomás" wrote:

pete posted:

There are some style guidlines against writing code like this:
while (*dest++ = *source++);
because it looks like an accident.

while (*dest++ = *source++); /* Not an accident */

Not only have you fouled up the attributions, but you have fouled
the quote. It is considered very bad form to edit quotations. I
actually wrote:

while (*dest++ = *source++) continue;

as an analogy to something else.

You've made a mistake, Chuck. Tomas was replying to pete, not you, and
pete did post the quoted material.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[CBFalconer]

Flash Gordon wrote:

CBFalconer wrote:

"Tomás" wrote:

pete posted:

There are some style guidlines against writing code like this:
while (*dest++ = *source++);
because it looks like an accident.
while (*dest++ = *source++); /* Not an accident */

Not only have you fouled up the attributions, but you have fouled
the quote. It is considered very bad form to edit quotations. I
actually wrote:

while (*dest++ = *source++) continue;

as an analogy to something else.

You've made a mistake, Chuck. Tomas was replying to pete, not you, and
pete did post the quoted material.

Could well be. It is threaded here as a reply to me, and was
received before the pete article arrived. Netscape is known to
have anomalies when the References chain grows too long. So when I
saw that the only article with that phrase in it was mine, which
included the 'continue'. Apologies to Tomas.

--
"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/>

[Tomás]

CBFalconer posted:

Apologies to Tomas.

No problem.
(Which reminds me I've to upgrade to the lastest version of XNews some
time soon... )
-Tomás

[Ion Gaztañaga]

> Not necessarily. Consider the hypothetical "one time use"

allocater. realloc need only allocate a new chunk of the
appropriate size and copy the old over. It doesn't need to know
the size of the old, even for the copying if it can detect 'the
end' by some other means, analogous to encountering EOF.

For the extended malloc interface we should see how malloc is
implemented to see if size information is there and is fast to obtain.

I don't know any malloc implementation that does not store the size. So
if the size is there in all known implementations , it's logical to
propose new functions. If all known malloc implementations (check every
C library out there to check this) store the size, I think that we
should use that information to get better performance and less memory
use.

Maybe obtaining the size is not constant time in the "one time use"
allocator and you must do something similar to "strlen()", but let's be
practical: there is not such allocator in the real world, and I doubt
it will ever exist.

So let's asume that the size information is there and is very cheap to
obtain. Now we can discuss if proposed functions improve performance or
not, or they are useful enough enough to include them in the standard.
I can understand that you can think that those advanced reallocation
functions are not useful because you might never need them for general
purpose C programming. I think that memory reallocation is a common
pattern for a lot of C programs, and that there is an easy way to
improve their performance through these functions.

Regards,

Ion

[CBFalconer]

"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.

--
"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/>

[Stephen Sprunk]

"Ion Gaztañaga" <ig********@gma il.com> wrote in message
news:11******** **************@ j55g2000cwa.goo glegroups.com.. .

Not necessarily. Consider the hypothetical "one time use"
allocater. realloc need only allocate a new chunk of the
appropriate size and copy the old over. It doesn't need to know
the size of the old, even for the copying if it can detect 'the
end' by some other means, analogous to encountering EOF.
For the extended malloc interface we should see how malloc is
implemented to see if size information is there and is fast to obtain.

I don't know any malloc implementation that does not store the size. So
if the size is there in all known implementations , it's logical to
propose new functions. If all known malloc implementations (check every
C library out there to check this) store the size, I think that we
should use that information to get better performance and less memory
use.

<OT>
For most implementations , the size of the allocated block is trivially easy
to discover -- it's usually a few bytes before the address malloc() or
realloc() returns. Check the implementations that you care about, put in
#ifdefs that detect those implementations and deal with them, and leave in
some portable code to handle everything else.
</OT>
Maybe obtaining the size is not constant time in the "one time use"
allocator and you must do something similar to "strlen()", but let's be
practical: there is not such allocator in the real world, and I doubt
it will ever exist.

IIRC, such an allocator was recommended on clc the other day to someone
whose normal malloc() didn't fit on an embedded system with only a few kB of
memory. I'm pretty sure someone, somewhere has implemented such before
because it's useful in certain cases.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
*** Posted via a free Usenet account from http://www.teranews.com ***

[Herbert Rosenau]

On Tue, 16 May 2006 07:58:28 UTC, "Tomßs" <NU**@NULL.NULL > wrote:

while ( *dest = *source ) ++dest, ++source;
This one doesn't do a redundant final incrementation.

Says who? One of the mashines I had do use such loop it had an extra
cost of dest--, source--; at the end of the loop. The cause: the
mashine had an mashine code like

*dest++ = *source++;

as single memory to memory instruction, but not equivalent without the
increments.
So to get the final pointers right both hand needed an separate
decrement to fit the "as if" clause.

for(;*dest = *source;++dest, ++source);

Nor does this one.

Says who? See above.

while ( *dest++ = *source++ );

This one does however.

Best optimum because 'as if' qualifies as 'really done'. Except: don't
save spaces!
while (*dest++ = *source++) ;
= that little space helps to see that
the body is empty. More readable would be: bring the semicolon on the
next line on one more indention.

for(;*dest++ = *source++;);

As does this one.

Yep.

As I found out since about 1990: save typing but don't save on
meaningfull comments so good as possible and let the copiler do the
optimising on mashine code level. It will do better as you ever will
get it in acceptable time.

Meaningfull comments needed for maintenance after haing the code
untouched for 12 month or longer. Save typing means: write compact
code without consideration of beginners in programming but don't
require with real experts with more than 5 years extensive experience.

Don't mircro optimazion by hand because the next compiler version may
turn back that in its absolute contrary. Rethink the algorithm you use
will give a better optimazion anyway.

Use the highest possible warning level even on the final compile with
highest optimazion, remove any diagnostic the compiler may give by
resolving the cause - but use casts only when you have rethinking the
logic and you knows exactly that you knows absolutely that you knows
exactly why you have to cast and there is nothing else that can be
done, but never cast when it is only to get the compiler quiet.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!