Neatest way to get the end pointer?

[Richard Heathfield]

Malcolm McLean said:

Pointer arithmetic is confusing.

What is it about pointer arithmetic that you find confusing?

 

[Malcolm McLean]

It *should* make you wonder.
NULL makes the code easier to read.
That's a strong reason for using it.

It makes it harder to read, in my opinion.
"null" should be a keyword and ptr = 0 should be illegal. However that
raises issues of old code that uses memset or calloc to intialise pointers
to null.

"NULL" shouts, and gives the null pointer an emphasis it normally should not
have.

 

[Walter Roberson]

Malcolm McLean said:

What is it about pointer arithmetic that you find confusing?

Eliza: Have you always What is it about pointer arithmetic that you
find confusing?

 

[Keith Thompson]

It makes it harder to read, in my opinion.
"null" should be a keyword and ptr = 0 should be illegal.

I actually agree that this would have been better, but it would break
too much existing code and therefore will never happen in a language
called "C". The most that could be done is to add a new _Null
keyword, which is a new special null pointer constant that cannot be
used in a non-pointer context. You could then have "#define null
_Null" or perhaps "#define nil _Null" in a new standard header. But I
doubt that there would be enough support for this, especially given
the necessity of preserving the existing forms.

However that
raises issues of old code that uses memset or calloc to intialise
pointers to null.

Such code is already broken^H^H^H^H^H^H non-portable; adding a "null"
keyword would not affect that.

"NULL" shouts, and gives the null pointer an emphasis it normally
should not have.

In C source, all-caps identifiers are conventionally used for macros
(no, the standard library does not consistently follow this
convention). It doesn't imply shouting as it does in English text.

 

[Malcolm McLean]

Eliza: Have you always What is it about pointer arithmetic that you
find confusing?

Tell me more about your pointer arithmetic.

 

[Richard Tobin]

Malcolm McLean said:

What is it about pointer arithmetic that you find confusing?

He said it's confusing, not that he is confused by it.

Certainly many people do seem to get confused by it. Other things
being equal, it's usually clearer to express an array traversal in
terms of an index, and modern compilers should generate at least
as good code.

-- Richard

 

[user923005]

Malcolm McLean said:



What is it about pointer arithmetic that you find confusing?

That void pointers have no stride, and yet you can do this:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
void *p[5][5];
p[0][0] = NULL;
return 0;
}

 

[pete]

an emphasis it normally should not have.

Isn't that what you say about *all* capitalized macros?

 

[Malcolm McLean]

Isn't that what you say about *all* capitalized macros?

Yes. Macros like clamp(), lerp(), uniform(), and so on are sufficiently
function-like that it makes sense to use the same typography as functions.
You can make a legitimate case that caller should be warned about the
side-effect of passing an increment or += to the macro. Nothing is black and
white. However Nintendo's N64 graphics pipeline macros, which had to take an
arguement of the form ptr++ because they sometimes expanded to two or more
pipeline comands, were made to look like function calls.

This is also the convention set by the standard library.

Structures, however, should shout, because they are big. Hence FILE or JPEG
might refer to very significant memory objects.

So lower case for portable macros, mixed case for macros that depend on
something other than the standard library, as with fucntions, caps for
structure typedefs.

 

[pete]

Malcolm McLean wrote:

Pointer arithmetic is confusing.

I like pointer math.
I also like to modify function parameters
at every given opportunity.

I think the two are related,
because a lot of parameters tend to be pointers.

 

[Walter Roberson]

Yes. Macros like clamp(), lerp(), uniform(), and so on are sufficiently
function-like that it makes sense to use the same typography as functions.

Structures, however, should shout, because they are big. Hence FILE or JPEG
might refer to very significant memory objects.

A function can involve "very signficant memory objects" (the code),
but that is of no concern to you?

 

[Ben Pfaff]

What is it about pointer arithmetic that you find confusing?

That void pointers have no stride, and yet you can do this: [...]
void *p[5][5];
p[0][0] = NULL;

[...]

May we assume that you do understand what is going on here,
though?

 

[Malcolm McLean]

I like pointer math.
I also like to modify function parameters
at every given opportunity.

I think the two are related,
because a lot of parameters tend to be pointers.

That was part of the justification for it. Stepping through an array with i
would involve creating an unnecessary temporary, and probably a bit of
useless arithmetic to dereference, whilst if you just incremented the
pointer the generated machine code would be tighter.

However computers are faster now and optimisers more aggressive. There's a
school of thought that parameters should be treated as read-only.

 

[Malcolm McLean]

A function can involve "very signficant memory objects" (the code),
but that is of no concern to you?

No. It's platform dependent, and if we manipulate that memory, which is
extremely rare, and rarer still a good idea, we've left the bounds of
portable C programming altogether.

 

[Walter Roberson]

There's a
school of thought that parameters should be treated as read-only.

Are you talking about code such as

int main(int argc; char **argv) {
argc--;
argv++;
while (argc-- > 0) puts(*argv++);
return 0;
}

in which the parameters argv and argc are modified?

Or are you talking about modifying something -pointed to- by a
parameter?

If you are talking about something -pointed to- by a parameter,
and want to rule out modifying things pointed to by parameters,
then you need a language that returns multiple values
distinctly,
[x y z] = foo(someparameter);
instead of
x = foo(someparameter,&y,&z);
Or else you need to always wrap multiple return values in a struct.

If you are indeed talking about not allowing things pointed to
by parameters to be modified, then you would lose the ability for a
routine to pass in its own buffer to a function.

 

[user923005]

That void pointers have no stride, and yet you can do this: [...]
    void            *p[5][5];
    p[0][0] = NULL;

[...]

May we assume that you do understand what is going on here,
though?

Sure, but didn't it seem confusing to you, the first time you found
out that void pointers have no stride and yet you can make multi-
dimentional arrays of them?

 

[Walter Roberson]

No. It's platform dependent,

Sounds to me like you have not considered Kolmogorov complexity in
this matter. Some functions are inherently complex, and cannot be
written smally except each in some language tailor-made to express
that one function smally.

and if we manipulate that memory, which is
extremely rare, and rarer still a good idea, we've left the bounds of
portable C programming altogether.

Invoking a routine is a form of manipulating memory.

If you want to have textual case distinguish object size, then
you need to be consistant and have large functions distinguished by
uppercase, as reminders that they are space-expensive to invoke.

printf() is a good traditional example: an integer-only program
that invokes printf() must be linked with the floating point library
(if there is a seperate floating point library) because printf()
needs floating point linked it case the user specified a floating
point formating element. It was not uncommon in the earlier days
for an integer-only program to be a fairly small number of Kb but
to kick up by several hundred Kb because printf() was referenced.

 

[Keith Thompson]

Malcolm McLean said:



What is it about pointer arithmetic that you find confusing?

That void pointers have no stride, and yet you can do this:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
void *p[5][5];
p[0][0] = NULL;
return 0;
}

Sorry, I don't see what's confusing about that, other than the
potentially misleading statement that "void pointers have no stride".

p is a two-dimensional array of elements, where the size of each
element (the stride, if you like) is typically something like 4 or 8
bytes. The fact that each element happens to be a void* is
irrelevant; we're not treating the elements as pointers, just as
objects.

p is an array 5 of array 5 of pointer to void, which decays to
a pointer to an array 5 of pointer to void.

p[0] is an array 5 of pointer to void, which decays to a pointer to
pointer to void.

p[0][0] is a pointer to void; we assign a value to it.

The behavior, and the logic behind it, would be the same for:

int p[5][5];
p[0][0] = 0;

Am I missing something?

 

[pete]

Are you talking about code such as

int main(int argc; char **argv) {
argc--;
argv++;
while (argc-- > 0) puts(*argv++);
return 0;
}

in which the parameters argv and argc are modified?

He was.
I am familiar with that school of thought.
"I'm on the other side of that issue."

 

[Tomás Ó hÉilidhe]

Malcolm McLean:

Structures, however, should shout, because they are big. Hence FILE or
JPEG might refer to very significant memory objects.

So lower case for portable macros, mixed case for macros that depend
on something other than the standard library, as with fucntions, caps
for structure typedefs.

The uppercase letters in a macro's name are the wasp's stripes. They're
there to make you think "Oh Christ I better not pass an argument whose
evalution has sideeffects". Thankfully, this convention is well
propogated throughout the "C community".

Using all uppercase letters for types is useless... if anything it just
introduces a "boy who called wolf" situation for when you come across a
situation where you actually need to be warned.

My own personal convention is:

1) Objects: All lowercase, words separated with underscores

my_array
quantity_places

2) Functions and types: Leading uppercase letter, words separated with
uppercase letters:

KillAllPointers();
Reset();
ChangeName();

3) Macros: ALL UPPERCASE, the wasp's stripes:

CONVERT_TO_PLACE();