On a modern computer, memory is protected — specifically to avoid malicious programs or curious programmers from altering a balanced and busy system. Yet, the C language has equivalents to the old peek<\/em> and poke<\/em> commands. You know them as pointers.<\/p>\n For example, if you were running an Apple II and wanted to click the speaker, in BASIC you’d type Above, Today, the peeking and poking you do with pointers is limited to the realm of memory assigned to your program. (The operating system’s API might have a method to access other memory locations, but such a discussion is beyond the scope of this post.)<\/p>\n In Code:Blocks, start a new Project, Console Application, C language.<\/p>\n Give the project a title, Peeks and Pokes<\/strong>. And check the box to Create Debug Configuration. You can leave the Release Configuration box unchecked.<\/p>\n Type the following code for This code generates no output, which is why you don’t need the Build and run the code. You can ignore any unused variable warnings.<\/p>\n Now you debug:<\/p>\n Click Line 5 to place the cursor at that location. On the Debugger toolbar, shown in Figure 1, click the Run to Cursor button outlined in blue in the figure. If you don’t see the Debugger toolbar, choose View, Toolbars, Debugger.<\/p>\n Figure 1. Code:Blocks’ Debugging toolbar.<\/p><\/div>\n After you click the Run to Cursor button, you see a flurry of activity. Click the Debugging Windows button, outlined in green in Figure 1, and choose Watches from the menu. You see the Watches window appear, which lists the code’s variables, similar to what’s shown in Figure 2.<\/p>\n Figure 2. The Watches window shows you variables used in your code.<\/p><\/div>\n The first column shows the code’s variable names. The second column shows their values. At this point in the code (Line 5), the variables are uninitialized. The values shown are whatever garbage already exists in memory. And, yes, this garbage is why it’s important in C to always initialize your variables.<\/p>\n On the Debugging toolbar, click the Next Line button, which is just to the right of the Run to Cursor button on the Debugging toolbar.<\/p>\n You see the value for variable When you click the Next Line button again, you see the memory location of variable The program is over, co click the red X button on the Debugging toolbar to exit the debugger and stop.<\/p>\n In next week’s Lesson<\/a>, I’ll show you a memory map where you can view the value and marvel at its brilliance.<\/p>\n","protected":false},"excerpt":{"rendered":" Pointers reveal the contents of memory locations, similar to BASIC commands from years ago. Continue reading PEEK($C030)<\/code>. The C language equivalent might be:<\/p>\n\r\nchar *p,a;\r\n\r\np = (char *)0xc030;\r\na = *p;<\/pre>\n
p<\/code> is a char<\/em> pointer and it’s set to the direct memory value 0xc030. This statement is illegal in current implementations of C, as you can only assign a pointer to a compatible variable. But I remember doing similar coding back in the 1980s. Then, to access that “peek” location, you assign the value stored at p<\/code> to char<\/em> variable a<\/code>. This approach might work, and if anyone has a runnning Apple II with a C compiler, they could confirm it. The odds of that happening are rather low.<\/p>\nmain.c<\/code>:<\/p>\n\r\nint main()\r\n{\r\n short *p;\r\n short a;\r\n\r\n a = 65;\r\n p = &a;\r\n\r\n return 0;\r\n}<\/pre>\nstdio.h<\/code> header file. Instead, this code is meant to be debugged, which shows you (peeks) at what’s going on in memory.<\/p>\n![\"\"](\"http:\/\/c-for-dummies.com\/blog\/wp-content\/uploads\/2018\/04\/0428-fig1_debugging-toolbar.png\")
![\"\"](\"http:\/\/c-for-dummies.com\/blog\/wp-content\/uploads\/2018\/04\/0428-fig2_watches.png\")
a<\/code> set to 65.<\/p>\na<\/code> assigned to pointer p<\/code>. On my screen, the value is 0x60ff0a. At that precise memory location in my computer, the short int<\/em> value 65 sits and waits.<\/p>\n