Where to find the exact requirement of the operand for C operators?

[linq936]

Hi,
I just did the following test:
1:void main(void){
2: int p = 1;
3: int* pp = &p;
4: int c = p * pp;
5: int d = p + pp;
6:}
I use GCC compiler and get the error and warning:

t2.c: In function `main':
t2.c:4: invalid operands to binary *
t2.c:5: warning: initialization makes integer from pointer without a
cast
t2.c:1: warning: return type of `main' is not `int'

You can see that operands in addition operation can be int* but not
in multiplication.

I checked my <<C programming language>>, it does not say anything on
operands. Is there any good web resource on such specification?

[Lew Pitcher]

On May 7, 2:18 pm, [e-mail] wrote:

Hi,
I just did the following test:

1:void main(void){
2: int p = 1;
3: int* pp = &p;
4: int c = p * pp;

[snip]

You can see that operands in addition operation can be int* but not
in multiplication.

What do you get when you multiply an address by an integer? Is the
result an address? An integer? Something else?
What does such a number represent?

Answer these questions, and you'll understand the meaning of the error
message and some of the limits of the operands of the binary
operations.

HTH
--
Lew

[Christopher Benson-Manica]

li*****@hotmail.com wrote:

1:void main(void){
2: int p = 1;
3: int* pp = &p;
4: int c = p * pp;
5: int d = p + pp;
6:}

t2.c: In function `main':
t2.c:4: invalid operands to binary *

n869, 6.5.5: "Each of the operands [to the multiplicative operators,
i.e. * and /] shall have arithmetic type." pp is a pointer and does
not have arithmetic type; your code exhibits a constraint violation.

t2.c:5: warning: initialization makes integer from pointer without a
cast

n869, 6.5.6: "For addition, either both operands shall have arithmetic
type, or one operand shall be a pointer to an object type and the
other shall have integer type." Your code meets this constraint, but
the result of p+pp is a pointer, not an integer; hence the warning.
Additionally, pp+1 does not point to an object, although fortunately
for you a pointer may point one past the end of an array object, so
you are ok.

t2.c:1: warning: return type of `main' is not `int'

Do not ignore this warning.

I checked my <<C programming language>>, it does not say anything on
operands. Is there any good web resource on such specification?

Google for a copy of n869, which is a freely available draft of the
standard.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Eric Sosman]

Lew Pitcher wrote On 05/07/07 14:35,:

On May 7, 2:18 pm, [e-mail] wrote:

>>Hi,
I just did the following test:

1:void main(void){
2: int p = 1;
3: int* pp = &p;
4: int c = p * pp;

[snip]

> You can see that operands in addition operation can be int* but not
in multiplication.

What do you get when you multiply an address by an integer? Is the
result an address? An integer? Something else?
What does such a number represent?

Answer these questions, and you'll understand the meaning of the error
message and some of the limits of the operands of the binary
operations.

For even more insight, frame your answers in terms of
a machine whose addresses look like "221B Baker Street,"
"1600 Pennsylvania Avenue," and "79 Wistful Vista."

--
Er*********@sun.com

[Martin Ambuhl]

li*****@hotmail.com wrote:

Hi,
I just did the following test:
1:void main(void){

^^^^
after this inanity, nothing else matters.

2: int p = 1;
3: int* pp = &p;
4: int c = p * pp;

What does it mean to multiply a pointer by an int? (hint: nothing
useful) Why would you store the result of pointer arithmetic in an int?
(hint: there is no reason)

5: int d = p + pp;

Why would you store the result of pointer arithmetic in an int? (hint:
there is no reason)

6:}
I use GCC compiler and get the error and warning:

t2.c: In function `main':
t2.c:4: invalid operands to binary *

Of course.

t2.c:5: warning: initialization makes integer from pointer without a
cast

Of course.

t2.c:1: warning: return type of `main' is not `int'

No kidding,

>
You can see that operands in addition operation can be int* but not
in multiplication.

I checked my <<C programming language>>, it does not say anything on
operands. Is there any good web resource on such specification?

Try turning your brain on.

[Richard Tobin]

In article <1178565636.596506@news1nwk>,
Eric Sosman <Er*********@Sun.COMwrote:

>What do you get when you multiply an address by an integer? Is the
result an address? An integer? Something else?

Something else.

>What does such a number represent?

It represents the product of an address and an integer.

For even more insight, frame your answers in terms of
a machine whose addresses look like "221B Baker Street,"
"1600 Pennsylvania Avenue," and "79 Wistful Vista."

x = $221B Baker Street$ * 2
printf("half x is %p\n", x/2);

--half x is $221B Baker Street$

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Keith Thompson]

li*****@hotmail.com writes:

Hi,
I just did the following test:
1:void main(void){
2: int p = 1;
3: int* pp = &p;
4: int c = p * pp;
5: int d = p + pp;
6:}

Please don't add line numbers to code that you post here. They make
it difficult for us to copy-and-paste the code and try it ourselves.
It's not a big deal in this case, but it can be for bigger code
samples. If you need to correlate line numbers in error messages to
your code, you can indicate line numbers as comments.

The declaration "void main(void)" is incorrect. The main function
returns an int. If your textbook tells you otherwise, get a better
one. Your compiler even warned you about this, but you ignored the
warning. And since main returns an int, you should return an int;

int main(void)
{
/* ... */
return 0;
}

[...]

>
You can see that operands in addition operation can be int* but not
in multiplication.

I checked my <<C programming language>>, it does not say anything on
operands. Is there any good web resource on such specification?

Do you mean _The C Programming Language_ by Kernighan and Ritchie? If
so (and make sure you have the 2nd edition), I'm sure it does discuss
this. Look up "pointer arithmetic" in the index, or take a look at
the Appendix A, particularly the section on expressions.

(Incidentally, this is an excellent book -- and it *doesn't* use
"void main(void)".)

You can't multiply two pointers, or add two pointers, because it
doesn't make any sense to do so; the result wouldn't mean anything.
You can add a pointer to and integer, or vice versa; the result is a
pointer, offset from the original pointer value. See K&R2 for
details.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Old Wolf]

On May 8, 6:51 am, Christopher Benson-Manica
<[e-mail]:

[e-mail] wrote:

I checked my <<C programming language>>, it does not say anything on
operands. Is there any good web resource on such specification?

Google for a copy of n869, which is a freely available draft of the
standard.

Also google for n1124, which is the actual standard text, with some
errata
combined in.

Interestingly, I looked at my copy of K&R, and the section 2.5 on
arithmetic operators does not say anything about operands, e.g.
it doesn't say that it is valid to add two integers. Nor does it say
that it is valid to multiply an integer and a pointer. the writers
seem to assume that the reader will know or glark the truth or
falsity of these things.

Operands are only mentioned in chapter 5 (Pointers) , where it
says that pointers and integers may be added.

[Eric Sosman]

Richard Tobin wrote On 05/07/07 16:54,:

In article <1178565636.596506@news1nwk>,
Eric Sosman <Er*********@Sun.COMwrote:

Actually, the >material is by Lew Pitcher.

>>>What do you get when you multiply an address by an integer? Is the
result an address? An integer? Something else?

Something else.

>>>What does such a number represent?

It represents the product of an address and an integer.

> For even more insight, frame your answers in terms of
a machine whose addresses look like "221B Baker Street,"
"1600 Pennsylvania Avenue," and "79 Wistful Vista."

x = $221B Baker Street$ * 2
printf("half x is %p\n", x/2);

--half x is $221B Baker Street$

Interesting. How was `x' declared? ;-)

--
Er*********@sun.com

[Keith Thompson]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <1178565636.596506@news1nwk>,
Eric Sosman <Er*********@Sun.COMwrote:

>>What do you get when you multiply an address by an integer? Is the
result an address? An integer? Something else?

Something else.

>>What does such a number represent?

It represents the product of an address and an integer.

> For even more insight, frame your answers in terms of
a machine whose addresses look like "221B Baker Street,"
"1600 Pennsylvania Avenue," and "79 Wistful Vista."

x = $221B Baker Street$ * 2
printf("half x is %p\n", x/2);

--half x is $221B Baker Street$

Um, what language is that?

I think your point is that a C-like language could conceivably allow
addresses to be multiplied and divided by integers. You could even
compute the sine of a pointer; taking the cosine of the result would
presumably give you the original pointer value again.

The argument that (pointer * integer) is invalid because it can't
possibly make any sense is ironclad, because the language *could* have
defined such constructs.

The real answer to the OP's question is in (at least) two parts.

Q: Why is (pointer * integer) illegal?

A: Because the language standard says so (see section whatever, or any
decent textbook).

It's permissible just to stop here, but ...

Q: Why does the standard say so?

A: Because the authors of the standard decided, correctly IMHO, that
making it legal and defining its semantics would have been more
trouble than it's worth.

And for the truly stubborn (not necessarily referring to the OP) ...

Q: But I *want* to multiply a pointer by an integer; it makes sense to
me!

A: Why? Show us an example where such an operation actualy makes
sense, that can't be done more cleanly using C's existing
facilities. If you can present such an example (unlikely) and
convince the committee that supporting it is worth the burden on
all possible platforms (vanishingly unlikely), then such a feature
might be added to a future version of the standard, and you might
be able to rely on it being implemented in 10 or 20 years. Sorry,
that's just the way it is.

There's no real virtue in defining all possible operations for all
possible types. For each such operation, you have to define its
semantics in a way that can be implemented on any realistic
architecture. The C standard is deliberately designed so it's not
restricted to architectures where pointers happen to look and act
like integers; this makes things like (pointer * integer) difficult
to define in such a way that the result makes sense other than as
an operand to a later operation that reverses its effect.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Tobin]

In article <1178574589.850910@news1nwk>,
Eric Sosman <Er*********@Sun.COMwrote:

> x = $221B Baker Street$ * 2
printf("half x is %p\n", x/2);

--half x is $221B Baker Street$

Interesting. How was `x' declared? ;-)

That part of the design has not been completed yet. In keeping with
C's inside-out declarations, we might have for example:

char *x/2;

indicating that x/2 is a char *.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Richard Heathfield]

Keith Thompson said:

<snip>

I think your point is that a C-like language could conceivably allow
addresses to be multiplied and divided by integers. You could even
compute the sine of a pointer; taking the cosine of the result would
presumably give you the original pointer value again.

They must do trig very differently in the USA...

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Tobin]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>The argument that (pointer * integer) is invalid because it can't
possibly make any sense is ironclad, because the language *could* have
defined such constructs.

Did you mean the opposite of that?

>Q: But I *want* to multiply a pointer by an integer; it makes sense to
me!

[...]

There's no real virtue in defining all possible operations for all
possible types. For each such operation, you have to define its
semantics in a way that can be implemented on any realistic
architecture. The C standard is deliberately designed so it's not
restricted to architectures where pointers happen to look and act
like integers; this makes things like (pointer * integer) difficult
to define in such a way that the result makes sense other than as
an operand to a later operation that reverses its effect.

Of course I'm not seriously suggesting this, but... I don't think it
would be difficult in cases where it makes sense. Sure, adding two
pointers to different objects then dividing by two to get the average
would not work on machines where each object has an address with a
different segment part, but then that operation doesn't make sense
anyway. But doing it with two pointers into the same array *does*
make sense - it's the sort of operation used in a binary search - and
would be no harder to implement than the things that already have to
work, such as array indexing. Combining pointers to different objects
(e.g adding them then subtracting one of them off again. as a rather
poor way to switch between objects) would require the "sum of two
pointers" type to be some kind of compound object internally, but
that's what you get for using a segmented architecture.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Keith Thompson]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>>The argument that (pointer * integer) is invalid because it can't
possibly make any sense is ironclad, because the language *could* have
defined such constructs.

Did you mean the opposite of that?

Yes, I did; I meant to write that the argument is *not* ironclad. (I
re-worded that sentence several times; I should have checked it more
carefully.)

[snip]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

Keith Thompson said:

<snip>

>I think your point is that a C-like language could conceivably allow
addresses to be multiplied and divided by integers. You could even
compute the sine of a pointer; taking the cosine of the result would
presumably give you the original pointer value again.

They must do trig very differently in the USA...

<snip>

D'oh! I meant arcsine, of course.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Richard Tobin wrote:

>

.... snip ...

>
Of course I'm not seriously suggesting this, but... I don't think
it would be difficult in cases where it makes sense. Sure, adding
two pointers to different objects then dividing by two to get the
average would not work on machines where each object has an
address with a different segment part, but then that operation
doesn't make sense anyway. But doing it with two pointers into
the same array *does* make sense - it's the sort of operation used
in a binary search - and would be no harder to implement than the
things that already have to work, such as array indexing.

And, if you bothered to read the standard, is specifically allowed.

Combining pointers to different objects (e.g adding them then
subtracting one of them off again. as a rather poor way to switch
between objects) would require the "sum of two pointers" type to
be some kind of compound object internally, but that's what you
get for using a segmented architecture.

And again, if you bothered to read the standard, is specifically
disallowed.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Lew Pitcher wrote:

On May 7, 2:18 pm, [e-mail] wrote:

> I just did the following test:

1:void main(void){
2: int p = 1;
3: int* pp = &p;
4: int c = p * pp;

[snip]

>You can see that operands in addition operation can be int* but
not in multiplication.

What do you get when you multiply an address by an integer? Is
the result an address? An integer? Something else?
What does such a number represent?

Answer these questions, and you'll understand the meaning of the
error message and some of the limits of the operands of the
binary operations.

In addition, main always returns an int. You don't know what makes
up a pointer, it may have many fields with various meanings. The
limitations are spelled out in the standard. You can find a copy
in the download section of my page (see organization header).

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Thad Smith]

Martin Ambuhl wrote:

li*****@hotmail.com wrote:

> I just did the following test:
1:void main(void){

^^^^
after this inanity, nothing else matters.

That is overstated. In a freestanding environment for a program that
never terminates that is an acceptable and common declaration for the
program entry point. In that case void is the return type that makes
the most sense. For hosted programs, main should either return an int
or conform to an implementation-defined type.

--
Thad

[Rudolf]

In article <46***********************@auth.newsreader.octanew s.com>,
Thad Smith <Th*******@acm.orgwrote:

Martin Ambuhl wrote:

1:void main(void){

^^^^
after this inanity, nothing else matters.

That is overstated. In a freestanding environment for a program that
never terminates that is an acceptable and common declaration for the
program entry point. In that case void is the return type that makes
the most sense. For hosted programs, main should either return an int
or conform to an implementation-defined type.

I'm curious: what about for a hosted program that never terminates?

--
Posted via a free Usenet account from http://www.teranews.com

[Jack Klein]

On Mon, 07 May 2007 15:20:35 -0400, Eric Sosman <Er*********@sun.com>
wrote in comp.lang.c:

Lew Pitcher wrote On 05/07/07 14:35,:

On May 7, 2:18 pm, [e-mail] wrote:

>Hi,
I just did the following test:

1:void main(void){
2: int p = 1;
3: int* pp = &p;
4: int c = p * pp;

[snip]

You can see that operands in addition operation can be int* but not
in multiplication.

What do you get when you multiply an address by an integer? Is the
result an address? An integer? Something else?
What does such a number represent?

Answer these questions, and you'll understand the meaning of the error
message and some of the limits of the operands of the binary
operations.

For even more insight, frame your answers in terms of
a machine whose addresses look like "221B Baker Street,"
"1600 Pennsylvania Avenue," and "79 Wistful Vista."

You misspelled "Wasteful" in the last address...

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Richard Heathfield]

Rudolf said:

In article <46***********************@auth.newsreader.octanew s.com>,
Thad Smith <Th*******@acm.orgwrote:

>Martin Ambuhl wrote:

>1:void main(void){
^^^^
after this inanity, nothing else matters.

That is overstated. In a freestanding environment for a program that
never terminates that is an acceptable and common declaration for the
program entry point. In that case void is the return type that makes
the most sense. For hosted programs, main should either return an
int or conform to an implementation-defined type.

I'm curious: what about for a hosted program that never terminates?

No such program has ever run to completion, so the point is moot. But in
any case, the behaviour of such a program would be undefined, whether
or not it terminates.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Eric Sosman]

Keith Thompson wrote:

>
The argument that (pointer * integer) is invalid because it can't
possibly make any sense is ironclad, because the language *could* have
defined such constructs. [...]

("Is ironclad" corrected to "is not ironclad" elsethread.)

It's not hard to imagine a formal underpinning for pointers
that would allow multiplication by an integer, or even by a
floating-point number. By thinking of a pointer as a vector --
and really now, what could be more natural? -- we can even get
multiplication of two pointer operands in at least two different
ways, corresponding to dot-product and cross-product.

But C's pointers aren't vectors: they are more abstract.
There are a few hints that pointers might be "addresses" (the
unary `&' operator is referred to as "address-of") and that
addresses might have some properties of numbers (alignment is
defined in terms of "multiples" of an address), but by and large
the C language avoids nailing down the nature of a pointer any
more than it must. A wise choice, because (1) there is little
use for the inverse or for the square root of a pointer, and
(2) being unnecessarily specific risks becoming obsolete.

By declining to define "unnecessary" operations on pointers
today, C leaves open the possibility of providing definitions
for them tomorrow when more is known about what might be useful.
Someday (mark my words!) we will discover that it is handy to
think of pointers as complex numbers, or as matrices, or as
quaternions -- and when that day comes, C will be free to add
new properties to pointer arithmetic without worrying about
changing old properties and breaking old code.

Prediction: When pointers are understood as indefinite
integrals, someone will try to read them with gets().

--
Eric Sosman
es*****@acm-dot-org.invalid

[Eric Sosman]

Jack Klein wrote:

On Mon, 07 May 2007 15:20:35 -0400, Eric Sosman <Er*********@sun.com>
wrote in comp.lang.c:

>Lew Pitcher wrote On 05/07/07 14:35,:

>>[... concerning arbitrary arithmetic on pointers ...]
Answer these questions, and you'll understand the meaning of the error
message and some of the limits of the operands of the binary
operations.

For even more insight, frame your answers in terms of
a machine whose addresses look like "221B Baker Street,"
"1600 Pennsylvania Avenue," and "79 Wistful Vista."

You misspelled "Wasteful" in the last address...

"Don't open that door!"

http://www.geocities.com/Hollywood/Hills/5284/

--
Eric Sosman
es*****@acm-dot-org.invalid

[Peter Nilsson]

Eric Sosman <[e-mail]:

...
By declining to define "unnecessary" operations on
pointers today, C leaves open the possibility of providing
definitions for them tomorrow when more is known about what
might be useful.

"No, they just didn't like it very much."
-- Zaphod Beeblebrox

--
Peter

[Richard Tobin]

In article <46**************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:

>Of course I'm not seriously suggesting this, but... I don't think
it would be difficult in cases where it makes sense. Sure, adding
two pointers to different objects then dividing by two to get the
average would not work on machines where each object has an
address with a different segment part, but then that operation
doesn't make sense anyway. But doing it with two pointers into
the same array *does* make sense - it's the sort of operation used
in a binary search - and would be no harder to implement than the
things that already have to work, such as array indexing.

And, if you bothered to read the standard, is specifically allowed.

What is, adding pointers and then dividing by two?

>Combining pointers to different objects (e.g adding them then
subtracting one of them off again. as a rather poor way to switch
between objects) would require the "sum of two pointers" type to
be some kind of compound object internally, but that's what you
get for using a segmented architecture.

And again, if you bothered to read the standard, is specifically
disallowed.

I think you have completely misunderstood this conversation.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Thad Smith]

Richard Heathfield wrote:

Rudolf said:

>>In article <46***********************@auth.newsreader.octanew s.com>,
Thad Smith <Th*******@acm.orgwrote:

>>>Martin Ambuhl wrote:

>1:void main(void){
^^^^
after this inanity, nothing else matters.

That is overstated. In a freestanding environment for a program that
never terminates that is an acceptable and common declaration for the
program entry point. In that case void is the return type that makes
the most sense. For hosted programs, main should either return an
int or conform to an implementation-defined type.

I'm curious: what about for a hosted program that never terminates?

No such program has ever run to completion, so the point is moot. But in
any case, the behaviour of such a program would be undefined, whether
or not it terminates.

The previous poster seems to be pulling our leg(s). Using interactive
I/O, one can indeed write a program that has behavior defined by the
standard. The standard says nothing of the timing, of course. A
suitable implementation must be chosen for that aspect.

--
Thad

[Kenneth Brody]

Richard Tobin wrote:

>
In article <1178574589.850910@news1nwk>,
Eric Sosman <Er*********@Sun.COMwrote:

x = $221B Baker Street$ * 2
printf("half x is %p\n", x/2);

--half x is $221B Baker Street$

Interesting. How was `x' declared? ;-)

That part of the design has not been completed yet. In keeping with
C's inside-out declarations, we might have for example:

char *x/2;

indicating that x/2 is a char *.

So, what is the result of:

x = $221B Baker Street$ + $1600 Washington Street$;
printf("half of x is %p\n", x/2);

:-)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Kenneth Brody]

Richard Tobin wrote:
[...]

Of course I'm not seriously suggesting this, but... I don't think it
would be difficult in cases where it makes sense. Sure, adding two
pointers to different objects then dividing by two to get the average
would not work on machines where each object has an address with a
different segment part, but then that operation doesn't make sense
anyway. But doing it with two pointers into the same array *does*
make sense

You can already do this, by adding half the difference, which makes
more sense than adding two addresses. Sure, adding two addresses
and dividing by two to get the "average" address may make sense as
a complete operation, but what is the intermediate result of the
addition of two addresses?

And, while we're at it, what about multiplying or dividing two
pointers? (Why limit it to addition?)

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[CBFalconer]

Richard Tobin wrote:

CBFalconer <cb********@maineline.netwrote:

>>Of course I'm not seriously suggesting this, but... I don't think
it would be difficult in cases where it makes sense. Sure, adding
two pointers to different objects then dividing by two to get the
average would not work on machines where each object has an
address with a different segment part, but then that operation
doesn't make sense anyway. But doing it with two pointers into
the same array *does* make sense - it's the sort of operation used
in a binary search - and would be no harder to implement than the
things that already have to work, such as array indexing.

And, if you bothered to read the standard, is specifically allowed.

What is, adding pointers and then dividing by two?

>>Combining pointers to different objects (e.g adding them then
subtracting one of them off again. as a rather poor way to switch
between objects) would require the "sum of two pointers" type to
be some kind of compound object internally, but that's what you
get for using a segmented architecture.

And again, if you bothered to read the standard, is specifically
disallowed.

I think you have completely misunderstood this conversation.

I think you are right :-)

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Dave Vandervies]

In article <46***************@spamcop.net>,
Kenneth Brody <ke******@spamcop.netwrote:

>Richard Tobin wrote:

>>
In article <1178574589.850910@news1nwk>,
Eric Sosman <Er*********@Sun.COMwrote:

> x = $221B Baker Street$ * 2
printf("half x is %p\n", x/2);

--half x is $221B Baker Street$

Interesting. How was `x' declared? ;-)

That part of the design has not been completed yet. In keeping with
C's inside-out declarations, we might have for example:

char *x/2;

indicating that x/2 is a char *.

So, what is the result of:

x = $221B Baker Street$ + $1600 Washington Street$;
printf("half of x is %p\n", x/2);

:-)

--------
half of x is $somewhere in the Atlantic Ocean$
--------
, obviously. What ELSE would you expect it to be?
dave
(maybe lat/long?)

--
Dave Vandervies dj******@csclub.uwaterloo.ca
I have apparently titled this subthread "Sillines".
Does anyone know what a silline is?
--Joona I Palaste in comp.lang.c

[Christopher Benson-Manica]

Kenneth Brody <ke******@spamcop.netwrote:

So, what is the result of:

x = $221B Baker Street$ + $1600 Washington Street$;
printf("half of x is %p\n", x/2);

$Gordon Brown$ ? :-)

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Richard Bos]

Christopher Benson-Manica <at***@ukato.freeshell.orgwrote:

Kenneth Brody <ke******@spamcop.netwrote:

So, what is the result of:

x = $221B Baker Street$ + $1600 Washington Street$;
printf("half of x is %p\n", x/2);

$Gordon Brown$ ? :-)

I support Gordon Brown for Prime Minister... for the new Free State of
Scotland, which will inevitably be brought up again after the latest
elections.

Richard

[Army1987]

"Richard Tobin" <ri*****@cogsci.ed.ac.ukha scritto nel messaggio
news:f1***********@pc-news.cogsci.ed.ac.uk...

In article <1178574589.850910@news1nwk>,
Eric Sosman <Er*********@Sun.COMwrote:

>> x = $221B Baker Street$ * 2
printf("half x is %p\n", x/2);

--half x is $221B Baker Street$

> Interesting. How was `x' declared? ;-)

That part of the design has not been completed yet. In keeping with
C's inside-out declarations, we might have for example:

char *x/2;

indicating that x/2 is a char *.

<visionary>
No. It indicates that (*x)/2 is a char. You meant char *(x/2).
Your declaration indicates that x points to a type able to contain
all even integers from 2*CHAR_MIN to 2*CHAR_MAX.
</visionary>
<uncyclopedia>
Adding two pointers is not legal, but adding a pointer and an
integer is. (The surprising thing is that it's commutative, as
expressions such as 9[array] show.) You can subtract an integer
from a pointer getting a pointer, and can subtract a pointer from
a pointer giving an integer (ptrdiff_t). In fancier language,
pointers form an affine space over integers. Therefore, any affine
combination of pointers (that is, a linear combination of pointers
which coefficients summing to exactly 1) makes sense. What doesn't
make sense is adding a pointer to an integer (rather than
viceversa), but this is allowed in C.
</uncyclopedia>

[Army1987]

"Eric Sosman" <es*****@acm-dot-org.invalidha scritto nel messaggio
news:ru******************************@comcast.com. ..

Keith Thompson wrote:

>>
The argument that (pointer * integer) is invalid because it can't
possibly make any sense is ironclad, because the language *could* have
defined such constructs. [...]

("Is ironclad" corrected to "is not ironclad" elsethread.)

It's not hard to imagine a formal underpinning for pointers
that would allow multiplication by an integer, or even by a
floating-point number. By thinking of a pointer as a vector --
and really now, what could be more natural? -- we can even get
multiplication of two pointer operands in at least two different
ways, corresponding to dot-product and cross-product.

But C's pointers aren't vectors: they are more abstract.

As I pointed out elsethread, they are elements of an affine space
over ptrdiff_t. :-)
http://en.wikipedia.org/wiki/Affine_space
(Actually, only pointers to elements of a same array or to one cell
past the end of an array are required to be in the same affine
space.)
<seriousness level="slightly more">
Suppose I have an array int a[MAX][MAX] and pointers int *p =
&a[0][0], *q = &a[1][0]. p + MAX is required by the standard to be
OK, and it equals q. Now q+1 equals &a[1][1] (or there would be no
way for multidimensional arrays to work).
Now I read in the FAQ 6.19 that p + (MAX + 1) is UB, and yet
I've just shown that (p + MAX) + 1 is OK.
Is there anything I am missing?
</seriousness>

[Eric Sosman]

Army1987 wrote:

<seriousness level="slightly more">
Suppose I have an array int a[MAX][MAX] and pointers int *p =
&a[0][0], *q = &a[1][0]. p + MAX is required by the standard to be
OK, and it equals q. Now q+1 equals &a[1][1] (or there would be no
way for multidimensional arrays to work).
Now I read in the FAQ 6.19 that p + (MAX + 1) is UB, and yet
I've just shown that (p + MAX) + 1 is OK.
Is there anything I am missing?
</seriousness>

A sense of proportion?

--
Eric Sosman
es*****@acm-dot-org.invalid