Convert Int Value To Pointer

[ReaperUnreal]

I've got a strange problem here. I need to take a value that I have
written down on a sticky-note here, and find what's at that address in
current memory. I've tried the following:

void *value = 0x00323c68;

but I get a typecasting error. If I do the following:

void *value = static_cast<void *>(0x00323c68);

will that get me what I desire?

--Guillaume C.L.--

 

[ReaperUnreal]

I've got a strange problem here. I need to take a value that I have
written down on a sticky-note here, and find what's at that address in
current memory. I've tried the following:

void *value = 0x00323c68;

but I get a typecasting error. If I do the following:

void *value = static_cast<void *>(0x00323c68);

will that get me what I desire?

--Guillaume C.L.--

Come to think of it, I'd need a reinterpret_cast not a static_cast
wouldn't I?

--Guillaume C.L.--

 

[Richard Heathfield]

ReaperUnreal said:

I've got a strange problem here. I need to take a value that I have
written down on a sticky-note here, and find what's at that address in
current memory. I've tried the following:

void *value = 0x00323c68;

but I get a typecasting error.

No, you don't, since there is no cast.

If I do the following:

void *value = static_cast<void *>(0x00323c68);

will that get me what I desire?

No, because that's a syntax error.

If you do this:

void *value = (void *)0x00323c68;

it'll compile all right, but it won't actually mean anything very much on
most systems. On a protected mode OS, if you try to read through (or write
through!) that pointer, the best you're likely to get is a segfault.

 

[Nelu]

Come to think of it, I'd need a reinterpret_cast not a static_cast
wouldn't I?

The casting you're using is specific to C++.
Depending on the OS the value of that number can or cannot have
meaning.
The standard (C99) also says that an integer may be converted to any
pointer type but the result is implementation-defined.

 

[Eric Sosman]

ReaperUnreal wrote On 07/14/06 12:09,:

I've got a strange problem here. I need to take a value that I have
written down on a sticky-note here, and find what's at that address in
current memory. I've tried the following:

void *value = 0x00323c68;

but I get a typecasting error. If I do the following:

void *value = static_cast<void *>(0x00323c68);

will that get me what I desire?

Only you know your desires. However, you're in the
wrong newsgroup. In comp.lang.c we discuss Australia;
you should instead go to comp.lang.c++ if you want to
learn about Austria. Despite the superficial similarity
of names, the two have very little to do with each other.

 

[Frederick Gotham]

ReaperUnreal posted:

I've got a strange problem here. I need to take a value that I have
written down on a sticky-note here, and find what's at that address in
current memory. I've tried the following:

void *value = 0x00323c68;

but I get a typecasting error. If I do the following:

void *value = static_cast<void *>(0x00323c68);

will that get me what I desire?

How about something like the following?

#include <stddef.h>
#include <limits.h>
#include <stdio.h>

void PrintBits(void const * const mem, size_t amount_bytes)
{
char static str[CHAR_BIT + 1]; /* Auto null teminator */

unsigned char const *p = (unsigned char const *)mem;

do
{
unsigned char const byte_val = *p++;

char *pos = str;

unsigned char i = 1U << CHAR_BIT - 1;

do *pos++ = byte_val & i ? '1' : '0';
while(i >>= 1U);

printf("%s",str);

} while (--amount_bytes);
}

int main(void)
{
void * const p = (void*)0x00323c68;

PrintBits( p, 1 );
}

 

[Jack Klein]

ReaperUnreal posted:

I've got a strange problem here. I need to take a value that I have
written down on a sticky-note here, and find what's at that address in
current memory. I've tried the following:

void *value = 0x00323c68;

but I get a typecasting error. If I do the following:

void *value = static_cast<void *>(0x00323c68);

will that get me what I desire?

How about something like the following?

#include <stddef.h>
#include <limits.h>
#include <stdio.h>

void PrintBits(void const * const mem, size_t amount_bytes)
{
char static str[CHAR_BIT + 1]; /* Auto null teminator */

unsigned char const *p = (unsigned char const *)mem;

do
{
unsigned char const byte_val = *p++;

char *pos = str;

unsigned char i = 1U << CHAR_BIT - 1;

do *pos++ = byte_val & i ? '1' : '0';
while(i >>= 1U);

Do you realize that there is absolutely no gain to adding the 'U'
suffix here?

printf("%s",str);

} while (--amount_bytes);
}

int main(void)
{
void * const p = (void*)0x00323c68;

PrintBits( p, 1 );
}

Do you actually this makes the behavior any less undefined? Do you do
realize that without a terminating '\n', there is no guarantee that
any output will appear?

 

[Rod Pemberton]

I've got a strange problem here. I need to take a value that I have
written down on a sticky-note here, and find what's at that address in
current memory. I've tried the following:

void *value = 0x00323c68;

but I get a typecasting error. If I do the following:

void *value = static_cast<void *>(0x00323c68);

will that get me what I desire?

I don't mean to sound difficult, but maybe, or maybe not. Your ability to
access memory outside of your application space is environment _and_
compiler specific. I get to this in a bit.

First, let's learn how to cast in C.

void *value = 0x00323c68;

First problem: there is no cast there. If there was a cast, it'd look like
this:

void *value = (void *)0x00323c68;

Second problem: you can't do pointer arithmetic on void's and you can't
obtain a value using a void pointer. So, the cast must be of some other
type (char, long, int,...):

unsigned char *value = (unsigned char *)0x00323c68;

or:

unsigned long *value = (unsigned long *)0x00323c68;

As a practical matter, the first will return a 8-bit "byte" on most modern
systems (C defines a byte as the smallest addressable grouping of bits, not
as 8-bits...). The second will return a 32-bit value on most modern
systems, but may return other sizes (64-bits) depending on the compiler
and/or environment.

Finally, if you are attempting to read memory outside your application
space. You may have to jump through a number of other hurdles:
1) mapping the memory through the MMU or paging mechanism
2) gaining CPU privilege to access the memory
3) adjusting the pointer by an offset (linear vs. physical addressing)
4) etc...


Rod Pemberton

 

[Frederick Gotham]

Jack Klein posted:

Do you realize that there is absolutely no gain to adding the 'U'
suffix here?

Option (1)

i >>= 1

The thing on the left is very likely to be promoted to a "signed int". It's
shifted once to the right, then the result is converted to an "unsigned
char".

Option (2)

i >>= 1U

The thing on the left is promoted to "unsigned int". It's shifted once to
the right, then the result is converted to an "unsigned char".


Option (2) sounds more natural to me.

Do you actually this makes the behavior any less undefined?

Obviously, this person knows what's at that memory address.

Do you do realize that without a terminating '\n', there is no guarantee that
any output will appear?

I recall hearing something along those lines before. Would I have to flush?

 

[ReaperUnreal]

Jack Klein posted:




Option (1)

i >>= 1

The thing on the left is very likely to be promoted to a "signed int". It's
shifted once to the right, then the result is converted to an "unsigned
char".

Option (2)

i >>= 1U

The thing on the left is promoted to "unsigned int". It's shifted once to
the right, then the result is converted to an "unsigned char".


Option (2) sounds more natural to me.




Obviously, this person knows what's at that memory address.




I recall hearing something along those lines before. Would I have to flush?

Ok, so first off, I got it to work, it was indeed that I either had to
use reinterpret_cast or a C-style cast. I needed to cast it as a void
pointer because that's what the function takes. This is perfectly
defined for the function ReadProcessMemory which I'm using to write a
trainer of sorts. Please stop telling me that it won't work, when I've
tested it, and it does. I do in fact know exactly what's at that memory
address, a double containing my randomly generated number, a proof of
concept basically.

--Guillaume C.L.--

 

[Barry Schwarz]

On 15 Jul 2006 08:04:36 -0700, "ReaperUnreal" <[email protected]>
wrote:

snip

Ok, so first off, I got it to work, it was indeed that I either had to
use reinterpret_cast or a C-style cast. I needed to cast it as a void

Are you working in C or C++? If the latter, this is the wrong group.
If the former, there is no reinterpret_cast.

pointer because that's what the function takes. This is perfectly

What language are you in? In C, you can pass any pointer to a
function that expects a void pointer as long as a prototype for that
function is in scope. C permits implicit conversion to and from void
pointers.


Remove del for email

 

[Keith Thompson]

Jack Klein posted: [...]n

Do you do realize that without a terminating '\n', there is no
guarantee that any output will appear?

I recall hearing something along those lines before. Would I have to
flush?

It depends on the circumstances. For something like:

printf("Prompt: ");
fflush(stdout);
fgets(buf, sizeof buf, stdin);

the fflush() call ensures that the prompt will appear. (This assumes
that the system supports this kind of interactive i/o in the first
place; not all systems do.) On the other hand, for the last output a
program produces before terminating, a missing newline means the
output might not appear at all, with or without a call to fflush().
C99 7.19.2p2:

A text stream is an ordered sequence of characters composed into
lines, each line consisting of zero or more characters plus a
terminating new-line character. Whether the last line requires a
terminating new-line character is implementation-defined.

(stdout is, of course, associated with a text stream.) Note that the
standard doesn't say what happens if a new-line character is required
and the program doesn't provide one; this implies that it's undefined
behavior.

More commonly, even if a final line without a trailing new-line is
written properly to stdout, it may not appear properly. For example,
a shell prompt written after the program terminates may be confusingly
merged with the program's output, or may even overwrite it.

 

[pete]

Jack Klein posted:


Option (1)

i >>= 1

The thing on the left is very likely
to be promoted to a "signed int".

Option (2)

i >>= 1U

The thing on the left is promoted to "unsigned int".

Wrong.
The types of the right and left operands of a shift operator,
have nothing to do with each other.

(i >>= 1) and (i >>= 1U),
are both expressions of whatever type i is promtoted to,
according to the rules for "integer promotions".

 

[pete]

Wrong.
The types of the right and left operands of a shift operator,
have nothing to do with each other.

(i >>= 1) and (i >>= 1U),
are both expressions of whatever type i is promtoted to,
according to the rules for "integer promotions".

I meant to say that (i >> 1) and (i >> 1U),
are both expressions of whatever type i is promoted to,
according to the rules for "integer promotions".

(i >>= 1) and (i >>= 1U) are both expressions of
whatever type i is of.

 

[Frederick Gotham]

Keith Thompson posted:

printf("Prompt: ");
fflush(stdout);
fgets(buf, sizeof buf, stdin);

Is it a requirement of C that every time you print something, there must be a
'\n' at the end?

 

[Ed Prochak]

Keith Thompson posted:




Is it a requirement of C that every time you print something, there must be a
'\n' at the end?

No. Why do you thing that?

 

[Frederick Gotham]

Ed Prochak posted:

No. Why do you thing that?

I think I understand...

The following program might not print anything at all:

#include <stdio.h>

int main(void)
{
printf("Hello");

fflush(stdout);
}

While the following *must* print something:


#include <stdio.h>

int main(void)
{
printf("Hello\n");
}



Correct... ?

What are all the ways of "flushing"? I know of:

(1) Print a '\n'.
(2) fflush()

 

[Keith Thompson]

Keith Thompson posted:

Is it a requirement of C that every time you print something, there
must be a '\n' at the end?

No, of course not. (It's odd that you ask that after quoting an
example where there *isn't* a '\n' at the end of the output.)

For a full explanation, see the remainder of my previous followup,
which you snipped.

 

[Keith Thompson]

Ed Prochak posted:



I think I understand...

The following program might not print anything at all:

#include <stdio.h>

int main(void)
{
printf("Hello");

fflush(stdout);
}

While the following *must* print something:


#include <stdio.h>

int main(void)
{
printf("Hello\n");
}



Correct... ?

Yes (though an output error is always a possibility, the first program
will *probably* print "Hello" without a newline, or possibly with one,
on most implementations, and you should really have a "return 0;"
unless you're assuming a C99 implementation).

What are all the ways of "flushing"? I know of:

(1) Print a '\n'.
(2) fflush()

Printing a '\n' doesn't *necessary* flush the stream; it depends on
how the stream is buffered.

C99 7.19.3p3:

When a stream is _unbuffered_, characters are intended to appear
from the source or at the destination as soon as
possible. Otherwise characters may be accumulated and transmitted
to or from the host environment as a block. When a stream is
_fully buffered_, characters are intended to be transmitted to or
from the host environment as a block when a buffer is filled. When
a stream is _line buffered_, characters are intended to be
transmitted to or from the host environment as a block when a
new-line character is encountered. Furthermore, characters are
intended to be transmitted as a block to the host environment when
a buffer is filled, when input is requested on an unbuffered
stream, or when input is requested on a line buffered stream that
requires the transmission of characters from the host
environment. Support for these characteristics is
implementation-defined, and may be affected via the setbuf and
setvbuf functions.

C99 7.19.3p7:

At program startup, three text streams are predefined and need not
be opened explicitly -- _standard input_ (for reading conventional
input), _standard output_ (for writing conventional output), and
_standard error_ (for writing diagnostic output). As initially
opened, the standard error stream is not fully buffered; the
standard input and standard output streams are fully buffered if
and only if the stream can be determined not to refer to an
interactive device.