operators similar to functions?

[Richard Harter]

... here is what Harbison (C - A reference Manual) has to say
(7.12 Order of Evaluation).

[snip quote]

H&S is simply wrong here (or, more charitably, they are referring
to "K&R C", before the original ANSI C Standard, when the
specification for C was quite loose).

[snip interesting discussion]

Many thanks for the clarification.



Richard Harter, (e-mail address removed)
http://home.tiac.net/~cri, http://www.varinoma.com
The good news is that things could be worse; the bad
news is that things aren't as good as they should be.

 

[Richard Harter]

[snip]

This is quite true. To quote myself, the responsibility for
avoiding overflow rests with the programmer and not with the
compiler.

When you cannot even add two integers together without avoiding all
possibility of overflow, how do you propose the programmer achieves this?

The programmer does it by not adding two integers together if
their sum would overflow.

You give all of the responsibility to the programmer but you do not give
him the tools to fulfill that responsibility.

He has a brain, doesn't he? That's the relevant tool to use.



Richard Harter, (e-mail address removed)
http://home.tiac.net/~cri, http://www.varinoma.com
The good news is that things could be worse; the bad
news is that things aren't as good as they should be.

 

[RoS]

In data Tue, 04 Dec 2007 17:02:37 GMT, Richard Harter scrisse:

This is quite true. To quote myself, the responsibility for
avoiding overflow rests with the programmer and not with the
compiler.

.... and the language data structure

 

[Flash Gordon]

Richard Heathfield wrote, On 05/12/07 06:11:

CJ said:

That isn't really a problem, since the behaviour is controlled by a switch
which, presumably, the programmer can choose not to throw. The problem is
not "this switch is bad" so much as "this switch has nothing whatsoever to
do with the topic of this newsgroup". The switch *is*, however, topical in
comp.compilers.lcc, and it would be good for those who wish to discuss it
to do so there, rather than here.

In my opinion Richard's comment about topicality is true for CJ's post,
but *not* for Jacob's post. Jacob mentioned the switch to provide an
example of an implementation which does overflow checking in a
sub-thread about the impacts of overflow checking on what is "valid" C,
and as such Jacob's post was perfectly reasonable.

 

[jacob navia]

In my opinion Richard's comment about topicality is true for CJ's post,
but *not* for Jacob's post. Jacob mentioned the switch to provide an
example of an implementation which does overflow checking in a
sub-thread about the impacts of overflow checking on what is "valid" C,
and as such Jacob's post was perfectly reasonable.

Yes, that was what prompted me to answer that.

 

[Philip Potter]

[snip]

This is quite true. To quote myself, the responsibility for
avoiding overflow rests with the programmer and not with the
compiler.

When you cannot even add two integers together without avoiding all
possibility of overflow, how do you propose the programmer achieves this?

The programmer does it by not adding two integers together if
their sum would overflow.

Where did that proviso come from? In the text you snipped:

>This is quite true. To quote myself, the responsibility for
>avoiding overflow rests with the programmer and not with the
>compiler.

There is no "if their sum would overflow" proviso. Once a proviso
becomes "if their sum or any partial sum in any possible reordering
would overflow"

The point I am making is that your application of the as-if rule, taken
to its logical conclusion, results in /no/ summation at all having
defined behaviour, because

a+b

can be evaluated as

a+INT_MAX+b-INT_MAX

I was saying this to get an idea from you of where the line was drawn.
(To be honest, looking back on it it's not that relevant to what you
were saying. What was I thinking when I wrote it?)

He has a brain, doesn't he? That's the relevant tool to use.

In order to speak Polish, it's not enough to simply be clever. One must
also know Polish.

In order to use C, it's not enough to simply be clever. One must also
know C. The C standard states that if an expression has defined
behaviour, the compiler must implement that defined behaviour, even if a
similar-looking expression which a compiler may be tempted to transform
it to does not have defined behaviour.

 

[Keith Thompson]

Let me grumble a bit. Just because one is a programmer doesn't
mean that one is exempt from the ordinary standards of
scholarship. Part of the drill is to include the identification
of references.

[...]

Not to beat a dead horse, but the reference was already identified.
Let's look at the context:

Richard Harter wrote:
[...]
| Of course Harbison & Steele could be wrong, or the standard may
| have been amended since then, but the text is quite clear. If
| you disagree with the text feel free to point out where it is
| wrong by citing the appropriate section of the standard.

Eric Sosman replied:
| 5.1.2.3, with special attention to paragraph 5.

You specifically asked for a citation *of the standard*, and that
context was visible in Eric's followup. It might have been nice if
Eric had written "C99 5.1.2.3", but it was perfectly clear to me what
he was citing. (As for C90 vs. C99, the section number happens to be
the same in both, and I don't think there were any relevant changes.)

 

[Richard Harter]

Richard Harter wrote:
On Tue, 04 Dec 2007 10:40:18 +0000, Philip Potter
[snip]

This is quite true. To quote myself, the responsibility for
avoiding overflow rests with the programmer and not with the
compiler.
When you cannot even add two integers together without avoiding all
possibility of overflow, how do you propose the programmer achieves this?

The programmer does it by not adding two integers together if
their sum would overflow.

Where did that proviso come from? In the text you snipped:

This is quite true. To quote myself, the responsibility for
avoiding overflow rests with the programmer and not with the
compiler.

There is no "if their sum would overflow" proviso. Once a proviso
becomes "if their sum or any partial sum in any possible reordering
would overflow"

The point I am making is that your application of the as-if rule, taken
to its logical conclusion, results in /no/ summation at all having
defined behaviour, because

a+b

can be evaluated as

a+INT_MAX+b-INT_MAX

I was saying this to get an idea from you of where the line was drawn.
(To be honest, looking back on it it's not that relevant to what you
were saying. What was I thinking when I wrote it?)

I dunno. My mind reader is on the blink

In order to speak Polish, it's not enough to simply be clever. One must
also know Polish.

In order to use C, it's not enough to simply be clever. One must also
know C. The C standard states that if an expression has defined
behaviour, the compiler must implement that defined behaviour, even if a
similar-looking expression which a compiler may be tempted to transform
it to does not have defined behaviour.

While I was wrong about what the rules were. However things are
not quite as you think. Harbison (op. cit.) said that the
compiler was free to reorder arithmetic expressions as though
they had the relevant mathematical properties. That would be
consistent with the as-if rule provided the semantics were
changed accordingly; the rule would be that the behaviour would
be undefined if the behaviour of any consistent reordering had
undefined behaviour.

Can one program with that rule? Of course one can; all that
would really mean is that in certain situations one should do
some defensive programming. In K&R C days it was something you
had better do; compilers really were free to reorder.

Having "things are executed left to right as they are written"
makes understanding what a program might or might not do easier.
Of course C is not terribly consistent about observing that
principle, but that is another matter, which doesn't matter
because C is what it is.




Richard Harter, (e-mail address removed)
http://home.tiac.net/~cri, http://www.varinoma.com
The good news is that things could be worse; the bad
news is that things aren't as good as they should be.

 

[David Thompson]

On Thu, 29 Nov 2007 08:45:06 -0500, Eric Sosman

There's a wide family of languages that imitate a formula
notation (C,FORTRAN, Algol, Pascal, ...), but examples of
"non-formulaic" languages are not hard to find. Lisp is one,
assemblers usually focus on the operations rather than on

Assemblers generally write separately each instruction making up the
program being, er, written, but at least since very early days most
allow within instruction operands expressions which are evaluable at
translation time, i.e. 'constant' expressions in C terminology. E.g.

LOAD R1, BUFBASE + 3*SIZE_OF_ELEMENT + LEN_PART1

formulas, what little I saw of COBOL looked like formulas
transliterated into pidgin English, and somewhere in the high

COBOL has both the formula way and the nearly-English way.
Some perhaps many of its users and supporters emphasise the latter as
a unique advantage; the 'unique' part is unarguable.

holy Himalayas of ratiocination you'll find the monasteries
wherein dwell the lamas who can actually read APL.

APL does use infix and prefix operator syntax but NOT precedence and
associativity rules like all other formula langauges I know; except
for parens it 'binds' strictly right to left.

Let's not poke too much fun at Lisp, by the way. It's
challenging to read (although one gets better with practice),
but there are *no* rules of precedence or associativity (or
their formal-grammar counterparts) to confuse newbies, the
"operator overloading" diatribes never erupt, and indeed it's
trivial to introduce brand-new "operators" at need. That's
a lot of power; the obfuscation may be a worthwhile price.

(Nearly-consistent) postfix like FORTH (already mentioned) and
PostScript is similarly simple at the syntax level. (Without thereby
limiting semantics, as already noted at least once.)

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[David Thompson]

Philip Potter wrote:

One thing which hasn't been mentioned so far is operators which change
the values of their operands. For example, it is impossible in C to
write a function:
int increment(int x);
which has the same effect as x++ (or ++x). [because pass by value]

and similarly = += etc.

But the C family is unusual in considering assignment and
implicit-assignment (like increment) as operators at all. Most(?)
other 3GLs make assignment(s) instead a statement form, so the
assignment can only occur at 'top level' not in a subexpression, and
doesn't yield a value (or in C++ often lvalue); Ada and now Fortran do
allow assignment to be overridden/customized for user-defined types,
but as a nonvalued procedure resp. subroutine, which both those
languages distinguish from a valued function.

[OT: In C++ this problem is solved by introducing reference types which
allow a pass-by-reference mechanism. Then 'int increment (int &x)

and in (most?) other 3GLs by having reference parameters, either
implicitly or as a modifier, without making them a quasitype
applicable to other things such as locals and classmembers as in C++.

C++'s reference types are merely syntactic sugar for something that can
be done in a slightly more cumbersome fashion in C:

int increment(int *px) { return (*px)++;}

In the context of replacing operators with functions, it's not the same
thing at all. Firstly, it requires you to replace x++ with increment(&x)
rather than increment(x) - so at best you can replace an operator with a
function call and another operator. Secondly, even increment(&x) doesn't
work everywhere x++ does: [snip: register storageclass is c.v.]
Having said that, I'm not sure if you can initialize a reference type
with a register lvalue in C++. <snip>

You can, but also &reg is fine in C++, not a c.v. as in C.

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[Ben Pfaff]

APL does use infix and prefix operator syntax but NOT precedence and
associativity rules like all other formula langauges I know; except
for parens it 'binds' strictly right to left.

Smalltalk is another language that lacks conventional precedence
and associativity rules for the standard arithmetic operators:
all binary operators are left associative and evaluated in
left-to-right order.

 

[Philip Potter]

In the context of replacing operators with functions, it's not the same
thing at all. Firstly, it requires you to replace x++ with increment(&x)
rather than increment(x) - so at best you can replace an operator with a
function call and another operator. Secondly, even increment(&x) doesn't
work everywhere x++ does: [snip: register storageclass is c.v.]
Having said that, I'm not sure if you can initialize a reference type
with a register lvalue in C++. <snip>

You can, but also &reg is fine in C++, not a c.v. as in C.

(I take it c.v. means "Constraint Violation?")

I did not know that. The mind boggles at the number of subtle
differences between C and C++.

 

[David Thompson]

In the context of replacing operators with functions, it's not the same
thing at all. Firstly, it requires you to replace x++ with increment(&x)
rather than increment(x) - so at best you can replace an operator with a
function call and another operator. Secondly, even increment(&x) doesn't
work everywhere x++ does: [snip: register storageclass is c.v.]
Having said that, I'm not sure if you can initialize a reference type
with a register lvalue in C++. <snip>

You can, but also &reg is fine in C++, not a c.v. as in C.

(I take it c.v. means "Constraint Violation?")

Yes. I probably should have capitalized it, as the usual practice here
is UB or occasionally U.B. for Undefined Behavior.

I did not know that. The mind boggles at the number of subtle
differences between C and C++.

Yep. See C++98 Annex C, and I'm not sure even that was entirely
complete -- and of course it doesn't consider the changes created by
C99 (though that did remove the differences for doubleslash comments,
and implicit int and implicit function declaration) and what appear to
me to be fairly significant changes made or proposed in C++ since '98.

- formerly david.thompson1 || achar(64) || worldnet.att.net