Test if pointer points to allocated memory

C

CBFalconer

rahul said:
malloc() library function uses brk() and sbrk() to increase the
address space of a process. sbrk() is a system call that ask
the kernel to allocate space at the end of "data segment" of
the process. So, the address returned by malloc() should always
be greater than the end of data segment.
Now, the end of data segment may be found by printing the address
of the symbol "end" or the address of the symbol "_end". These
symbols are defined with the appropriate values by the linker.
Or you may use "objdump" to find out the addresses of data segments
of your executable.

This sort of answer illustrates the danger of allowing Trollsdale
posts to go unchallenged. brk/sbrk are not part of the C
standard, and their actions (if present) are non-portable and thus
immaterial on c.l.c. Everybody should be aware that ANYTHING
written by Tisdale aka Trollsdale is immediately suspect and
probably nonsense.
 
J

Joona I Palaste

This sort of answer illustrates the danger of allowing Trollsdale
posts to go unchallenged. brk/sbrk are not part of the C
standard, and their actions (if present) are non-portable and thus
immaterial on c.l.c. Everybody should be aware that ANYTHING
written by Tisdale aka Trollsdale is immediately suspect and
probably nonsense.

It was rahul dev, not Trollsdale, who wrote all that crap about brk/
sbrk and "_end" symbols.
 
D

Dan Pop

In said:
Interesting, what sort of computer are you using that doesn't have a
kernel?

Most computers don't have a kernel (they are very small chips used in
embedded control applications; your PC probably contains several of them).

OTOH, they don't have hosted C implementations, either, so Christian's
point about malloc on kernel-less computers is moot: freestanding
implementations need not provide malloc at all.

Dan
 
P

pete

E. Robert Tisdale said:
Jack said:
E. Robert Tisdale wrote:

Undefined behavior.
p and &p are not pointers to the same object
or one past the same object or array.

Please elaborate. Why does that make a difference?
Not all processors have a stack.

But they all have "automatic storage".
The typical implementation of automatic storage is on the program stack.
Even for those that do, you are
you are making the unwarranted and unproven assumption that
"the stack" resides at higher memory addresses than other areas.
I know of several architectures
where processor hardware requires that the stack be in low memory.

Name one.
Or is uninitialized. Or null.
Or points to allocated memory that has been free.


Neither does anyone with any sense, you included.

I don't know whether I have any sense or not.
But my assertion is easily tested:
cat main.c
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char* argv[]) {
//char c;
//char* p = &c;
char* p = (char*)malloc(sizeof(char));
if (p > (char*)(&p)) {
fprintf(stdout, "p probably points to a character "
"in automatic storage.\n");
}

C:\Program Files\DevStudio\SharedIDE\bin\Debug>new
p probably points to a character in automatic storage.
 
C

CBFalconer

Joona said:
It was rahul dev, not Trollsdale, who wrote all that crap about brk/
sbrk and "_end" symbols.

But he was triggered by the Trollsdale junk. I consider him a
poor sucker trolled by Trollsdale. See underlined.
 
D

Dan Pop

In said:
Could be running PC-DOS, where the `kernel' is simply a program loader
and an interrupt handler. (Calling something so simple a kernel now
would get one laughed out of the industry. ;) )

Nope, it is a lot more than that. It provides many of the services
offered by the kernels of more sophisticated OSs; it's just that many
of them are extremely poorly implemented (console I/O very slow, serial
I/O unreliable at "high" speeds because is not interrupt driven) and
others are designed with a complete lack of security concerns in mind.

Actually version 2 was not so bad, given the hardware it was supposed to
run on. Things started to get bad by the time IBM introduced the AT/286
but the OS kept treating the machine as a fast 8086 and became absolutely
ludicrous when the AT/386 was treated as an even faster 8086 by the OS.
Yet, the OS design remained unchanged until its official death, in the
Pentium I era.

Dan
 
D

Dan Pop

In said:
This sort of answer illustrates the danger of allowing Trollsdale
posts to go unchallenged. brk/sbrk are not part of the C
standard, and their actions (if present) are non-portable and thus
immaterial on c.l.c. Everybody should be aware that ANYTHING
written by Tisdale aka Trollsdale is immediately suspect and
probably nonsense.

By what kind of logic can Trollsdale be made responsible for the
nonsense written by other people, rahul dev, in this case?

C'mon, if you engage your brain, I'm sure you can tell the difference
between the lines prefixed by one '>' and those with no prefix at all.
You may even be able to decode the meaning of the line:


appearing at the beginning of a post (right after the headers): it
means that all the lines prefixed by a single '>' have been written
by Trollsdale, while those with no prefix have been written by the
poster whose name appears in the From header of the post (and in the
signature block, if present).

Dan
 
D

Dan Pop

In said:
But he was triggered by the Trollsdale junk. I consider him a
poor sucker trolled by Trollsdale. See underlined.

A perfect non-sequitur. Your own comments apply to the text posted by
rahul dev and there is no way to blame that text on Trollsdale's advice,
especially considering that he was explicitly saying that it was *not*
based on the C standard.

Your lame attempt to save your ass from your previous mistake fools no
one. Believe me, there is no substitute for engaging your brain before
posting.

Dan
 
D

David Resnick

Is there anyway to test if a pointer points to allocated memory or
not?
For example if I have a pointer such as char *p is there a standard
way to test whether an assignment such as the following has been
applied?
p = (char *) malloc(sizeof(char) * n);

Well, if you need to do this, there is one portable option. You could
"wrap" malloc, calloc, realloc, and free, and keep track of
the things allocated/freed. Of course, this only works for things
allocated under your control, which may not always be true of
all dynamically allocated memory you encounter (e.g. stuff from
libraries not owned by you). Anyway, the following might work
for you:

example program fragment, assumes you have some static hash
table accessed through the hash functions which store or
retrieve pointer values.

void *my_malloc(size_t size)
{
void *tmp = malloc(size);

if (tmp != NULL) {
hash_enter(tmp);
}

return tmp;
}

void my_free(void *ptr)
{
if (ptr != NULL) {
hash_remove(ptr);
free(ptr);
}
}

int ptr_was_allocated(void *ptr)
{
if (ptr != NULL && hash_contains(ptr)) {
return 1;
}
else {
return 0;
}
}

If the above doesn't suit you, you are out of luck in portable
C AFAIK. But if you are willing to use platform specific extensions,
you may have some options. If so, ask in a group dedicated to
your platform. Or you could leave such checking of
pointers out of your code, and use the tools available for your
platform while testing to detect invalid memory accesses -- for example
valgrind/electric fence/bounds checker/Purify/etc.

Good luck.

-David
 
A

August Derleth

Dan said:
Nope, it is a lot more than that. It provides many of the services
offered by the kernels of more sophisticated OSs; it's just that many
of them are extremely poorly implemented (console I/O very slow, serial
I/O unreliable at "high" speeds because is not interrupt driven) and
others are designed with a complete lack of security concerns in mind.

Hm. I suppose I knew that (I do assembly-level DOS programming on
occasion, nearly always for 80386s or higher), but I tried to subsume it
under the rubric of `interrupt handler'. In other words, I was being
somewhat facetious and trying to imply that anything like PC-DOS,
MS-DOS, or DR-DOS (or any of the lesser-known clones) is /not/ a Real OS
by my (Unix-informed) standard. ;)

It's also interesting to hear just how broken PC-DOS truly was. Wasn't
that IBM's in-house project? No wonder they embraced Linux so quickly:
Moderately code must make them downright ecstatic, when compared to what
they'd have done on their own. ;)
Actually version 2 was not so bad, given the hardware it was supposed to
run on. Things started to get bad by the time IBM introduced the AT/286
but the OS kept treating the machine as a fast 8086 and became absolutely
ludicrous when the AT/386 was treated as an even faster 8086 by the OS.
Yet, the OS design remained unchanged until its official death, in the
Pentium I era.

Bah. Bogosity and cruft, taken to an absurd degree. I can understand
(maybe) not using the half-baked extra features introduced in the 80286,
but not jumping with both feet on the 80386's 32-bit addressing and
general strides in the direction of becoming a Real Architecture?
Mind-boggling.

(I consider the 8086 to be an abortion of a design, and the 80386
Intel's semi-awakening to the world of ISA sanity. Nothing as pretty as
a VAX or even a Motorola 68000, but not nearly as painful to program
assembly for.)
 
D

Daniel Haude

On 21 Jan 2004 08:25:57 -0800,
Andrew said:
Is there anyway to test if a pointer points to allocated memory or
not?
For example if I have a pointer such as char *p is there a standard
way to test whether an assignment such as the following has been
applied?
p = (char *) malloc(sizeof(char) * n);

I'm entering this thread a bit late, and therefor it's quite likely that
someone already made this sugegstion:

Why don't you initialize the pointer variable in question as NULL, and
test if it is non-NULL when in doubt? If you want to re-use the variable,
you must set it to NULL after freeing it. Of course this method has the
obvious limitations, but I use it all the time and am very satisfied.

I'm sure you've already been instructed to use

p = malloc(n * sizeof *p)

instead of doing it the way quoted above. The cast hides a possible bug,
and sizeof(char) is just a complicated way of writing 1. The generally
accepted method works with all pointer types, discloses failure to include
stdlib.h, and is less verbose.

--Daniel
 
J

Joe Wright

Daniel said:
On 21 Jan 2004 08:25:57 -0800,



I'm entering this thread a bit late, and therefor it's quite likely that
someone already made this sugegstion:

Why don't you initialize the pointer variable in question as NULL, and
test if it is non-NULL when in doubt? If you want to re-use the variable,
you must set it to NULL after freeing it. Of course this method has the
obvious limitations, but I use it all the time and am very satisfied.
[ snip ]

Limitations indeed. If you know that you are careful enough to NULL a
pointer after freeing it, then what is the point of later checking it
for NULL? What will we do if it is not NULL? Error out?

On most modern 32-bit architectures a pointer value has 4 billion
possibilities, NULL and all the others. The C programmer can examine the
pointer value to determine whether it is NULL or not. Beyond that, its
validity is not knowable.
 
D

Daniel Haude

On Sun, 25 Jan 2004 12:41:39 -0500,
in Msg. said:
Limitations indeed. If you know that you are careful enough to NULL a
pointer after freeing it, then what is the point of later checking it
for NULL? What will we do if it is not NULL? Error out?

That depends on whether we expect the pointer to be pointing at useable
storage area or not.

--Daniel
 
J

Joe Wright

Daniel said:
On Sun, 25 Jan 2004 12:41:39 -0500,


That depends on whether we expect the pointer to be pointing at useable
storage area or not.
It doesn't matter what you expect. NULL does not point to useable
storage. You can't tell whether any other pointer value does. Think
about it.
 
D

Daniel Haude

On Mon, 26 Jan 2004 00:19:04 GMT,
in Msg. said:
It doesn't matter what you expect. NULL does not point to useable
storage. You can't tell whether any other pointer value does. Think
about it.

Don't worry, I already know all about it. If you think that I think that
any non-NULL pointer points to allocated memory, you're mistaken. Remember
that I pointed out the "obvious limitations" of this simple method right
at the beginning.

If one interprets the OP literally as a request for a method that, when
fed ANY pointer, can tell if it points to allocated storage, then of
course it's not sufficient to just test against NULL. But then such a
method would be at best of academic interest, but rather useless for
practical purposes (unless you're wrizing a debugger).

--Daniel
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,766
Messages
2,569,569
Members
45,043
Latest member
CannalabsCBDReview

Latest Threads

Top