help a beginner with a basic function that should return a char

[luserXtrog]

Thanks, Korzybski.
But there is also a basic similarity between addresses and integers,
particularly where the integer is employed to index an array.
A pointer is an index to any location in the process memory space.
Using an index to a smaller portion of that memory can improve
locality.

You can probably find a basic similarity between just about any two
concepts.

Your model of a pointer as "an index to any location in the process
memory space" assumes a monolithic linear addressing space, where all
of memory can be treated as a single array of bytes.  C does not
require such a model, and there are machines that don't use it.

You can add or subtract an integer to a pointer and get another
pointer, you can subtract one pointer from another to get an integer,
and you can compare two pointers using <, <=, >, or >=.  But all
these operations are defined only within a single object.

[...]

Understood. But as a neo-pythagorean, my hackles rise automatically
when anyone suggests X is not a number. My sense of holism attempts
to retaliate by identifying a universe of discourse in which the
two dissolve into one. Occasionally this corresponds to mathematical
abstraction; but often it is merely poetic.

Perhaps the true situation is more of a superposition of the dual
intepretation: pointers are numbers and pointers are not numbers.

I think [feel] that in this example the similarities are more
important than the differences; because it may lead to the notion
of separating the boolean nature of the function's return value
from the resulting encoded output.

 

[Keith Thompson]

Your model of a pointer as "an index to any location in the process
memory space" assumes a monolithic linear addressing space, where all
of memory can be treated as a single array of bytes.  C does not
require such a model, and there are machines that don't use it.

You can add or subtract an integer to a pointer and get another
pointer, you can subtract one pointer from another to get an integer,
and you can compare two pointers using <, <=, >, or >=.  But all
these operations are defined only within a single object.

[...]

Understood. But as a neo-pythagorean, my hackles rise automatically
when anyone suggests X is not a number. My sense of holism attempts
to retaliate by identifying a universe of discourse in which the
two dissolve into one. Occasionally this corresponds to mathematical
abstraction; but often it is merely poetic.

Perhaps the true situation is more of a superposition of the dual
intepretation: pointers are numbers and pointers are not numbers.

The word "number" can be applied to many different mathematical
concepts: integers, reals, rationals, complex numbers. quaternions,
et cetera literally ad infinitum.

So if you want to think of pointers as a kind of "number" in some
abstract mathematical sense, one that covers signed and unsigned
integers, floating-point numbers, and (for languages that support such
things) rational numbers and so forth, go ahead.

The point is that pointers are not *integers*.

I think [feel] that in this example the similarities are more
important than the differences; because it may lead to the notion
of separating the boolean nature of the function's return value
from the resulting encoded output.

I'm not sure what you mean by "boolean nature". But a pointer value
(a value that, for example, refers to the location of some object) and
that pointer value's representation when stored in a pointer object (a
sequence of bits) are and should be separated.

 

[luserXtrog]

The word "number" can be applied to many different mathematical
concepts: integers, reals, rationals, complex numbers. quaternions,
et cetera literally ad infinitum.
Rad!

So if you want to think of pointers as a kind of "number" in some
abstract mathematical sense, one that covers signed and unsigned
integers, floating-point numbers, and (for languages that support such
things) rational numbers and so forth, go ahead.

The point is that pointers are not *integers*.

Yes. Apologies for any suggestion to the contrary.

I think [feel] that in this example the similarities are more
important than the differences; because it may lead to the notion
of separating the boolean nature of the function's return value
from the resulting encoded output.

I'm not sure what you mean by "boolean nature".

Simply that the function returns one of two things.
I meant that property of the purpose of the function
that makes the ternary conditional operator so appropriate.

 But a pointer value

(a value that, for example, refers to the location of some object) and
that pointer value's representation when stored in a pointer object (a
sequence of bits) are and should be separated.

Yes. But seeing-as-how expressions involving arrays are described
in terms of the equivalent pointer arithmetic, it seems pertinent
to discuss the motivations one might have to choose one method
over another.

 

[Richard Bos]

Understood. But as a neo-pythagorean, my hackles rise automatically
when anyone suggests X is not a number.

Of course X is a number! And its value is '88', isn't it?

My sense of holism attempts to retaliate by identifying a universe of
discourse in which the two dissolve into one.

That is a futile exercise, only useful on paper, for philosophical
reasons. It will give you a mapping from one to the other; but the
mapping will be meaningless. It won't make programming any more
possible, let alone practical.

Perhaps the true situation is more of a superposition of the dual
intepretation: pointers are numbers and pointers are not numbers.

Bah. For most programs, and even for most programmers, there is no
reason to assume that pointers are numbers. Wibbling on about quantum
meta-programming does not change that situation. Are you sure you don't
prefer to speak German?

Richard

 

[jameskuyper]

But there is also a basic similarity between addresses and integers,
particularly where the integer is employed to index an array.
A pointer is an index to any location in the process memory space.
Using an index to a smaller portion of that memory can improve
locality.

You can probably find a basic similarity between just about any two
concepts.

Your model of a pointer as "an index to any location in the process
memory space" assumes a monolithic linear addressing space, where all
of memory can be treated as a single array of bytes. C does not
require such a model, and there are machines that don't use it.

You can add or subtract an integer to a pointer and get another
pointer, you can subtract one pointer from another to get an integer,
and you can compare two pointers using <, <=, >, or >=. But all
these operations are defined only within a single object.

[...]

Understood. But as a neo-pythagorean, my hackles rise automatically
when anyone suggests X is not a number. My sense of holism attempts
to retaliate by identifying a universe of discourse in which the
two dissolve into one. Occasionally this corresponds to mathematical
abstraction; but often it is merely poetic.

Perhaps the true situation is more of a superposition of the dual
intepretation: pointers are numbers and pointers are not numbers.

I think [feel] that in this example the similarities are more
important than the differences; because it may lead to the notion
of separating the boolean nature of the function's return value
from the resulting encoded output.

I just don't see the value in thinking of pointers as numbers. The
main consequence I can see from thinking about them that way is that
it can lead to incorrect conclusions about which operations are legal,
and their meaning. For instance, given two char* pointers p and q, and
a unsigned integer n, thinking about pointers as numbers might lead
you to incorrectly conclude that:

~p, -p, p*n, p/n, p+q, n-p, p<<n, p>>n, p%n, p&n, p^n , and p|n
are permitted
p+n, p-q, and p > q are always well-defined

and that all of the following expressions are guaranteed to be true:

(p + n) - n == p
(uintptr_t)p + n == (uintptr_t)(p + n)
(p == q) == ((uintprt_t)p == (uintptr_t)q)

I don't see any benefit from making the analogy that is sufficient to
compensate for the risk of encouraging such misconceptions.

 

[luserXtrog]

Of course X is a number! And its value is '88', isn't it?

Hilarious. Truly.
But seriously: everything is number. No less so in programming
than in any other enterprise.

That is a futile exercise, only useful on paper, for philosophical
reasons. It will give you a mapping from one to the other; but the
mapping will be meaningless. It won't make programming any more
possible, let alone practical.

Perhaps. But as I say, it is an 'automatic' reaction.
Of course I have some conscious control of the direction
of the reactive energy. But I have yet to gain control
of the source.

Bah. For most programs, and even for most programmers, there is no
reason to assume that pointers are numbers. Wibbling on about quantum
meta-programming does not change that situation. Are you sure you don't
prefer to speak German?

Actually, I prefer Russian for the ultimate in precision.
In fact, when silent, you are all speaking Russian, saying
"is". Whatever that may mean?! [ ;{> ]

I'm not really sure what I'm defending anymore.
But I shall not yield to mere ribbing.

But just in case, I remind the world to take everything I or
anyone else may say with appropriate quantities of salt.
Especially if you're out in the hot sun.

 

[luserXtrog]

[...]

Understood. But as a neo-pythagorean, my hackles rise automatically
when anyone suggests X is not a number. My sense of holism attempts
to retaliate by identifying a universe of discourse in which the
two dissolve into one. Occasionally this corresponds to mathematical
abstraction; but often it is merely poetic.

Perhaps the true situation is more of a superposition of the dual
intepretation: pointers are numbers and pointers are not numbers.

I think [feel] that in this example the similarities are more
important than the differences; because it may lead to the notion
of separating the boolean nature of the function's return value
from the resulting encoded output.

I just don't see the value in thinking of pointers as numbers. The
main consequence I can see from thinking about them that way is that
it can lead to incorrect conclusions about which operations are legal,
and their meaning. For instance, given two char* pointers p and q, and
a unsigned integer n, thinking about pointers as numbers might lead
you to incorrectly conclude that:

    ~p, -p, p*n, p/n, p+q, n-p, p<<n, p>>n, p%n, p&n, p^n , and p|n
are permitted
    p+n, p-q, and p > q are always well-defined

and that all of the following expressions are guaranteed to be true:

    (p + n) - n == p
    (uintptr_t)p + n == (uintptr_t)(p + n)
    (p == q) == ((uintprt_t)p == (uintptr_t)q)

I don't see any benefit from making the analogy that is sufficient to
compensate for the risk of encouraging such misconceptions.

I meant only: think about the overall task and choose the most
appropriate construct. I appreciate the dangers you describe
but I don't understand how my suggestions send one towards those
dangers.

 

[Keith Thompson]

Hilarious. Truly.
But seriously: everything is number. No less so in programming
than in any other enterprise.

Seriously, not everything is a number, unless you redefined "number"
as a synonym for "thing".

In the more abstract branches of mathematics, the word "number" can
cover a huge variety of things, but if you expand it too far it just
loses all meaning, or at least all usefulness.

Getting back to reality, thinking of C pointers as numbers just isn't
very useful. You might not be led astray by the assumption that
pointers are numbers, or more narrowly that they're N-bit integers,
but others can be and often are.

"Numbers", the way you seem to be using the word, are not a C concept.
C has what it calls "arithmetic types". The important and relevant
point is that pointer types are not arithmetic types.

 

[Nick Keighley]

cheese, torque

Hilarious. Truly.
But seriously: everything is number. No less so in programming
than in any other enterprise.

a NaN is number?
my tea mug is a number?

Perhaps. But as I say, it is an 'automatic' reaction.
Of course I have some conscious control of the direction
of the reactive energy. But I have yet to gain control
of the source.

are you drunk?

<snip>

 

[Nick Keighley]

[...]
Understood. But as a neo-pythagorean, my hackles rise automatically
when anyone suggests X is not a number. My sense of holism attempts
to retaliate by identifying a universe of discourse in which the
two dissolve into one. Occasionally this corresponds to mathematical
abstraction; but often it is merely poetic.
Perhaps the true situation is more of a superposition of the dual
intepretation: pointers are numbers and pointers are not numbers.
I think [feel] that in this example the similarities are more
important than the differences; because it may lead to the notion
of separating the boolean nature of the function's return value
from the resulting encoded output.

I just don't see the value in thinking of pointers as numbers. The
main consequence I can see from thinking about them that way is that
it can lead to incorrect conclusions about which operations are legal,
and their meaning. For instance, given two char* pointers p and q, and
a unsigned integer n, thinking about pointers as numbers might lead
you to incorrectly conclude that:

    ~p, -p, p*n, p/n, p+q, n-p, p<<n, p>>n, p%n, p&n, p^n , and p|n
are permitted
    p+n, p-q, and p > q are always well-defined

and that all of the following expressions are guaranteed to be true:

    (p + n) - n == p
    (uintptr_t)p + n == (uintptr_t)(p + n)
    (p == q) == ((uintprt_t)p == (uintptr_t)q)

I don't see any benefit from making the analogy that is sufficient to
compensate for the risk of encouraging such misconceptions.

I meant only: think about the overall task and choose the most
appropriate construct.

but James seems to have demonstrated that you have made an
inappropriate
choice.

Recently someone asked why the C standard didn't give a meaning to p +
q.
Its thinking like yours that led to the question. And thinking like
James's
that leads to the answer "because it makes no sense".

I appreciate the dangers you describe
but I don't understand how my suggestions send one towards those
dangers.

we'e rather the open sea than the lee shore. Why go there at all?

 

[James Kuyper]

[...]
Understood. But as a neo-pythagorean, my hackles rise automatically
when anyone suggests X is not a number. My sense of holism attempts
to retaliate by identifying a universe of discourse in which the
two dissolve into one. Occasionally this corresponds to mathematical
abstraction; but often it is merely poetic.
Perhaps the true situation is more of a superposition of the dual
intepretation: pointers are numbers and pointers are not numbers.
I think [feel] that in this example the similarities are more
important than the differences; because it may lead to the notion
of separating the boolean nature of the function's return value
from the resulting encoded output.

I just don't see the value in thinking of pointers as numbers. The ....
I don't see any benefit from making the analogy that is sufficient to
compensate for the risk of encouraging such misconceptions.

I meant only: think about the overall task and choose the most
appropriate construct.

That I can agree with. But I don't see what it has to do with thinking
about the (limited) similarities between pointers and numbers. In fact,
for that purpose, I think it's far more important to think about their
(numerous) differences. As far as their similarities go, they are
equally appropriate; it is their differences that make one more
appropriate than the other.

 

[luserXtrog]

luserXtrog wrote:
... [[...]]
[...]
Understood. But as a neo-pythagorean, my hackles rise automatically
when anyone suggests X is not a number. My sense of holism attempts
to retaliate by identifying a universe of discourse in which the
two dissolve into one. Occasionally this corresponds to mathematical
abstraction; but often it is merely poetic.
Perhaps the true situation is more of a superposition of the dual
intepretation: pointers are numbers and pointers are not numbers.
I think [feel] that in this example the similarities are more
important than the differences; because it may lead to the notion
of separating the boolean nature of the function's return value
from the resulting encoded output.
I just don't see the value in thinking of pointers as numbers. The ...
I don't see any benefit from making the analogy that is sufficient to
compensate for the risk of encouraging such misconceptions.

I meant only: think about the overall task and choose the most
appropriate construct.

That I can agree with. But I don't see what it has to do with thinking
about the (limited) similarities between pointers and numbers. In fact,
for that purpose, I think it's far more important to think about their
(numerous) differences. As far as their similarities go, they are
equally appropriate; it is their differences that make one more
appropriate than the other.

But it is their similarities that allow both options in the same
field. It is only because they are similar in many ways that
the differences have any significance.

A recognition of similarity opens the question of which option
would serve better. Analyzing the differences closes the question.

One significant (to me) difference is that splint will complain
about returning a pointer to a string literal.

 

[luserXtrog]

luserXtrog wrote:
... [[...]]
[...]
Understood. But as a neo-pythagorean, my hackles rise automatically
when anyone suggests X is not a number. My sense of holism attempts
to retaliate by identifying a universe of discourse in which the
two dissolve into one. Occasionally this corresponds to mathematical
abstraction; but often it is merely poetic.
Perhaps the true situation is more of a superposition of the dual
intepretation: pointers are numbers and pointers are not numbers.
I think [feel] that in this example the similarities are more
important than the differences; because it may lead to the notion
of separating the boolean nature of the function's return value
from the resulting encoded output.
I just don't see the value in thinking of pointers as numbers. The
main consequence I can see from thinking about them that way is that
it can lead to incorrect conclusions about which operations are legal,
and their meaning. For instance, given two char* pointers p and q, and
a unsigned integer n, thinking about pointers as numbers might lead
you to incorrectly conclude that:
    ~p, -p, p*n, p/n, p+q, n-p, p<<n, p>>n, p%n, p&n, p^n , and p|n
are permitted
    p+n, p-q, and p > q are always well-defined
and that all of the following expressions are guaranteed to be true:
    (p + n) - n == p
    (uintptr_t)p + n == (uintptr_t)(p + n)
    (p == q) == ((uintprt_t)p == (uintptr_t)q)
I don't see any benefit from making the analogy that is sufficient to
compensate for the risk of encouraging such misconceptions.

I meant only: think about the overall task and choose the most
appropriate construct.

but James seems to have demonstrated that you have made an
inappropriate
choice.

Recently someone asked why the C standard didn't give a meaning to p +
q.
Its thinking like yours that led to the question.

I don't recall ever proposing to do arithmetic on pointers.
I'm not sure how to understand "thinking like yours".
Perhaps I should add "except when it isn't" to the ends of
my sentences.

We all seem to be dancing on a slippery hillside.
I at least have good shoes.

And thinking like
James's
that leads to the answer "because it makes no sense".


we'e rather the open sea than the lee shore. Why go there at all?

Because you can angle against the rocks and use their mass
for a gravitational accelleration effect opening a wormhole
to the other side of the universe. No mass no gravity.

 

[luserXtrog]

cheese, torque



a NaN is number?

It is enumerable, isn't it? Can you access its representation
with unsigned char *s?

my tea mug is a number?

OTOH, it is the first one I've seen you mention.
It probably has dimensions in terms of some unit of measurement.
It presumably is composed of a material substance with known
properties expressed quantitatively. It would likely contain
a volume. It may even have a natural resonance frequency.
The damned thing's chock full of numbers!

are you drunk?

Sometimes.

 

[Ben Pfaff]

OTOH, it is the first one I've seen you mention.
It probably has dimensions in terms of some unit of measurement.
It presumably is composed of a material substance with known
properties expressed quantitatively. It would likely contain
a volume. It may even have a natural resonance frequency.
The damned thing's chock full of numbers!

I think that there is a very important distinction to be made
here. It may be the case that every thing can be described using
one or more numbers, but that doesn't mean that every thing is a
number.

 

[Keith Thompson]

On Jul 15, 5:07 am, Nick Keighley <[email protected]>
wrote: [...]

a NaN is number?

It is enumerable, isn't it? Can you access its representation
with unsigned char *s?

Were you aware that NaN stands for "Not a Number"?

OTOH, it is the first one I've seen you mention.
It probably has dimensions in terms of some unit of measurement.
It presumably is composed of a material substance with known
properties expressed quantitatively. It would likely contain
a volume. It may even have a natural resonance frequency.
The damned thing's chock full of numbers!

[...]

No, there are many numbers that can be used to describe it, but
it contains no numbers, and the tea mug itself is a tea mug, not
a number.

Sure, you can stretch the meaning of "number" to cover anything
you like, especially if you're being deliberately obfuscatory.

A pointer is a number in the same sense that a struct is a number.
I say that neither of them is a number. There's a case to be made
that both of them are numbers, but only in the context of abstruse
mathematics (which has very little to do with C) or deliberate
confusion.

 

[Beej Jorgensen]

A word lacking descriptive power is nothing more than a meaningless
grunt -- a "number," if you will.

322918140285959040100468!

-Beej

 

[jameskuyper]

On Jul 15, 5:07 am, Nick Keighley <[email protected]> ....

OTOH, it is the first one I've seen you mention.
It probably has dimensions in terms of some unit of measurement.
It presumably is composed of a material substance with known
properties expressed quantitatively. It would likely contain
a volume. It may even have a natural resonance frequency.
The damned thing's chock full of numbers!

It can be described with numbers; that's very different from saying
that it is a number.

 

[Nobody]

You can do some arithmetic operations on some pointers.

If p and q point to parts of the same object,
then (p - q) and (q - p) are defined.

For the difference to be defined, p and q must point to elements of the
same array.

 

[luserXtrog]

On Jul 15, 5:07 am, Nick Keighley <[email protected]>
wrote: [...]

a NaN is number?

It is enumerable, isn't it? Can you access its representation
with unsigned char *s?

Were you aware that NaN stands for "Not a Number"?

Yes. That should've been followed by several smileys.

OTOH, it is the first one I've seen you mention.
It probably has dimensions in terms of some unit of measurement.
It presumably is composed of a material substance with known
properties expressed quantitatively. It would likely contain
a volume. It may even have a natural resonance frequency.
The damned thing's chock full of numbers!

[...]

No, there are many numbers that can be used to describe it, but
it contains no numbers, and the tea mug itself is a tea mug, not
a number.

*must* *resist* *'t''e''a'' ''m''u''g'*

Sure, you can stretch the meaning of "number" to cover anything
you like, especially if you're being deliberately obfuscatory.

A pointer is a number in the same sense that a struct is a number.
I say that neither of them is a number.  There's a case to be made
that both of them are numbers, but only in the context of abstruse
mathematics (which has very little to do with C) or deliberate
confusion.

The abstruse can be intrusive at times.
Not to get too Zen, but sometimes one can only see clearly after
having become thoroughly confused.