0

An example says more than thousand words:

unsigned char *hello = (unsigned char*)malloc(STR_LEN * sizeof(unsigned char));
const char *str= "haha";
memcpy(hello, str, strlen(str) + 1);

How can I print the content of the whole hello-variable (printf("%s",..) would only respect the part before the \0-termination and not all STR_LEN characters).

NaN
  • 3,501
  • 8
  • 44
  • 77
  • 1
    Doing so would be undefined behaviour, because the memory isn't initialized. – Kerrek SB Mar 08 '14 at 17:40
  • I know... And in a normal situation it would not make any sense. But I have to compare some ASM operations and want to compare the bits behind the `\0`. – NaN Mar 08 '14 at 17:42
  • Sense or not, its still UB. – WhozCraig Mar 08 '14 at 17:45
  • 2
    @WhozCraig - I guess debuggers must crash left and right then, no? In fact UB is a theoretical concept, on practical systems the outcomes are reasonably constrained. – Chris Stratton Mar 08 '14 at 17:49
  • 1
    The more interesting issue here may be that if the desire is to compare "the bits behind" then one probably does not want to print the bytes as ASCII characters, but rather to print out their values in some convenient form, such as hex. – Chris Stratton Mar 08 '14 at 17:51
  • @ChrisStratton hard to argue with UB being theoretical, since assigning definition to the U is an oxymoron. And who said anything about *crashing* when invoking UB? That would be... expecting definition from the undefined. Like it or not, the standard itself is clear on evaluating uninitialized data. The behavior cannot be relied on, as there is no definition. That a process *doesn't* crash is misplaced assumption that *observed* behavior is therefore *defined*. And nothing is further from reality. – WhozCraig Mar 08 '14 at 18:36
  • @WhozCraig - your ceaseless harping on the theoretical concept ignores the practical reality that real programs running on real systems read uninitialized data **all the time**. Programs do not run on theoretical systems, they run on real ones, which have *well known* behavior that differs from that of language standards. **Investigative programs** in particular, **such as being discussed here** routinely examine **actual behavior** as distinct from theoretical standards. Yes, it's undefined behavior, but flying monkeys are not going to enslave you to maintain their cobol payroll database. – Chris Stratton Mar 08 '14 at 19:09
  • @ChrisStratton I can only hope your closing sentence is true =). But I guess i'll never really know. – WhozCraig Mar 08 '14 at 20:09

3 Answers3

5

You can use fwrite to write unformatted data:

char buf[4] = { 1, 2 };

fwrite(buf, 1, 4, stdout);   // writes the bytes 1, 2, 0, 0

You could use fwrite(hello, 1, STR_LEN, stdout), but note that you're not allowed to read uninitialized data (so you should use calloc instead or initialize the data in some other way).

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
0

You'd have to write your own for loop that goes from hello to hello+STR_LEN, and prints each character one at a time.

for (unsigned char *c = hello, e = hello +STR_LEN; c < e; ++c) {
    printf("%c", *c);
}
Daniel
  • 4,481
  • 14
  • 34
  • 2
    No, you wouldn't, as others have pointed out. However, if the goal is actually to look at the raw data itself, where a character representation is not very userful, then something like this with a format string such as `%02x ` might be a good start for generating an informative little hex dump – Chris Stratton Mar 08 '14 at 17:54
0
int i;
for(i = 0; i < STR_LEN; i++) {
    putchar(hello[i]);
}
user26347
  • 594
  • 3
  • 4