-7

I am trying to analyze some code in a C++ program (I am very new to C++), and I dont get what the following code is trying to accomplish.
Based on the threads Ive read on here, setting a pointer to deadbeef will make the pointer null. However, visual studio does not allow me to do this and gives me an error. I have no idea what the second pointer is supposed to do. Any input would be appreciated.

long* firstpointer = (long *)((void *)0);
char* secondpointer = (char*) ((void *)0);

*firstpointer = 0xDEADBEEF;
strcpy(secondpointer,"Here is some text, here is some more");
Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
  • 2
    Undefined behaviour for both. – chris Apr 01 '13 at 02:54
  • 9
    "Based on the threads Ive read on here, setting a pointer to deadbeef will make the pointer null. " -- What thread says that? It's not at all true. – Jim Balter Apr 01 '13 at 02:54
  • "I dont get what the following code is trying to accomplish." -- Why do you think it's trying to accomplish something? It looks like pointless nonsense. Where did you find this code? – Jim Balter Apr 01 '13 at 02:55
  • If it doesnt make it null, what is it trying to accomplish? – user2012481 Apr 01 '13 at 02:56
  • 1
    " However, visual studio does not allow me to do this and gives me an error." -- Doesn't allow you to do what? What error, on what line? – Jim Balter Apr 01 '13 at 02:57
  • Well it is in an exercise, and I am suppose to figure out how the program will react when reaching this code. I get an error in visual studio when the firstpointer = deadbeef. – user2012481 Apr 01 '13 at 02:57
  • 1
    "If it doesnt make it null, what is it trying to accomplish? " -- You didn't answer my question ... **What thread says that?** Come along now, before this very low quality question gets deleted. – Jim Balter Apr 01 '13 at 02:57
  • 2
    "I get an error in visual studio " -- **What error**? – Jim Balter Apr 01 '13 at 02:58
  • 1
    " I am suppose to figure out how the program will react when reaching this code." -- That has nothing to do with trying to accomplish something. – Jim Balter Apr 01 '13 at 02:59
  • i dont understand your hostility jim..I assumed it was making a pointer null after reading this http://stackoverflow.com/questions/5907614/0xdeadbeef-vs-null – user2012481 Apr 01 '13 at 02:59
  • 1
    Trying to dereference a null pointer causes undefined behaviour. End of story. – Carl Norum Apr 01 '13 at 02:59
  • This is the error I get. First-chance exception at 0x00331527 in hello world.exe: 0xC0000005: Access violation writing location 0xcccccccc. Thanks for the response Carl, thats all I needed. – user2012481 Apr 01 '13 at 03:01
  • 3
    Who is hostile? I'm just trying to get you to provide the information that would allow people to help you. Notice that your question now has 7 downvotes ... try to understand why. – Jim Balter Apr 01 '13 at 03:02
  • "I assumed it was making a pointer null after reading this" -- That doesn't say anything of the sort. – Jim Balter Apr 01 '13 at 03:02
  • 2
    "Thanks for the response Carl, thats all I needed." -- Chris already said it in the first comment. – Jim Balter Apr 01 '13 at 03:03
  • 1
    "This is the error I get." -- That's not an error from Visual Studio, it's an error from Windows OS ... Visual Studio is just reporting it. Visual Studio *did* allow you to do it ... if it hadn't, your program would not have run and you would not have gotten the error. – Jim Balter Apr 01 '13 at 03:05
  • "I am suppose to figure out how the program will react when reaching this code. I get an error in visual studio when the firstpointer = deadbeef. " -- And now you *know* how it will react. Next is for you to understand why it reacts that way. Since this is a class exercise, all the relevant info is probably in the prior course materials -- you might want to review them. – Jim Balter Apr 01 '13 at 03:15
  • Your basic problem is your assumption that the code is supposed to do something ... but it's not; it is intentionally broken, nonsense code that was presented to you as an exercise for understanding. So your question, "why does this code not work" is like asking why treating monkey droppings like a recipe doesn't produce a cake. – Jim Balter Apr 01 '13 at 03:39
  • "Based on the threads Ive read on here, setting a pointer to deadbeef will make the pointer null." -- No, no thread here says anything like that, certainly not the one you cited in your comment above. That thread doesn't even talk about setting pointers, it talks about `memset`. – Jim Balter Apr 01 '13 at 03:40
  • And `*firstpointer = 0xDEADBEEF;` doesn't set a pointer to 0xDEADBEEF, it doesn't set a pointer at all. It attempts to set a `long` that the pointer points to. But the value of `firstpointer` is `(long *)((void *)0)`, which is not a valid address of any long, so the result is undefined behavior. The specific result on your Windows system is an access violation. – Jim Balter Apr 01 '13 at 03:41
  • `strcpy(secondpointer,"Here is some text, here is some more");` -- Since the first statement gets an access violation, the second one is moot ... but if the first statement were removed, this would likewise result in undefined behavior for exactly the same reason. `secondpointer` has the same value as `firstpointer`, which is not a valid address of a long, and `strcpy` is just another way to try to store into what the pointer points to, but it doesn't point anywhere valid, so the behavior is undefined. – Jim Balter Apr 01 '13 at 03:42
  • I should have said "which is not a valid address of an array of chars sufficiently long to hold the given string", but the basic idea is the same. – Jim Balter Apr 01 '13 at 03:50

1 Answers1

3

Based on the threads Ive read on here, setting a pointer to deadbeef will make the pointer null.

No, that is incorrect. Although deadbeef is a common "nonsense pattern", it is definitely not equal null. A common reason to set pointers (more generally, a memory area) to a known and unusual pattern, such as deadbeef, is to detect non-initialized areas of memory. A pattern of all zeros, which is commonly used to represent null pointers, is not as good a candidate, because your chances of finding a sequence of zeros in consecutive memory locations is much higher than finding a sequence of deadbeefs.

The crash that you see in the call of strcpy happens because secondpointer is set to an invalid value. You need to allocate enough memory to fit "Here is some text, here is some more", along with its terminating zero, in order for strcpy not to exhibit undefined behavior.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
  • This is all true, but it does not answer the OP's questions: Why does this code not work, what is it trying to accomplish, and what is the second pointer supposed to do. – Jim Balter Apr 01 '13 at 03:18
  • @JimBalter I think that with some clarity on the "what's deadbeef" point the second half of the question becomes less relevant. – Sergey Kalinichenko Apr 01 '13 at 03:25
  • I don't think so at all. What's deadbeef has nothing at all to do with OP's exercise ... 0xDEADBEEF could have been anything, with the same results. – Jim Balter Apr 01 '13 at 03:30
  • @JimBalter It's not the value itself, it's the incorrect belief that it should somehow be equivalent to `null`. I added a note about the crash. – Sergey Kalinichenko Apr 01 '13 at 03:35
  • It doesn't matter whether it's equivalent to NULL ... if it were equivalent to NULL, the result would be the same. I wrote a real answer but the question got closed before I could save it. The OP has a large number of false impressions, including that `*firstpointer = 0xDEADBEEF` sets a pointer. – Jim Balter Apr 01 '13 at 03:37