the 'standard' is so strange

[Pilcrow]

This behavior seems very strange to me, but I imagine that someone will
be able to 'explain' it in terms of the famous C standard.

-------------------- code -----------------------------------
#include <stdio.h>

int main (void)
{
char xx[]="abcd";
char * p1 = xx;
char * p2 = xx;
int i;
for(i = 0; i < 4; i++)
printf("%d %c %c\n", i, *p1++, *p1 );
putchar('\n');
for(i = 0; i < 4; i++)
printf("%d %c %c\n", i, *p2, *p2++);
}

-------------------- output -----------------------------------

0 a a
1 b b
2 c c
3 d d

0 b a
1 c b
2 d c
3 d

-------------------------------------------------------------

--
I understand you come from England,
but I promise not to hold it against
you.

[Pilcrow]

On Mon, 17 Nov 2008 13:38:40 -0800 (PST), jameskuyper
<ja*********@ve rizon.netwrote:

>Pilcrow wrote:
...

>Before posting my example I had already realised that I was not allowed
(at least in *this* case) to use a shortcut to modify an argument to a
function *within* the parens. I just assumed that the much-cited k&r
had fully defined the language. All these 'undefines' have me feeling
like I'm trying to herd cats. (snakes?)

K&R did not fully define the language. The C89 standard did define it,
but that definition included specifying, with considerable precision,
situations in which the standard does not specify the behavior.

>Now I realise that I will have to read the 'standard', which seems to
have been written by a team composed of Philidelphia lawyers and
abstract mathematicians, neither of whom heard of Henry W Fowler. Truly
gelatinous prose. Technical writing need not be so murky. Oh, well, we
live to learn.

A key thing that you need to understand is that the standard is,
conceptually , a contract between implementors of C and developers of C
programs. If a developer writes strictly conforming code, a conforming
implementati on has to produce exactly the behavior specified by the
standard. The "undefined behavior" that bothers you so much is simply
one of the several methods which the standard uses to identify code
which doesn't meet the contract requirements.

These ways are:
1. The standard requires that a conforming implementation must produce
at least one diagnostic message whenever given a program that contains
any syntax errors or constraint violations. An implementation is also
free to produce diagnostic messages for any other reason that it
wishes. Diagnostics are not required to provide you with any useful
information; they are not even required to be in any language that
anyone knows how to read. However, an implementation is required to
document how to identify diagnostic messages. If you don't find the
messages helpful, that's a legitimate issue to complain about to the
implementor - but it doesn't make the implementation non-conforming.

Having generated that diagnostic, an implementation is free to process
your code a produce a program that you might or might not be willing
to actually execute (I wouldn't).

2. Unspecified behavior: in some cases, the standard allows an
implementati on a range of choices. This is usually not done just for
the fun of it - it's done because existing implementations handle the
situation in different ways, often because the best way to handle the
situation is different on different machines. By making the behavior
unspecified, the standard makes it easier to implement C in an
efficient fashion on a much wider variety of platforms than just about
any other language. The price we pay for this is that we have to be
careful to avoid writing code that depends upon unspecified behavior,
unless we have a very good reason to tie a program to a particular
implementati on of C.

A program whose behavior is unspecified must still behave in one of
permitted ways, an implementation is not free to make it behave in a
completely arbitrary fashion. In many cases, unspecified behavior is
also implementation-defined behavior; in that case, the implementation
is required to document which choice it made. See Annex J.3 for
implementati on-defined behavior; see Annex J.1 for other unspecified
behavior.

3. Undefined behavior: the standard imposes no requirements, of any
kind, on the behavior. An implementation is free to provide it's own
definition of the behavior. If you're deliberately relying upon a
particular implementation' s definition of the behavior, that's fine.
However, if you intend your code to be portable, you must avoid
undefined behavior completely. See Annex J.2 for undefined behavior.

>Maybe I'll try to make a catalog of *all* the 'undefines' and similar
gotchas in C. Written in English.

Virtually every sentence of the standard contains a "gotcha", many of
them contain several "gotchas". To write them out in clear English,
avoiding the technical jargon that makes the standard so difficult to
read, a complete list of the "gotchas" will have to be several times
longer than the standard itself.

...

>BTW, what's a 'sequence point', and how could I recognize one in a dark
alley? Never mind, maybe the *standard* will tell me.

Here's the complete list of sequence points from Annex C:

>— The call to a function, after the arguments have been evaluated (6.5.2.2).
— The end of the first operand of the following operators: logical AND && (6.5.13);
logical OR || (6.5.14); conditional ? (6.5.15); comma , (6.5.17).
— The end of a full declarator: declarators (6.7.5);
— The end of a full expression: an initializer (6.7.8); the expression in an expression
statement (6.8.3); the controlling expression of a selection statement (if or switch)
(6.8.4); the controlling expression of a while or do statement (6.8.5); each of the
expressions of a for statement (6.8.5.3); the expression in a return statement
(6.8.6.4).
— Immediately before a library function returns (7.1.4).
— After the actions associated with each formatted input/output function conversion
specifier (7.19.6, 7.24.2).
— Immediately before and immediately after each call to a comparison function, and
also between any call to a comparison function and any movement of the objects
passed as arguments to that call (7.20.5).

Thank you, sir. That will help.

--
You are a gentleman and a scholar
and a judge of fine whiskey.

[Pilcrow]

On Mon, 17 Nov 2008 15:59:18 -0800, Pilcrow <Pi******@gmail .comwrote:

>On Mon, 17 Nov 2008 13:01:28 -0800, Keith Thompson <ks***@mib.or g>
wrote:

>>Again, why put the word "standard" in scare quotes? It really is the
standard.

because it scares me??

>>
The standard is a technical document. The authors valued precision
over pleasant prose. If you have specific cases where you think the

In my experience, precision *is* pleasant.

>>same ideas could be expressed more clearly, by all means bring them
up; comp.std.c is probably the best place to do so. If you have
specific suggestions for better wording, that's great.

>>Maybe I'll try to make a catalog of *all* the 'undefines' and similar
gotchas in C. Written in English.

Take a look at Annex J of the C99 standard (or n1256 if you don't have
the official standard).

Turns out I have n1256. I thought that was it. Where can I get the
C99, and the other, previous ones? URL, please?

nevermind... found it.

[Nick Keighley]

On 17 Nov, 20:26, Pilcrow <Pilcr...@gmail .comwrote:

On Mon, 17 Nov 2008 09:18:44 -0800, Keith Thompson <[e-mail] g>

Others have done a very good job of answering your question. But I'm
curious: why do you have such a dismissive attitude regarding the C
standard (putting the words "standard" and "explain" in quotation
marks and so forth)?

Before posting my example I had already realised that I was not allowed
(at least in *this* case) to use a shortcut to modify an argument to a
function *within* the parens. I just assumed that the much-cited k&r
had fully defined the language. All these 'undefines' have me feeling
like I'm trying to herd cats. (snakes?)

To mix metaphores: just when I think I'm beginning to get a grip on C,
it turns into sea, and runs through my fingers.

Now I realise that I will have to read the 'standard', which seems to
have been written by a team composed of Philidelphia lawyers and
abstract mathematicians, neither of whom heard of Henry W Fowler.

the C standard is a model of clarity. And Fowler is over rated.

Truly
gelatinous prose. Technical writing need not be so murky. Oh, well, we
live to learn.

if you're going to be precise in english then a certain murkiness
is inevitable. As Churchill almost said:

"writing a technical standard in english is the worst possible
solution, apart from all the other solutions that have been tried"

Maybe I'll try to make a catalog of *all* the 'undefines' and similar
gotchas in C. Written in English.

Thanks to all for a most illuminating experience.

BTW, what's a 'sequence point', and how could I recognize one in a dark
alley? Never mind, maybe the *standard* will tell me.

It's been real

It's been complex
--
Nick Keighley

[begin quote]
5.4.4.2. Semantics
A MOID-NEST-jump J, in an environ E, is elaborated as follows:
- let the scene yielded in E by the label-identfier of J be composed
of a series
S2 and an environ E1;
Case A:
MOID is not any procedure yielding MOID1:
- let S1 be the series of the smallest {1.1.3.2.g} serial-clause
containing
S2;
- the elaboration of S1 in E1, or of any series in E1 elaborated
in its
place, is terminated {2.1.4.3.e};
- S2 in E1 is elaborated \in place of" S1 in E1;
Case B:
MOID is some procedure yielding MOID1:
- J in E {is completed and} yields the routine composed of
(i) a new MOID-NEST-routine-text whose unit is akin {1.1.3.2.k} to
J,
(ii) E1.

[...]

10.3. Transput declarations
{ "So it does!" said Pooh, "It goes in!"
"So it does!" said Piglet, "And it comes out!"
"Doesn't it?" said Eeyore, "It goes in and out like
anything,"
Winnie-the-Pooh, A.A. Milne.}

[end quote]

Both from "Revised Report on the Algorithmic Language ALGOL 68"

[Kenny McCormack]

In article <7a************ *************** *******@r36g200 0prf.googlegrou ps.com>,
Nick Keighley <ni************ ******@hotmail. comscrewed up again
thusly:
....

>the C standard is a model of clarity. And Fowler is over rated.

In much the same way that Bridgit Bardot (in her prime) was a model of
ugliness. I.e., to get the concept, you conceive of the exact opposite
of the "model".

[Dik T. Winter]

In article <gf**********@n ews.xmission.co mga*****@shell.x mission.com (Kenny McCormack) writes:
....

Bridgit Bardot (in her prime)

Who is that?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Joachim Schmitz]

Dik T. Winter wrote:

In article <gf**********@n ews.xmission.co m>
ga*****@shell.x mission.com (Kenny McCormack) writes: ...

> Bridgit Bardot (in her prime)

Who is that?

A typo. Actually three, her firstname is Brigitte

[CBFalconer]

Joachim Schmitz wrote:

Dik T. Winter wrote:

>ga*****@shell.x mission.com (Kenny McCormack) writes:

>>Bridgit Bardot (in her prime)

Who is that?

A typo. Actually three, her firstname is Brigitte

I think we should offer sympathy to Mr Winter.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Joachim Schmitz]

CBFalconer wrote:

Joachim Schmitz wrote:

>Dik T. Winter wrote:

>>ga*****@shell.x mission.com (Kenny McCormack) writes:

Bridgit Bardot (in her prime)

Who is that?

A typo. Actually three, her firstname is Brigitte

I think we should offer sympathy to Mr Winter.

For being to young to have seen BB in her prime? Nah...

Bye, Jojo

[Nick Keighley]

On 17 Nov, 22:55, Stephen Sprunk <step...@sprunk .orgwrote:

Pilcrow wrote:

On Mon, 17 Nov 2008 09:18:44 -0800, Keith Thompson <[e-mail] g>
wrote:

C is indeed less well-defined than most other languages.

are you sure about this? Might it be that C is better at
documenting its dark corners?

I've seen it argued[1] that the Ada standard has more open issues than
the C standard (this was some time ago so the holes may have been
plugged now).

[1] I can't remember exactly where something like "secure C"
by Hatton (I couldn't find it by google). Ah! Wikipedia for "Hatton".
"Safer C" by Les Hatton

[beware: link is broken]
http://www.amazon.co.uk/Safer-High-I...7092931&sr=8-1

>*The reason is
that C evolved and branched on its own long before the standards bodies
got their hands on it, and different implementors had wildly different
ideas about what different things meant. *As a result, ANSI (and thus
ISO) was reduced to trying to document the areas where most or all of
them agreed and leaving the areas of disagreement undefined.

Also, C was always intended to be as efficient as possible, and what
behavior is most efficient on different systems varies. *Finally, one of
C's greatest strengths is the ability to write both portable code (such
as cross-platform applications) and unportable code (such as device
drivers) in the same language; the way this is done is by allowing
"undefined" and "implementa tion-defined" behavior, which can be avoided
by anyone trying to write portable code but embraced by those who don't
care about portability.

<snip>

--
Nick Keighley

"The Dinosaurs have come and gone,
we Theriodonts remain"

[Dik T. Winter]

In article <gg*********@on line.de"Joachim Schmitz" <jo**@schmitz-digital.dewrite s:

CBFalconer wrote:

Joachim Schmitz wrote:

Dik T. Winter wrote:
ga*****@shell.x mission.com (Kenny McCormack) writes:

Bridgit Bardot (in her prime)

Who is that?

A typo. Actually three, her firstname is Brigitte

I think we should offer sympathy to Mr Winter.

For being to young to have seen BB in her prime? Nah...

Tsk. At least she was refreshing after DD. But since her retirement some
35 years ago she has become politically involved, although not exactly correct.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/