Talk:Pointer (computer programming)

message: The section about C arrays is totally wrong.
&array and array have the same value infact, they're just different types. the visual diagram represents array as if it was a pointer, it's not exactly like that. should be fixed. —The preceding unsigned comment was added by 88.154.187.60 (talk) 02:14, 23 April 2007 (UTC)
replies: text: Then fix it.  Cburnett 02:56, 23 April 2007 (UTC)
thread_title:  FIX ARRAY SECTION 

message: Reading this page, although it's pretty much correct, I'm not terribly fond of the approach taken. It tacitly refers to C and the Intel platform throughout, worst of all in the second paragraph, with little attention given to the variety of ways of treating pointers on other platforms or in other languages that have them, most notably assembly languages.
The statement that memory capacity is limited to pointer size is misleading and ignores segmentation, as is the statement that pointer operations are more efficient than array operations.
I also think explaining the close connection between pointers and how the underlying hardware operates would emphasize how fundamental they are. I've updated the page to strike at a few of these problems. Disagreements welcome.
Derrick Coetzee 18:05, 4 Jan 2004 (UTC)
replies: text: You removed my perfectly valid warning about what constitutes trouble for 89% of beginner programmers, and I removed your vague and repetitive phrase about "simpler form of...". Simpler in what sense? Mikkalai 06:35, 21 Sep 2004 (UTC)
replies: text:  I moved your warning, not removed it. References are "simpler" in the sense that they're formally easier to reason about, because they can't do as many operations. Perhaps more restricted or less powerful is more descriptive. If you believe this confusion is a big deal, I'll leave these changes alone, but please explain yourself in the future, at least in the edit comment box, or I'm left thinking you just reverted my changes for no reason when I had a reason for doing them. Derrick Coetzee 07:32, 21 Sep 2004 (UTC)

text: There are no pointers in Java. See reference (computer science). Deco 01:16, 10 January 2006 (UTC)
thread_title: Old comments

message: Too much code! It looks like a training manual. Alex 20:58, 28 March 2006 (UTC)
replies: text: I agree. You don't need to show every bit of code. It's an example, not something for people to compile. —Andrew Hampe Talk 22:57, 4 August 2007 (UTC)

text: Huh? The article is called " pointers " people. You need code!  —Preceding unsigned comment added by 137.30.122.155 (talk) 18:58, 10 April 2011 (UTC)

text: I disagree! Code is precise, and pointers are a matter of programming. As someone who programs, I find this good and correct. Mfwitten (talk) 19:51, 10 April 2011 (UTC)
thread_title:  Wild pointers 

message: Most of Wikipedia's link to pointer mean a "data pointer", so was my move wrong? I thought it might be nice to let dog lovers have their word back. Also, a lot of teachers still use a long stick to actually "point" to a spot on the blackboard. ^_^ --Uncle Ed 15:38, 17 November 2006 (UTC)
replies: text: Your move has created the confusing situation where a (category) page is the target of a redirect from the page without the category, and there's a double redirect to boot.  Shouldn't this have gone to WP:RM?  I'd put it there now, if I was sure what to say.  --Tardis 21:05, 17 November 2006 (UTC)
thread_title: Second thoughts on move

message: I think we don't need to describe the C pointer syntax since Wikipedia is not a tutorial (and in any case we can't tell everything important about that in one section). — Vano 14:11, 2 November 2007 (UTC)
replies: text: The difference is what is the purpose.  I wrote that to demonstrate pointers.  It just so happens that C is very adept at pointers, pointer arithmetic, and general uses of pointers.  The point is to explain what a pointer is and one conceptualization (C) of how pointers are used.  That is why it's not a tutorial on "How to use pointers in C".   Cburnett 00:40, 7 November 2007 (UTC)
thread_title:  C tutorial 

message: This reads like a tutorial on C programming rather than an encyclopedic description of a concept.  The wording and language used is at odds to that of the C standard or even the canonical text on C programming, "The C programming Language" by K&R. I think we can do better than this.  I vote to discard it. 203.158.49.249 (talk) 23:42, 25 October 2009 (UTC)
thread_title:  Vote to remove section on C programming. 

message: I think the "pointer diagram" may be improved in 3 ways:
# The left column of addresses shows only 4 digits while the actual addresses on right side holds 8. Which makes the figure uselessly difficult to interpret --precisely for people who need it.
# The figure shows a second name "b" for the value while in the typical case (ag C pointer) there is only one name, the name of the pointer variable. This is precisely what differentiates a pointer from a (meta-)symbol, or a real reference.
# The figure does not show the first step of deferencing, namely the lookup for the name "a" in a symbol table, which provides for
#* the address (000000008) of the value,
#* an indication of the type of the pointer which allows the magic indirection --by interpretating the first value as an address,
#* typically, ,the type of the value itself.
(See below more comment on this.)
To sum up, there may be over the current figure: a pointer definition in pseudo-code, followed by a mini-schema showing the table lookup, which should include at least the initial address (00000008) and a sign telling that we are confronted to a pointer, not a value.
=== pointer specificity ===
This addition may usefully illustrate the pointer specificity, namely:
* That it is an indirection compared to direct value access.
* That it is a shortcut compared to a symbolic reference (no need for a second symbol table lookup).
 I try to illustrate what I mean below:
 * "friend: xxxxxxx" represents a table lookup for name "friend"
 * "<Person>" represents a type
 * "#00001008 --> 00000011" represents reading a value from an address
 
 ~~~ direct access ~~~
 friend: <Person> #00000008 --> 0000000011
 
 ~~~ pointer access ~~~
 friend: <Pointer> <Person> #00000008 --> #00001008 --> 0000000011
 
 ~~~ symbolic access ~~~
 friend: <Symbol> #00000008 --> person1: <Person> #00001008 --> 0000000011
--Denispir (talk) 14:51, 28 November 2009 (UTC)
thread_title:  pointer diagram figure & pointer specificity 

message: This addition may usefully illustrate the pointer specificity, namely:
* That it is an indirection compared to direct value access.
* That it is a shortcut compared to a symbolic reference (no need for a second symbol table lookup).
 I try to illustrate what I mean below:
 * "friend: xxxxxxx" represents a table lookup for name "friend"
 * "<Person>" represents a type
 * "#00001008 --> 00000011" represents reading a value from an address
 
 ~~~ direct access ~~~
 friend: <Person> #00000008 --> 0000000011
 
 ~~~ pointer access ~~~
 friend: <Pointer> <Person> #00000008 --> #00001008 --> 0000000011
 
 ~~~ symbolic access ~~~
 friend: <Symbol> #00000008 --> person1: <Person> #00001008 --> 0000000011
--Denispir (talk) 14:51, 28 November 2009 (UTC)
thread_title:  pointer specificity 

message: It's not guaranteed to segfault, anything can happen, even if you write there. There are environments that just don't care and give you the rope, others don't even have any memory protection for the first thing.
Also, the article talks about pointers as if they were ints. While this certainly explains things, and while in practice they usually are, technically they don't need to be. They could be reference numbers or something similar. AFAIR  p = malloc(16)+20 is already nasal  demons game over, even if you never use *p. --92.78.21.188 (talk) 17:28, 29 December 2009 (UTC)
thread_title:  * ((char *) 0) is nasal demons 

message: This external link is not working for me: Tutorial: C++ pointers by Alf P. Steinbach
It may be a temporary down-time, so I suppose we watch it, and remove it if it does not exist any more.  —Preceding unsigned comment added by 80.98.89.246 (talk) 21:50, 12 March 2010 (UTC)
thread_title:  External links 

message: C implementations that permit malloc(0) to return NULL violate the principle that live pointers returned by distinct malloc() calls must compare as distinct pointers.  In practice, this means that successful returns from malloc(0) must consume address space (but not necessarily actual memory).  It must be legal to load these addresses into pointer registers (modulo "as if"), but not to dereference.  If the fine print differs from this, there are many of us who would shoot on sight, standard or not. What's this noise about errno as a discriminator?  Can I puke now?  I don't hold to the maxim that all empty buckets are created equal.  Zero is the greatest of all numbers, not the least. — MaxEnt 03:48, 3 April 2011 (UTC)
thread_title: Uniqueness of malloc() results

message: The description below the diagram at the beginning claims that both, the memory addresses and the stored values, are hexadecimal numbers. But looking at the addresses would suggest a decimal system since 09 is followed by 10. Should the description be fixed or the diagram? Or am I just missing something (probably not)?  —Preceding unsigned comment added by 109.233.64.81 (talk) 00:31, 11 April 2011 (UTC)
replies: text: Yes, it appears to be a mistake. The image itself (line 387) needs to be corrected, to change the 1010 to 100A. — Loadmaster (talk) 18:37, 11 April 2011 (UTC)
replies: text:  I personally think it would be better to change the '8' in the value to which 'a' points to a '1' or '0' and then call it a binary number (because there are 8 such numbers, so it could be a fairly standard 8-bit byte, especially given the leading zero and the fact that the other such value is already all 1s and 0s). Then, just call the address column values 'decimal numbers'; after all, many people might find decimal values easier to understand. Mfwitten (talk) 20:41, 11 April 2011 (UTC)
replies: text:  I edited the SVG and the description to be more generic. Mfwitten (talk) 22:38, 11 April 2011 (UTC)
thread_title:  Values in diagram 

message: After skimming the beginning of this article (I have no idea whether it is accurate), I have concluded that both the original and final text of this edit are incorrect or misleading; in particular:
* Old: A process of course has access to its entire virtual address space; the remark about address 0x400000 is not really correct. In fact, a process's virtual address space is only write-protected for addresses 0-to-0xFFFF under Windows Me/98/95.
* New: This doesn't make any sense: "Windows maps its virtual address space to start at physical location 0x00400000"; for one thing, each process has a virtual address space, and secondly, there's no way each process's virtual address space would be mapped to start at the same physical address.
I'm getting rid of the Windows example. Mfwitten (talk) 23:50, 9 May 2011 (UTC)
thread_title:  Windows's Virtual Addresses 

message: You are invited to join the discussion at Talk:Pointer#Mouse cursor.  -- Trevj (talk) 11:02, 1 November 2011 (UTC)
thread_title: Move to [[Pointer (programming)]]

message: Would it be appropriate to include a history section? I see Harold Lawson "is credited with the 1964 invention of the pointer.[1] In 2000, Lawson was presented the Computer Pioneer Award by the IEEE [2] for his invention." The wording of the award [ref 2] is also informative: “For inventing the pointer variable and introducing this concept into PL/I, thus providing for the first time, the capability to flexibly treat linked lists in a general-purpose high level language”.
Also, where in the TOC should this be placed?  humanengr (talk) 03:47, 18 April 2013 (UTC)
thread_title:  History section? 

message: see page from 2009 here where the diagram originates
https://en.wikipedia.org/w/index.php?title=Pointer_%28computer_programming%29&diff=324903182&oldid=324596904#/media/File:Pointers.pngken (talk) 05:33, 5 May 2015 (UTC)
thread_title:  Pointer diagram copied from original work of Kdakin 

message: Hello fellow Wikipedians,
I have just modified  on Pointer (computer programming). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit User:Cyberpower678/FaQs#InternetArchiveBot*this simple FaQ for additional information. I made the following changes:
*Added archive http://web.archive.org/web/20090824073244/http://pplab.snu.ac.kr:80/courses/adv_pl05/papers/p261-knuth.pdf to http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).
Cheers.—cyberbot IITalk to my owner:Online 02:41, 11 June 2016 (UTC)
thread_title:  External links modified 

message: Currently the "cursor" disambiguation page says "Cursor may refer to: ... Cursor, a value that is the position of an object in some known data structure, a predecessor of pointers ..."
with a link to this Pointer (computer programming) page.
So when I clicked on that link, I expected this page to at least mention "cursor" somewhere,
and perhaps this page might discuss other predecessors of pointers (if any).
Alas, currently this page doesn't seem to mention either.
What are the predecessor(s) of pointers?
Is there some other more general article (perhaps reference (computer science)) that would be better for discussing the history of pointers and similar things -- cursors, handles, array index, etc.?
--DavidCary (talk) 07:24, 23 January 2021 (UTC)
thread_title:  cursor 

message: "However, most implementations simply halt execution of the program in question, usually with a segmentation fault." 
This is false. No C implementation disallows accessing the NULL pointer, because it is perfectly valid behavior for an OS to map the 0 address to physical memory. Most operating systems don't do that by default because of the safety implications, but the compiler doesn't know about that.
2A02:A44A:5C96:1:B446:3A68:C785:C0CB (talk) 05:08, 12 April 2022 (UTC)
thread_title:  Dereferencing NULL in C is not implementation defined