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.

[pete]

Pilcrow wrote:

printf("%d %c %c\n", i, *p1++, *p1 );

That line of code makes your program be undefined.

You modify p1 and read it twice
without an intervening sequence point,
to get an address of an object
that will have its value printed.

printf("%d %c %c\n", i, *p2, *p2++);

That one too.

N869
6.5 Expressions

[#2] Between the previous and next sequence point an object
shall have its stored value modified at most once by the
evaluation of an expression. Furthermore, the prior value
shall be accessed only to determine the value to be
stored.

--
pete

[Phil Carmody]

Pilcrow <Pi******@gmail.comwrites:

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 );

It is not specified when the effect "p1++" will happen. Therefore
"*p1" is meaningless in this context. The compiler can do what it
likes.

putchar('\n');
for(i = 0; i < 4; i++)
printf("%d %c %c\n", i, *p2, *p2++);

Again, it is not specified when the effect "p2++" will happen. Likewise,
"*p2" is meaningless in this context. Again, the compiler can do what it
likes.

}

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

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

It appears that the compiler chose to evaluate the arguments to printf
from the right to the left, or to not perform the incrementation of p1
until after all arguments were evaluated. You were lucky, much worse
things could have happened.

0 b a
1 c b
2 d c
3 d

It appears that the compiler chose to evaluate the arguments to printf
from the right to the left, and to perform the incrementation of p2 in
the rightmost argument before proceeding to evaluate the argument to the
left of it. Again, you were lucky, much worse things could have happened.

Combining those two data points, I think we can concluded that the
compiler choses to evaluate its arguments from right to left and to
perform the side-effects associated with each argument as it processes
that argument. It is permitted to so do. It it not oblided to so do.

The compiler's behaviour does not in any way seem "very strange", it
simply appears undefined. The only strange behaviour is that of the
author of the code thinking he could get away with writing code with
undefined behaviour.

Phil
--
I tried the Vista speech recognition by running the tutorial. I was
amazed, it was awesome, recognised every word I said. Then I said the
wrong word ... and it typed the right one. It was actually just
detecting a sound and printing the expected word! -- pbhj on /.

[Keith Thompson]

Pilcrow <Pi******@gmail.comwrites:

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

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

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)?

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

[Pilcrow]

On Mon, 17 Nov 2008 09:18:44 -0800, Keith Thompson <ks***@mib.org>
wrote:

>Pilcrow <Pi******@gmail.comwrites:

>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

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

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. Truly
gelatinous prose. Technical writing need not be so murky. Oh, well, we
live to learn.

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

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

[Kenny McCormack]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote a bunch of crap, leading up to:
....

>
Maybe ``you'' should "read" the 'standard' before you *complain* about
/it/.

You are such a tool.

[jameskuyper]

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
implementation 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
implementation 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
implementation 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
implementation-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).

[CBFalconer]

Pilcrow wrote:

>
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 );

From this point on your code is undefined. You have raised
undefined performance here. The compiler is entitled to do
whatever it wishes. Look up sequence points, and restrictions on
code between them.

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

[Stephen Sprunk]

Pilcrow wrote:

On Mon, 17 Nov 2008 09:18:44 -0800, Keith Thompson <ks***@mib.org>
wrote:

>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.

C is indeed less well-defined than most other languages. 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 "implementation-defined" behavior, which can be avoided
by anyone trying to write portable code but embraced by those who don't
care about portability.

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.

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

Start by translating Annex J, but I bet you'll find that your
translation is several times as long, and by the time you're complete,
you won't need it anymore because the Standard will have started to make
an odd sort of sense to you.

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.

The most obvious sequence points are ;'s after expressions and function
calls. There are a few others, as noted in the Standard, but if you're
just getting started, the simplest approach is to assume for now that no
others exist. More important is why you need to _care_ about sequence
points, and I can't even begin to explain that in English...

S

[CBFalconer]

Pilcrow wrote:

Keith Thompson <ks***@mib.orgwrote:

.... snip ...

>

>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?

n1256 is more accurate than the printed versions you can buy.

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

[Pilcrow]

On Mon, 17 Nov 2008 13:38:40 -0800 (PST), jameskuyper
<ja*********@verizon.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
implementation 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
implementation 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
implementation 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
implementation-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.org>
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 <[e-mail]:

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

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**********************************@r36g2000prf. googlegroups.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**********@news.xmission.comga*****@shell.xmission.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**********@news.xmission.com>
ga*****@shell.xmission.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.xmission.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.xmission.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 <[e-mail]:

Pilcrow wrote:

On Mon, 17 Nov 2008 09:18:44 -0800, Keith Thompson <[e-mail]>
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 "implementation-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*********@online.de"Joachim Schmitz" <jo**@schmitz-digital.dewrites:

CBFalconer wrote:

Joachim Schmitz wrote:

Dik T. Winter wrote:
ga*****@shell.xmission.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/

[Joachim Schmitz]

Dik T. Winter wrote:

In article <gg*********@online.de"Joachim Schmitz"
<jo**@schmitz-digital.dewrites:

>CBFalconer wrote:

>>Joachim Schmitz wrote:
Dik T. Winter wrote:
ga*****@shell.xmission.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.

Yes, I'm old enough to decipher that 8-))

But since her retirement
some 35 years ago she has become politically involved, although not
exactly correct.

Partly true indeed... (her fight against seal hunting was OK, IMHO)

Bye, Jojo