question about k&r2

[Anthony Irwin]

Hi all,

I have been going through the k&r2 book and all the examples are done
with main() instead of int main(void) and k&r2 in the start of chapter
1 does not return 0 so I haven't yet either.

I did two compiles shown below.

$ gcc -std=c89 -Wall exercise_1-9.c -o exercise_1-9
exercise_1-9.c:5: warning: return type defaults to `int'
exercise_1-9.c: In function `main':
exercise_1-9.c:27: warning: control reaches end of non-void function

$ gcc -std=c99 -Wall exercise_1-9.c -o exercise_1-9
exercise_1-9.c:5: warning: return type defaults to `int'
Why doesn't k&r2 have the int return type on main and why doesn't c99
care that I reached the end of a non-void function without returning a
value.

Kind Regards,
Anthony Irwin

[Richard Heathfield]

Anthony Irwin said:

Why doesn't k&r2 have the int return type on main

They rely on the fact that, if a function doesn't explicitly return any
type, it is assumed to return int. This is, in my opinion, poor style.

and why doesn't c99
care that I reached the end of a non-void function without returning a
value.

It does, normally - but they (foolishly?) made a special case for main.

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

[Anthony Irwin]

Richard Heathfield wrote:

Anthony Irwin said:

>>Why doesn't k&r2 have the int return type on main

They rely on the fact that, if a function doesn't explicitly return any
type, it is assumed to return int. This is, in my opinion, poor style.

>>and why doesn't c99
care that I reached the end of a non-void function without returning a
value.

It does, normally - but they (foolishly?) made a special case for main.

Ok thanks for the clarification. I will continue my way through the
k&r2 book which is definately a good book the sample programs they get
you to write seem more real some how, its hard to explain.

Thanks to all who recommended it as I would not have bought it if it
wasn't recommended so much here. Funny how one assumes that a smaller
book won't be as good as a bigger one.

Another quick question is var1 = var2 = var3 = var4 = 0; considered
good style to save typing. I saw it in k&r2 and it was a new concept
for me and I have used it a few types already.

Kind Regards,
Anthony Irwin

[Richard Heathfield]

Anthony Irwin said:

Another quick question is var1 = var2 = var3 = var4 = 0; considered
good style to save typing. I saw it in k&r2 and it was a new concept
for me and I have used it a few types already.

It's a handy shortcut. I would not recommend using it in too complicated
a way. For example, if you end up typing: a = b += c * a / d = e % f;
then you've probably gone too far.

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

[CBFalconer]

Anthony Irwin wrote:

>

.... snip ...

>
Another quick question is var1 = var2 = var3 = var4 = 0;
considered good style to save typing. I saw it in k&r2 and it
was a new concept for me and I have used it a few types already.

Opinions vary. I like it for various reasons. It emphasizes that
those items are initially equal. It may enable more efficient code
to be generated. It minimizes vertical space used.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

[pete]

Anthony Irwin wrote:

Another quick question is var1 = var2 = var3 = var4 = 0; considered
good style to save typing.

Saving typing is a valid reason for writing code in a certain way,
but it is the weakest of all valid reasons.

The rule is that for the above c code statement,
the assigment of the zero value may be assigned to the vars
in any order. So, make sure to use that kind of code construct,
only when the order of the assignments doesn't matter.

If this is what you mean:
p -next = q;
p = q;
don't write it this way:
p = p -next = q;

--
pete

[Army1987]

"Anthony Irwin" <no****@noemailhere.nowhereha scritto nel messaggio
news:eu**********@news-01.bur.connect.com.au...

Why doesn't k&r2 have the int return type on main and why doesn't c99 care
that I reached the end of a non-void function without returning a value.

C99 says that the closing brace of the main() function acts as return 0;},
or something like that (5.1.1.2.3.1).

[coder]

pete wrote:

Anthony Irwin wrote:

Another quick question is var1 = var2 = var3 = var4 = 0; considered
good style to save typing.

Saving typing is a valid reason for writing code in a certain way,
but it is the weakest of all valid reasons.

The rule is that for the above c code statement,
the assigment of the zero value may be assigned to the vars
in any order. So, make sure to use that kind of code construct,
only when the order of the assignments doesn't matter.

If this is what you mean:
p -next = q;
p = q;
don't write it this way:
p = p -next = q;

What's wrong with the above line? I thought that the assignment
operator has right-left associativity.

[Default User]

CBFalconer wrote:

Anthony Irwin wrote:

... snip ...

Another quick question is var1 = var2 = var3 = var4 = 0;
considered good style to save typing. I saw it in k&r2 and it
was a new concept for me and I have used it a few types already.

Opinions vary. I like it for various reasons. It emphasizes that
those items are initially equal. It may enable more efficient code
to be generated. It minimizes vertical space used.

I'm in the opposite camp. I've never used it in code. I generally feel
that variables that need initialization should be done at declaration
time, and I try to use an individual line for most variable
declarations.


Brian

[Craig Franck]

"CBFalconer" wrote

Anthony Irwin wrote:

>>

... snip ...

>>
Another quick question is var1 = var2 = var3 = var4 = 0;
considered good style to save typing. I saw it in k&r2 and it
was a new concept for me and I have used it a few types already.

Opinions vary. I like it for various reasons. It emphasizes that
those items are initially equal. It may enable more efficient code
to be generated. It minimizes vertical space used.

True, but most modern compilers can optimize away whitespace
and carriage returns.

--
Craig Franck
cr**********@verizon.net
Cortland, NY

[Peter Nilsson]

Richard Heathfield <[e-mail]:

Anthony Irwin said:

Why doesn't k&r2 have the int return type on main

They rely on the fact that, if a function doesn't explicitly
return any type, it is assumed to return int. This is, in my
opinion, poor style.

It may be a poor language 'feature', but I don't see it as
poor style.

Prior to standardisation, there was no void keyword. It makes
_more_ sense to leave out an explicit int than to put one in for
a function that doesn't return a value.

Of course, K&R2 was supposed to be about the (then) new standard,
but the fact remains the new standard was heavily backwards
compatible.

and why doesn't c99
care that I reached the end of a non-void function without
returning a value.

It does, normally - but they (foolishly?)

(Paul Psieh influence?)

made a special case for main.

The main function is not special cased in that regard.

There is still no requirement in C99 for a non-void function
to return a value. If the calling function attempts to use
a value from a non-void function that doesn't return a value
the behaviour is undefined. But unlike C++, a non-void function
failing to return a value is not, in and of itself, UB.

If you're talking about the default return value for main,
then I don't see that as being foolish if it strengthens
the robustness of otherwise sloppy programs without having
any adverse impact on C.

--
Peter

[CBFalconer]

pete wrote:

Anthony Irwin wrote:

.... snip ...

>
If this is what you mean:
p -next = q;
p = q;
don't write it this way:
p = p -next = q;

No reason not to. Same effect.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

[Richard Heathfield]

Peter Nilsson said:

Richard Heathfield <[e-mail]:

>Anthony Irwin said:

<snip>

and why doesn't c99
care that I reached the end of a non-void function without
returning a value.

It does, normally - but they (foolishly?)

(Paul Psieh influence?)

Not exactly, no - I actually have a great deal of respect for the ISO
folks - but I do think this particular decision was foo... well,
ill-advised, anyway.

>

>made a special case for main.

The main function is not special cased in that regard.

There is still no requirement in C99 for a non-void function
to return a value.

Ah, you are correct. My apologies. I'm just so accustomed to gcc's
diagnostic message (in other people's code!) that I got kerfuffled for
a moment there.

<snip>

If you're talking about the default return value for main,
then I don't see that as being foolish if it strengthens
the robustness of otherwise sloppy programs without having
any adverse impact on C.

I guess I'm just one of those people who think that programmers ought to
do The Right Thing, and that their compilers should help to persuade
them so to do. :-)

--
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 <wM%Nh.6153$_S.1855@trndny08>,
Craig Franck <cr**********@verizon.netwrote:

>>Another quick question is var1 = var2 = var3 = var4 = 0;
considered good style to save typing. I saw it in k&r2 and it
was a new concept for me and I have used it a few types already.

>Opinions vary. I like it for various reasons. It emphasizes that
those items are initially equal. It may enable more efficient code
to be generated. It minimizes vertical space used.

>True, but most modern compilers can optimize away whitespace
and carriage returns.

I assume that's a joke. The point of minimising vertical whitespace
is to let the human reader see the whole structure of a function at
once.

And I'd be surprised if any modern compiler really generates better
code just because of the form of the initialisation.

-- Richard

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

[pete]

coder wrote:

>
pete wrote:

Anthony Irwin wrote:

Another quick question is var1 = var2 = var3 = var4 = 0; considered
good style to save typing.

Saving typing is a valid reason for writing code in a certain way,
but it is the weakest of all valid reasons.

The rule is that for the above c code statement,
the assigment of the zero value may be assigned to the vars
in any order. So, make sure to use that kind of code construct,
only when the order of the assignments doesn't matter.

If this is what you mean:
p -next = q;
p = q;
don't write it this way:
p = p -next = q;

What's wrong with the above line? I thought that the assignment
operator has right-left associativity.

It's somewhat controversial,
but it has been known to have problems with real compilers.
http://groups.google.com/group/comp....+next+%3D+q%22

Jack Klein explained it well.
http://groups.google.com/group/comp....955214830fbcd3

"you are assuming that precedence and associativity forces order of
operation again, and even more importantly that it forces order of
modification of objects."

--
pete

[CBFalconer]

pete wrote:

coder wrote:

>pete wrote:

.... snip ...

>>>
If this is what you mean:
p -next = q;
p = q;
don't write it this way:
p = p -next = q;

What's wrong with the above line? I thought that the assignment
operator has right-left associativity.

It's somewhat controversial,
but it has been known to have problems with real compilers.
http://groups.google.com/group/comp....+next+%3D+q%22

Jack Klein explained it well.
http://groups.google.com/group/comp....955214830fbcd3

"you are assuming that precedence and associativity forces order of
operation again, and even more importantly that it forces order of
modification of objects."

If it doesn't work the compiler is badly broken. C expressions
have a value. Without side effects order of evaluation doesn't
enter into it.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

[Dave Hansen]

On Mar 28, 9:22 am, CBFalconer <[e-mail]:

pete wrote:

coder wrote:

pete wrote:

... snip ...

>If this is what you mean:
p -next = q;
p = q;
don't write it this way:
p = p -next = q;

What's wrong with the above line? I thought that the assignment
operator has right-left associativity.

It's somewhat controversial,
but it has been known to have problems with real compilers.
http://groups.google.com/group/comp....&group=comp.la...

Jack Klein explained it well.
http://groups.google.com/group/comp....955214830fbcd3

"you are assuming that precedence and associativity forces order of
operation again, and even more importantly that it forces order of
modification of objects."

If it doesn't work the compiler is badly broken. C expressions
have a value. Without side effects order of evaluation doesn't
enter into it.

Did you read the reference?

Given
p = p->next = q;
The compiler is free to compile this as if you had written
p = q;
p->next = q;
or
p->next = q;
p = q;

There is a difference. Quoting from the referenced article:

"I am not saying that any given compiler would actually execute
that
statement in that sequence, but THERE IS NOTHING IN THE C STANDARD
THAT PREVENTS IT."

If you want the latter semantics, write the latter syntax.

Regards,
-=Dave

[Old Wolf]

On Mar 27, 11:56 am, CBFalconer <[e-mail]:

If this is what you mean:
p -next = q;
p = q;
don't write it this way:
p = p -next = q;

No reason not to. Same effect.

Hardly, the latter causes undefined behaviour. Without an
intervening sequence point, p is both written, and read for
a purpose other than to determine the value to be written.
(That purpose is in fact to determine the location to write
another value).

To put it another way:
(p->next = q)
evaluates to q and has side-effect of updating p->next with q.
So the parent expression has side-effect of updating p with q.

There's no sequence point, so either side-effect could occur
first. Since both side-effects involve 'p' and one of them is
a write, the behaviour is undefined.

[Ben Pfaff]

pete <pf*****@mindspring.comwrites:

If this is what you mean:
p -next = q;
p = q;
don't write it this way:
p = p -next = q;

There have been multiple long, fierce threads on comp.lang.c and
comp.std.c covering this very issue over the years. I've started
some of them myself. I don't think there was ever consensus on
whether this is defined or undefined.

I try to avoid this kind of thing when I remember, because of the
uncertainty, but it is so "obviously correct" that it is
difficult to remember all the time.
--
"To get the best out of this book, I strongly recommend that you read it."
--Richard Heathfield

[CBFalconer]

Dave Hansen wrote:

>

.... snip ...

>
Did you read the reference?

Given
p = p->next = q;
The compiler is free to compile this as if you had written
p = q;
p->next = q;
or
p->next = q;
p = q;

There is a difference. Quoting from the referenced article:

No, but I still disagree. The left assignment is of the value of
the statement "p->next = q". To evaluate that statement you have
to evaluate the assignment "= q". There never is an assignment "p
= q" in the chain. This is because, in C, assignment statements
have a value, and that statement has to be performed before that
value is available. The point is that the value is that of the
completed assignment statement.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

[CBFalconer]

Old Wolf wrote:

On Mar 27, 11:56 am, CBFalconer <[e-mail]:

>>

>>If this is what you mean:
p -next = q;
p = q;
don't write it this way:
p = p -next = q;

No reason not to. Same effect.

Hardly, the latter causes undefined behaviour. Without an
intervening sequence point, p is both written, and read for
a purpose other than to determine the value to be written.
(That purpose is in fact to determine the location to write
another value).

p is NOT written. p->next is. That does not affect the value of
p. Well defined.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Old Wolf wrote:

>On Mar 27, 11:56 am, CBFalconer <[e-mail]:

>>>
If this is what you mean:
p -next = q;
p = q;
don't write it this way:
p = p -next = q;

No reason not to. Same effect.

Hardly, the latter causes undefined behaviour. Without an
intervening sequence point, p is both written, and read for
a purpose other than to determine the value to be written.
(That purpose is in fact to determine the location to write
another value).

p is NOT written. p->next is. That does not affect the value of
p. Well defined.

Yes, p is written; it's the target of an assignment.

<SEQUENCE_POINTp = p->next = q; <SEQUENCE_POINT>

C99 6.5p2:

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 read only to
determine the value to be stored.

Between the two sequence points, p is modified once (when the result
of "p->next = q" is assigned to it), *and* p is read for a purpose
other than to determine the value to be stored (in the evaluation of
the lvalue p->next, to determine the location to which to assign the
value of q).

--
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 Mar 29, 12:44 pm, CBFalconer <[e-mail]:

Old Wolf wrote:

On Mar 27, 11:56 am, CBFalconer <[e-mail]:

>If this is what you mean:
p -next = q;
p = q;
don't write it this way:
p = p -next = q;

No reason not to. Same effect.

Hardly, the latter causes undefined behaviour. Without an
intervening sequence point, p is both written, and read for
a purpose other than to determine the value to be written.
(That purpose is in fact to determine the location to write
another value).

p is NOT written. p->next is. That does not affect the value of
p. Well defined.

p most certainly is written; it is by itself on the left of an
assignment operator!

This code straight-out violates C99 6.5p2 (which Keith was kind
enough to quote). Ben Pfaff says there has been some debate over
this; if so then perhaps the debate should be about whether to
change the standard..?

[CBFalconer]

Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:

>Old Wolf wrote:

>>On Mar 27, 11:56 am, CBFalconer <[e-mail]:

If this is what you mean:
p -next = q;
p = q;
don't write it this way:
p = p -next = q;

No reason not to. Same effect.

Hardly, the latter causes undefined behaviour. Without an
intervening sequence point, p is both written, and read for
a purpose other than to determine the value to be written.
(That purpose is in fact to determine the location to write
another value).

p is NOT written. p->next is. That does not affect the value of
p. Well defined.

Yes, p is written; it's the target of an assignment.

I was referring to the interior portion of the statement. I wasn't
clear.

>
<SEQUENCE_POINTp = p->next = q; <SEQUENCE_POINT>

Agreed so far

>
C99 6.5p2:

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 read only to
determine the value to be stored.

Between the two sequence points, p is modified once (when the result
of "p->next = q" is assigned to it), *and* p is read for a purpose
other than to determine the value to be stored (in the evaluation of
the lvalue p->next, to determine the location to which to assign the
value of q).

And I disagree here, although I see your point. I think this
should head for the standards group, so cross-posted.

--
If you want to post a followup via groups.google.com, ensure
you quote enough for the article to make sense. Google is only
an interface to Usenet; it's not Usenet itself. Don't assume
your readers can, or ever will, see any previous articles.
More details at: <http://cfaj.freeshell.org/google/>
--
Posted via a free Usenet account from http://www.teranews.com

[pete]

CBFalconer wrote:

>
Dave Hansen wrote:

... snip ...

Did you read the reference?

Given
p = p->next = q;
The compiler is free to compile this as if you had written
p = q;
p->next = q;
or
p->next = q;
p = q;

There is a difference. Quoting from the referenced article:

No, but I still disagree. The left assignment is of the value of
the statement "p->next = q".
To evaluate that statement

If (p->next = q) was a statement, then you'd be right.
To evaluate that "expression" ...

you have to evaluate the assignment "= q".

The value of the expresssion (p->next = q), is equal to (q).

There never is an assignment "p = q" in the chain.
This is because, in C, assignment statements have a value,

Statements don't have values in C.

and that statement has to be performed before that
value is available.

You're mixing your terms "statements" and "expressions"
and that's the problem.
You're seeing sequence points where there are none.
Statements are sequence points.
Assignment isn't a sequence point.
(p = p->next = q) associates like (p = (p->next = q))

The value of (p->next = q) is the same as (q)
and that's why the value of q can be assigned to p.

--
pete