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. a protected mode S, if you try to read through (or write
through!) that pointer, the best you're likely to get is a segfault.

"ReaperUnreal" <reaperunreal@gmail.comwrites:

ReaperUnreal wrote:
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?

C.L

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

ReaperUnreal wrote 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?

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.

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 ();
}

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

PrintBits( p, 1 );
}

Fri, 14 Jul 2006 19:37:20 GMT, Frederick Gotham
<fgothamN@SPAM.comwrote in comp.lang.c:

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 ();
}

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?

Jack Klein posted:


>while(i 1U);
>
Do you realize that there is absolutely no gain to adding the 'U'
suffix here?

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

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

(2) sounds more natural to me.

Do you actually this makes the behavior any less undefined?

, 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?

Frederick Gotham <fgothamN@SPAM.comwrites:
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.) 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.

Frederick Gotham wrote:

Jack Klein posted:
>
>while(i 1U);
>
Do you realize that there is absolutely no gain to adding the 'U'
suffix here?

(1)

i 1

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

(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 wrote:

Frederick Gotham wrote:

Jack Klein posted:
>
>while(i 1U);
>
Do you realize that there is absolutely no gain to adding the 'U'
suffix here?

(1)

i 1

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

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

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.

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 posted:

Frederick Gotham wrote:
>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?
>
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()

Frederick Gotham <fgothamN@SPAM.comwrites:
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?

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.

Frederick Gotham <fgothamN@SPAM.comwrites:
Ed Prochak posted:
>
>>
>Frederick Gotham wrote:
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?
>>
>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 ?

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