macOS Pointers in C... can anyone help me understand?

ytk · Feb 5, 2013

ravenvii said:
So the word[] part of the prototype is just window dressing, like the const part?

Sorta. The [] notation is just a way of specifying a pointer.

ravenvii said:
And if the argument is automatically converted to a pointer to the first element of the array, why does the 'array' work as expected in the function itself? i.e. I was able to access all elements of the array in the manner one would expect?

In C, declaring an array creates a pointer which is stored in the variable specified, which points to the head of the array. In fact, the [] operator is effectively a macro, such that foo[10] expands to *(foo + 10). The upshot of this is you can also write 10[foo] and it will compile and run just fine.

So when you say that a function is taking an array as an argument, you're really saying that it's taking a pointer to an array. All array operations involve pointers, though it may not be entirely obvious at first that this is the case.

chown33 · Feb 5, 2013

ravenvii said:
I thought I read somewhere that const is only there to reassure the user that the function doesn't modify what's passed to it, but doesn't actually do anything? Maybe that's just with older compilers?

Try writing the function so it modifies the data referenced by the const pointer. The compiler will forbid this (produce an error).

The 'const' is part of the "contract" of the function declaration. For callers that include the declaration, it tells them (and the programmer) that the function won't modify the data pointed at. For the implementation of the function, i.e. its definition, it tells the compiler to enforce read-only access, and doesn't permit the function to modify the data pointed at. Of course, if you recast to non-const, the compiler assumes you know what you're doing. A lot of C is like that: it assumes you know what you're doing.

gnasher729 · Feb 5, 2013

ytk said:
In C, declaring an array creates a pointer which is stored in the variable specified, which points to the head of the array.

That is totally wrong. No pointer is stored anywhere in any variable when an array is declared. An array consists of its elements, and nothing else.

----------

ravenvii said:
So the word[] part of the prototype is just window dressing, like the const part?

And if the argument is automatically converted to a pointer to the first element of the array, why does the 'array' work as expected in the function itself? i.e. I was able to access all elements of the array in the manner one would expect?

The [] is just window dressing.
The "const" is not. It means the pointer that the function receives is a "pointer to const char". That means the compiler won't let you modify the data that the pointer points to through that pointer.

Why does it work? Take both parts together. The caller passes a pointer to the first array element, and the function expects a pointer. So that matches. Once you have a pointer to the first array element, you can access the other elements as well. In your case:

word [0] or *word - The first element of the array
word [1] or * (word + 1) - The second element of the array
word [2] or * (word + 2) - The third element of the array.

----------

ghellquist said:
Nop. They mean exactly what you say. The function is passed an array of characters...

C11 Standard, 6.7.6.3 sentence 7: "A declaration of a parameter as ‘‘array of type’’ shall be adjusted to ‘‘qualified pointer to type’’, where the type qualifiers (if any) are those specified within the [ and ] of the array type derivation. "

You cannot declare a function in C (or C++, or Objective-C, or Objective-C++) that has a parameter of an array type.

----------

ytk said:
Respectfully, I disagree. I've explained pointers quite a few times over the years, and I've found that the clearest understanding comes once your realize that a pointer IS simply a number. The only difference is what you do with the number.

Ok. Now try to explain what a "restrict pointer" is. Try explaining why pointers that point into the same array, and pointers pointing to different arrays, are treated differently. Try explaining aliasing. Going back in history, try explaining what's the difference between a "far pointer" and a "huge pointer". Try explaining why it is ok to write "char* p = 0;" but not "char* p = 1;" and not "int i = 0; char* p = i;". Try explaining what a C++ reference is. Try explaining a pointer cast in C++.

ytk · Feb 5, 2013

gnasher729 said:
That is totally wrong. No pointer is stored anywhere in any variable when an array is declared. An array consists of its elements, and nothing else.

int foo[20];

Now, what type is foo? Const pointer to int. I've declared an array, and the pointer to the array is stored in the variable specified. I don't understand what the problem here is. Are you saying that no memory is allocated for the variable that holds the pointer itself? Okay, fine, but I didn't say that. As far as the C compiler, and thus the programmer, is concerned, you can use the variable foo in any context that calls for a pointer as an rvalueyou can assign it to another pointer, for example.

gnasher729 said:
Ok. Now try to explain what a "restrict pointer" is. Try explaining why pointers that point into the same array, and pointers pointing to different arrays, are treated differently. Try explaining aliasing. Going back in history, try explaining what's the difference between a "far pointer" and a "huge pointer". Try explaining why it is ok to write "char* p = 0;" but not "char* p = 1;" and not "int i = 0; char* p = i;". Try explaining what a C++ reference is. Try explaining a pointer cast in C++.

None of the things listed here change anything about the fundamental nature of pointers. Think about what the term pointer means for a second: It points to an address in memory. What is an address? A number. If you explain it any other way, you're just throwing layer upon layer of abstractions from the actual definition of what a pointer is, in an attempt to simplify the explanation for the novice user. Ultimately, all of these simplifications must be un-learned in order to advanceif they are understood at all in the first placebecause they are fundamentally wrong. If you imply that there is anything special at all about pointers as far as the computer is concerned, you're doing a disservice to those who are trying to learn from you.

Mac_Max · Feb 5, 2013

ytk said:
Sorta. The [] notation is just a way of specifying a pointer.

Perhaps we're going too meta here, but here's a good explanation of whats going on:

http://c-faq.com/decl/spiral.anderson.html

jon3543 · Feb 5, 2013

ytk said:
int foo[20];

Now, what type is foo? Const pointer to int. I've declared an array, and the pointer to the array is stored in the variable specified

Absolutely wrong. The type is "array of 20 ints". There is no pointer anywhere in that.

chown33 said:
All arrays passed to functions are passed as pointers.

See Section 6 of the C FAQs, which I linked to earlier:
http://c-faq.com/

Probably 99.9% of people I've seen who thought they understood arrays and pointers could still benefit significantly from reading that part of the C FAQ, so excellent call on that. ytk - this means you.

It is essential to understand the array-to-pointer standard conversion, which converts an array to a pointer to its first element in most contexts. This is the thing from which all the pointer-like behavior of arrays arises, and it is the explanation for chown33's first sentence. Then it's mainly a matter of understanding how pointers work. For example, array indexing is defined in terms of pointer arithmetic, and the first step from a[2] (where "a" is an array name) to *(a+2) is the array-to-pointer conversion. Then you need to understand pointer arithmetic. Then dereferencing the pointer result.

Arrays and pointers are not the same thing! An array is a region of storage containing elements of a single type one after the other, with no space in between. In contrast, a pointer is a scalar quantity whose defined values include NULL and memory addresses, the latter being the addresses of single objects, including objects within arrays.

An array name is not a pointer! The C FAQ 6.2 explains this. 6.1 could have further illustrated this, but it punts to Koenig's excellent "C Traps And Pitfalls" (1989), which I'm surprised to see is available on Amazon. However, if you understand 6.2 and the fact that your linker may treat the two declarations of "a" as a sort of union, you can explain what happens when you make the mistake in 6.1, and the compiler/linker system doesn't diagnose the problem and produces an executable file, as the present day Visual C++ 2012 continues to do, and probably most if not all others.

gnasher729 · Feb 5, 2013

ytk said:
None of the things listed here change anything about the fundamental nature of pointers. Think about what the term pointer means for a second: It points to an address in memory. What is an address? A number. If you explain it any other way, you're just throwing layer upon layer of abstractions from the actual definition of what a pointer is, in an attempt to simplify the explanation for the novice user. Ultimately, all of these simplifications must be un-learned in order to advanceif they are understood at all in the first placebecause they are fundamentally wrong. If you imply that there is anything special at all about pointers as far as the computer is concerned, you're doing a disservice to those who are trying to learn from you.

There are no layers at all: A pointer is just that - a pointer. Something that points to another item. That's the essence of a pointer. No layers. No simplification. You on the other hand are introducing an unnecessary and incorrect specialisation by claiming that a pointer is a number. It isn't. It's behaviour is different from a number. You can add numbers. You can't add pointers. You can multiply numbers. You can divide numbers. You can square numbers. You can't multiply, divide, or square pointers. It's nonsense.

Sam Yikin · Feb 5, 2013

gnasher729 said:
There are no layers at all: A pointer is just that - a pointer. Something that points to another item. That's the essence of a pointer. No layers. No simplification. You on the other hand are introducing an unnecessary and incorrect specialisation by claiming that a pointer is a number. It isn't. It's behaviour is different from a number. You can add numbers. You can't add pointers. You can multiply numbers. You can divide numbers. You can square numbers. You can't multiply, divide, or square pointers. It's nonsense.

Wouldn't it be correct to say that pointers are STORED as numbers but have a very different implementation and completely different utilities than numbers?

Sam Yikin · Feb 5, 2013

I hope you guys don't mind if I add a question: That awesome FAQ linked earlier said that while arrays and pointers are quite different ( I understand the differences), that anytime time an array is used in an expression, a pointer to the first element of the array is used instead? Even though arrays and pointers are separate items, that a pointer actually is used the vast majority of the time an array is used?

ytk · Feb 5, 2013

jon3543 said:
Absolutely wrong. The type is "array of 20 ints". There is no pointer anywhere in that.

An array name is an address constant, which means it refers to a specific address in memory directly (as opposed to a pointer variable, which stores an address in modifiable memory, and the pointer must be explicitly dereferenced to access the location pointed to).

The C99 specification (section 6.6) defines an address constant as follows:

An address constant is a null pointer, a pointer to an lvalue designating an object of static storage duration, or a pointer to a function designator; it shall be created explicitly using the unary & operator or an integer constant cast to pointer type, or implicitly by the use of an expression of array or function type.

So every address constant, including an array name, is by definition a pointer.

gnasher729 said:
You can add numbers. You can't add pointers.

You absolutely can do arithmetic on pointers. True, pointer arithmetic works a bit differently in C than with regular numbers, but that's just shorthand that the language provides to make pointers of data types larger than a single byte easier to deal with. If you wanted to, you could cast the pointers to integers of the appropriate size, do math on them at the byte level, and cast them back to pointers and it would work just fine (assuming your architecture doesn't have any data alignment issues or anything like that.)

jon3543 · Feb 5, 2013

Sam Yikin said:
I hope you guys don't mind if I add a question: That awesome FAQ linked earlier said that while arrays and pointers are quite different ( I understand the differences), that anytime time an array is used in an expression, a pointer to the first element of the array is used instead? Even though arrays and pointers are separate items, that a pointer actually is used the vast majority of the time an array is used?

As I wrote a couple of messages ago:

It is essential to understand the array-to-pointer standard conversion, which converts an array to a pointer to its first element in most contexts. This is the thing from which all the pointer-like behavior of arrays arises, and it is the explanation for chown33's first sentence. Then it's mainly a matter of understanding how pointers work. For example, array indexing is defined in terms of pointer arithmetic, and the first step from a[2] (where "a" is an array name) to *(a+2) is the array-to-pointer conversion. Then you need to understand pointer arithmetic. Then dereferencing the pointer result.

While the array-to-pointer conversion occurs in array indexing, passing arguments to functions, returning values from functions (that being a big gotcha for a local non-static array), etc, there are contexts in which it does not occur. A couple that come to mind include when an array is the operand of the address-of operator and sizeof. In C++, other examples include when binding to an array reference and when the array is the operand to typeid. In those instances, an array does not undergo the array-to-pointer conversion. There might be one or two more instances I'm not thinking of at the moment. But anytime an array occurs in other expressions, it undergoes the array-to-pointer conversion, e.g.

Code:

typedef struct S { int x; } S;
void f(S*);
void g()
{
   S s[10];
   S* p = s+5;
   s[1];
   *s;
   s->x;
   p-s;
   f(s);
}

In each of the expressions above involving s, s undergoes the array-to-pointer conversion. And it's not just named arrays that behave like this; it's also subarrays of multidimensional arrays, e.g.

Code:

S t[2][10];

The expressions t[0] and t[1] are both arrays with type S[10] and they behave just like s in the first example, to the extent you can substitute (say) t[0] for every occurrence of s. Note, however, that t contains no pointers at all. It's just a region of storage containing 20 S's, one after the other, in row major order.

Sam Yikin · Feb 5, 2013

jon3543 said:
As I wrote a couple of messages ago:

It is essential to understand the array-to-pointer standard conversion, which converts an array to a pointer to its first element in most contexts. This is the thing from which all the pointer-like behavior of arrays arises, and it is the explanation for chown33's first sentence. Then it's mainly a matter of understanding how pointers work. For example, array indexing is defined in terms of pointer arithmetic, and the first step from a[2] (where "a" is an array name) to *(a+2) is the array-to-pointer conversion. Then you need to understand pointer arithmetic. Then dereferencing the pointer result.

While the array-to-pointer conversion occurs in array indexing, passing arguments to functions, returning values from functions (that being a big gotcha for a local non-static array), etc, there are contexts in which it does not occur. A couple that come to mind include when an array is the operand of the address-of operator and sizeof. In C++, other examples include when binding to an array reference and when the array is the operand to typeid. In those instances, an array does not undergo the array-to-pointer conversion. There might be one or two more instances I'm not thinking of at the moment. But anytime an array occurs in other expressions, it undergoes the array-to-pointer conversion, e.g.

Code:

typedef struct S { int x; } S; void f(S*); void g() { S s[10]; S* p = s+5; s[1]; *s; s->x; p-s; f(s); }

In each of the expressions above involving s, s undergoes the array-to-pointer conversion. And it's not just named arrays that behave like this; it's also subarrays of multidimensional arrays, e.g.

Code:

S t[2][10];

The expressions t[0] and t[1] are both arrays with type S[10] and they behave just like s in the first example, to the extent you can substitute (say) t[0] for every occurrence of s. Note, however, that t contains no pointers at all. It's just a region of storage containing 20 S's, one after the other, in row major order.

Thank you for your reply, that was very helpful and informative. I've always been fuzzy on the differences between arrays and pointers but you've cleared it up nicely.

jon3543 · Feb 5, 2013

ytk said:
An array name is an address constant, which means it refers to a specific address in memory directly (as opposed to a pointer variable, which stores an address in modifiable memory, and the pointer must be explicitly dereferenced to access the location pointed to).

The C99 specification (section 6.6) defines an address constant as follows:
An address constant is a null pointer, a pointer to an lvalue designating an object of static storage duration, or a pointer to a function designator; it shall be created explicitly using the unary & operator or an integer constant cast to pointer type, or implicitly by the use of an expression of array or function type.

So every address constant, including an array name, is by definition a pointer.

ytk: Again, absolutely wrong. You should be learning from basic references, then tackle the C FAQ. You do not have the basic knowledge necessary to understand the C Standard, and that document is not written to be a teaching aid. Read what I wrote about the array-to-pointer conversion and everything else I wrote. It is correct. For example, here is what C99 says about arrays (this is from my 1997 draft copy):

6.1.2.5/17
An array type describes a contiguously allocated nonempty set of objects with a particular member object type, called the element type.

6.2.2.1/3
Except when it is the operand of the sizeof operator or the unary & operator, or is a character string literal used to initialize an array of character type, or is a wide string literal used to initialize an array with element type compatible with wchar_t, an lvalue that has type array of type is converted to an expression that has type pointer to type that points to the initial element of the array object and is not an lvalue.

These agree with the definitions I gave for arrays and for the array-to-pointer conversion. When the irrelevant bit you quoted about "address constants" talks about their production "implicitly by the use of an expression of array type", which is the only thing it says about arrays, this implicit production is due to the array-to-pointer conversion I've been talking about. It does not support your repeated wrong assertions that arrays are constant pointers. Also, the use of the term "expression" further renders the section irrelevant to your claim about array names, because the following is a declaration, not an expression:

int x[10];

These are defined terms the standard uses in precise ways. The section you quoted simply doesn't contribute to what is meant by an "array name", and FWIW, "array names" aren't even the fundamental thing anyway WRT array behavior, as I alluded to at the end of my previous message when I talked about subarrays in multidimensional arrays.

jon3543 · Feb 5, 2013

Sam Yikin said:
Wouldn't it be correct to say that pointers are STORED as numbers but have a very different implementation and completely different utilities than numbers?

Everything in a computer is stored as a "number", ultimately sequences of bits of various lengths that are assigned various meanings. If you want to talk about something, talk about types. That's the fundamental concept. A type is a set of values and operations defined on those values. It's rather redundant to make a point out of those values being "numbers". What else would they be?

ytk · Feb 5, 2013

jon3543 said:
It does not support your repeated wrong assertions that arrays are constant pointers.

I never once asserted that. There's a difference between an array and an array name. Please read my original statement:

ytk said:
In C, declaring an array creates a pointer which is stored in the variable specified, which points to the head of the array.

Does it say an array is a pointer? No. It explicitly says declaring an array creates a pointer (the address constant) which is stored in the variable specified (the array name). Isn't that self-evident? How else would you refer to that location in memory, if not via a pointer? It's not precisely the same as an explicitly defined pointer, in that it's not held in memory at runtime and thus cannot be modified, but it is a pointer nevertheless when used in almost any context.

jon3543 said:
Also, the use of the term "expression" further renders the section irrelevant to your claim about array names, because the following is a declaration, not an expression:

int x[10];

Yes, but “x” is an expression, which generates an address constant, which is explicitly defined as a pointer. I didn't ask what “int foo[20]”, or “int foo[]” is. I asked about “foo”, which is an expression, not a declaration.

But okay, fine. Let me clarify my original statement for you:

In C, declaring an array defines a memory address which is stored in the name specified, which points to the head of the array. When using that name in very nearly any context, it returns a value that acts exactly like a pointer.

That statement, while technically a more accurate description of what is going on under the hood, provides more information than is necessary for comprehension and is likely far more confusing to a novice. Happy now?

jon3543 · Feb 5, 2013

ytk said:
I never once asserted that. There's a difference between an array and an array name. Please read my original statement:

In C, declaring an array creates a pointer which is stored in the variable specified, which points to the head of the array.

Does it say an array is a pointer? No. It explicitly says declaring an array creates a pointer (the address constant) which is stored in the variable specified (the array name).

For at least the third time, ALL OF THAT IS ABSOLUTELY WRONG.

Yes, but x is an expression, which generates an address constant, which is explicitly defined as a pointer. I didn't ask what foo[20], or foo[] is. I asked about foo, which is an expression, not a declaration.

The things you've said in several posts that I've replied to include:

ytk sez

int foo[20];

Now, what type is foo? Const pointer to int. I've declared an array, and the pointer to the array is stored in the variable specified

-----

An array name is an address constant... So every address constant, including an array name, is by definition a pointer.

All of that is just trivially wrong, and besides not understanding much about C, you don't even seem to comprehend what you've written, as you're denying saying those things you plainly said. You're not even making an effort to learn. Judging by your lack of comments and questions, you haven't read the C FAQ recommended to you by several people, which explains why you're wrong. Nor have you asked anything about the array-to-pointer conversion, which is the key to clearing up a big part of your misunderstanding.

P.S. I'm putting your past posts in italics because otherwise they get clipped when I reply, and I can't figure out how to make this board preserve more than one level of quotes. Having to go back and find those statements makes this whole thing even more tedious.

jon3543 · Feb 5, 2013

ytk said:
But okay, fine. Let me clarify my original statement for you:

In C, declaring an array defines a memory address which is stored in the name specified, which points to the head of the array. When using that name in very nearly any context, it acts exactly like a pointer.

That statement, while technically a more accurate description of what is going on under the hood, provides more information than is necessary for comprehension and is likely far more confusing to a novice. Happy now?

Please stop putting your statements in quote tags. When I quote your message, they do not appear in mine, and I have to go back to yours and copy/paste.

Your revision is not an improvement. When you declare:

int x[10];

The only thing that exists in memory is the array of 10 ints. (For the definition of "array", see my previous posts.) There is no pointer anywhere in it or around it. In particular, x is not a pointer. It is harmful to think of it as a pointer. The identifier x merely is the name for this array, and it is not an object in its own right. Thus, it is ABSOLUTELY WRONG to say that "declaring an array defines a memory address which is stored in the name specified, which points to the head of the array".

ytk · Feb 5, 2013

jon3543 said:
Your revision is not an improvement. When you declare:

int x[10];

The only thing that exists in memory is the array of 10 ints.

Yes, I said that: It's not precisely the same as an explicitly defined pointer, in that it's not held in memory at runtime and thus cannot be modified

I'm tired of arguing with you about this, particularly when you repeatedly tell me I've said things I didn't say, or explicitly said the precise opposite of. I'm not even sure what the argument is about, because I basically agree with everything you're saying conceptually.

Yes, I get it. An array is not a pointer. I've said that numerous times. Referencing an array by name returns a pointer, so you can treat the array name exactly as if it were a pointer to the start of the array. That's really all I'm trying to say here. If you think I ever said anything different, then I was simply unclear. Okay?

gnasher729 · Feb 6, 2013

Sam Yikin said:
Wouldn't it be correct to say that pointers are STORED as numbers but have a very different implementation and completely different utilities than numbers?

How would that help with any understanding? And are they stored as floating point numbers or integer numbers? Signed or unsigned integer numbers? If they are stored as numbers, it could be either, right? So things get more confused immediately.

And once you get to things like multiple inheritance in C++, references in C++, blocks in Objective-C, distributed objects, or more interesting hardware like an AS400, this "pointer = number" thing _really_ makes it hard to understand what's actually going on.

ytk said:
Yes, but “x” is an expression, which generates an address constant, which is explicitly defined as a pointer. I didn't ask what “int foo[20]”, or “int foo[]” is. I asked about “foo”, which is an expression, not a declaration.

Code:

void f (int array [20])
{
    printf ("Size of array parameter is %d\n", (int) sizeof (array));
}

int main (void)
{
    int array [20];
    printf ("Size of array is %d\n", (int) sizeof (array));
    f (array);
}

Run this code. Explain the results. Then go to my first post, read rules (2) and (3) carefully, and check whether they make the result absolutely predictable.

jon3543 said:
Everything in a computer is stored as a "number", ultimately sequences of bits of various lengths that are assigned various meanings. If you want to talk about something, talk about types. That's the fundamental concept. A type is a set of values and operations defined on those values. It's rather redundant to make a point out of those values being "numbers". What else would they be?

More precisely, everything in C (but not in C++) has a "representation", which is the sequence of bytes filling the memory occupied by the object. So on a Mac, a pointer will have a "representation" consisting of four or eight bytes. Assuming that this representation means anything can stop you from understanding more difficult concepts.

balamw · Feb 6, 2013

jon3543 said:
Please stop putting your statements in quote tags. When I quote your message, they do not appear in mine, and I have to go back to yours and copy/paste.

MOD NOTE:

This isn't great advice. The quote tags generate quote notifications it's a great way to note that someone is replying to your previous message.

Also the tone of the thread has become a bit personal. Dial it back a bit please or we'll have to put this one down.

B

ghellquist · Feb 6, 2013

I think i will leave this discussion.

I guess we can agree that a discussion about pointers in c quickly can become, hmm, sort of complicated. That is why we should recommend any beginning programmer to follow a well-thought curriculum in learning how to use pointers.

Every-one will then go from the simple things into more complicated matters. On the way, the understanding will deepen and maybe even change. The final authority on how a c program should behave is the standard document, but in order to actually understand that you need a firm base in computer science.

And any actual implementation might add further "complications". I remember one version of a c compiler where you could select between small, medium and large memory model, each handling pointers quite differently inside the program. In the small model, pointers could only point to a small memory area of 256 bytes. In this mode the compiler could not follow the full c specification, but you could do decent things within the limits regardless.

jon3543 · Feb 6, 2013

balamw said:
MOD NOTE:

This isn't great advice. The quote tags generate quote notifications it's a great way to note that someone is replying to your previous message.

That's different than what I'm talking about. In his own messages, ytk has been putting things he said in quote tags (sometimes modifying them) and intending them to be new comments. See the end of this message for an example:

https://forums.macrumors.com/posts/16795641/

This makes it hard to reply to him, because those parts don't appear when I quote his message. When I quote the above linked message to reply, the end of it appears as follows (I'm using italics and my own pseudo-tagging because this is part of my message, and using quote tags would cause the problem I'm complaining about if someone were to reply to it):

*****ytk {*****
But okay, fine. Let me clarify my original statement for you:

///// part ytk put in quote tags missing here /////

That statement, while technically a more accurate description of what is going on under the hood, provides more information than is necessary for comprehension and is likely far more confusing to a novice. Happy now?
*****} ytk*****

Like I said, I have to go back and copy and paste to restore the missing part. This would not be a problem if the forum were configured to leave nested quote tags alone. I looked for an option to enable this feature, but like I said earlier, I didn't find it.

I can understand the motivation for disabling nested quotes, but most forums don't do it, and it's fairly common to use quote tags as ytk has done rather than using "real quotes", because it sets the quoted text apart better. Moreover, unless a reply to a quoted part includes everything necessary to understand the reply, you have to go back to the original to get the proper context, which can get really tedious when people break a message into multiple quoted parts to respond inline, as they typically don't copy the little link to the antecedent message in each quoted part they separate out. For all these reasons, I think it's best not to have the forum software effectively edit replies by stripping nested quotes and require people to trim quotes themselves, despite all the problem with that policy.

macOS Pointers in C... can anyone help me understand?

macrumors 6502

Moderator

Suspended

macrumors 6502

macrumors 6502

macrumors 6502a

Suspended

macrumors regular

macrumors regular

macrumors 6502

macrumors 6502a

macrumors regular

macrumors 6502a

macrumors 6502a

macrumors 6502

macrumors 6502a

macrumors 6502a

macrumors 6502

Suspended

Moderator emeritus

macrumors regular

macrumors 6502a

Our Staff