C elements of style

[aarklon]

Hi all,

I was going through the book "C Elements of style" by steve oualline.
in this book many guidelines are given.

the following were seen in the book as rules

1) while(1) is preferred over for(;;)
2) use of const is preferred over #define
3) unless extreme efficiency is warranted, use printf instead of putc
& puts
now my question is

can anyone give examples for the justification of above rules ..????

OR
To what extent these rules are true..???

[user923005]

On Apr 2, 12:26*pm, [e-mail] wrote:

Hi all,

I was going through the book "C Elements of style" by steve oualline.
in this book many guidelines are given.

the following were seen in the book as rules

1) *while(1) is preferred over for(;;)

I am opposite here. The constructs create identical results and the
meaning for both is obvious. Some lints and compilers will whine
about while (1) but they do not add any noise for for(;;).

2) *use of const is preferred over #define

This one is obvious. #define can unexpectedly change something if you
are not careful.

3) *unless extreme efficiency is warranted, use printf instead of putc
& puts

Nonsense. If there is no format string, use puts(). If you are
outputting a single character, use putc().

now my question is

can anyone give examples for the justification of above rules ..????

* * * * * * * * * * * * * * * *OR
To what extent these rules are true..???

I like number 2, and the other two rub me the wrong way.

[Eric Sosman]

aa*****@gmail.com wrote:

Hi all,

I was going through the book "C Elements of style" by steve oualline.
in this book many guidelines are given.

the following were seen in the book as rules

1) while(1) is preferred over for(;;)
2) use of const is preferred over #define
3) unless extreme efficiency is warranted, use printf instead of putc
& puts
now my question is

can anyone give examples for the justification of above rules ..????

OR
To what extent these rules are true..???

(1) is an expression of somebody's personal preference,
in the form of a rule. It seems to me to have as much force
as "indent in multiples of three spaces" or "adverbAlways
verbUse adjectiveHungarian nounNotation."

(2) has appeared in the draft CERT "Secure C Coding
Standard," and some justification is given there. For what
it's worth, I find the justifications unconvincing. Still,
of the Three Rules this may be the most defensible.

(3) seems silly. It might make sense if inverted ("Don't
switch from printf() to putchar() just for a tiny speed gain"),
but in the actual form used ... Does this Rulemaker go on to
recommend pow(x,2) instead of x*x, or pow(2,6) instead of 64?

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

[Richard Tobin]

In article <0f**********************************@m36g2000hse. googlegroups.com>,

>1) *while(1) is preferred over for(;;)

I am opposite here. The constructs create identical results and the
meaning for both is obvious.

An experienced C programmer will of course be familiar with both, but
I don't think the meaning of "for(;;)" is obvious. It doesn't follow
from anything else that an empty continuation condition is true; the
best you can do is say that it would be pointless if it worked the
other way. "while(1)" on the other hand is not a special case at all.

-- Richard
--
:wq

[aarklon]

On Apr 3, 12:58*am, Eric Sosman <[e-mail]:

>

*Does this Rulemaker go on to

recommend pow(x,2) instead of x*x, or pow(2,6) instead of 64?

he gives many rules, some of them are as follows

4) always split a for statement into 3 lines

5) when splitting up a conditional clause(?:),write it on three lines:
the condition line,the true-value line, and the false-value
line.indent the last two lines an extra level

6)allow no more than 5 parameters to a function

7)avoid do/while use while and break instead.

8)use the comma operator inside a for statement only to put together
two statements. never use it to combine three statements

9)always put a break at the end of the last case in a switch statement

[Ben Pfaff]

user923005 <dc*****@connx.comwrites:

On Apr 2, 12:26*pm, [e-mail] wrote:

>3) *unless extreme efficiency is warranted, use printf instead of putc
& puts

Nonsense. If there is no format string,

....and the string to print ends in new-line, then...

use puts(). If you are
outputting a single character, use putc().

--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[Walter Roberson]

In article <1207166230.803380@news1nwk>,
Eric Sosman <Er*********@sun.comwrote:

>aa*****@gmail.com wrote:

>I was going through the book "C Elements of style" by steve oualline.

>3) unless extreme efficiency is warranted, use printf instead of putc
& puts

(3) seems silly. It might make sense if inverted ("Don't
switch from printf() to putchar() just for a tiny speed gain"),
but in the actual form used ...

My -speculation- would be that the reasoning is that for text
output, printf() appears so often that when putc() or puts()
appears, people may have to stop and think about whether there
is anything "special" or "magic" about what is being output
or about the way that putc() or puts() operate so as to warrant
the use of those functions instead of printf().

For example, I see puts() seldom enough that I tend to forget that
puts() adds \n automatically and then when I glance at code
that uses puts() I tend to think, "Hold on, where's the \n ??"
So there is some "magic" about puts() that has to be remembered.
(especially as fputs() does not add a \n ).

putc(), though, I personally find immediately obvious.
--
"To the modern spirt nothing is, or can be rightly known,
except relatively and under conditions." -- Walter Pater

[Default User]

aa*****@gmail.com wrote:

Hi all,

I was going through the book "C Elements of style" by steve oualline.
in this book many guidelines are given.

the following were seen in the book as rules

1) while(1) is preferred over for(;;)

This will lead to warnings in some cases. That being said, it's my
preferred way.

2) use of const is preferred over #define

That won't work for array dimensions. There should at least be
exceptions for that case.

3) unless extreme efficiency is warranted, use printf instead of putc
& puts

I can't see why this would be preferable. Besides being possibly less
efficient, printf() is often less readable and more prone to error.

OR

To what extent these rules are true..???

Style rules can't be true or false.


Brian

[Flash Gordon]

Eric Sosman wrote, On 02/04/08 20:58:

aa*****@gmail.com wrote:

>Hi all,

I was going through the book "C Elements of style" by steve oualline.
in this book many guidelines are given.

the following were seen in the book as rules

1) while(1) is preferred over for(;;)
2) use of const is preferred over #define
3) unless extreme efficiency is warranted, use printf instead of putc
& puts
now my question is

can anyone give examples for the justification of above rules ..????

OR
To what extent these rules are true..???

(1) is an expression of somebody's personal preference,
in the form of a rule. It seems to me to have as much force
as "indent in multiples of three spaces" or "adverbAlways
verbUse adjectiveHungarian nounNotation."

Agreed.

(2) has appeared in the draft CERT "Secure C Coding
Standard," and some justification is given there. For what
it's worth, I find the justifications unconvincing. Still,
of the Three Rules this may be the most defensible.

The problem is that const does not introduce a compile time constant so
it is not suitable for a lot of purposes and can cause confusion in
others. I would say that (ab)using enum to create constants of type int
has value and #define for the rest often makes more sense.

(3) seems silly. It might make sense if inverted ("Don't
switch from printf() to putchar() just for a tiny speed gain"),
but in the actual form used ... Does this Rulemaker go on to
recommend pow(x,2) instead of x*x, or pow(2,6) instead of 64?

Agreed.

Based on that sample I would say it was a source not to be trusted.
--
Flash Gordon

[Flash Gordon]

aa*****@gmail.com wrote, On 02/04/08 21:15:

On Apr 3, 12:58 am, Eric Sosman <[e-mail]:

Does this Rulemaker go on to

>recommend pow(x,2) instead of x*x, or pow(2,6) instead of 64?

he gives many rules, some of them are as follows

4) always split a for statement into 3 lines

As an "always" I definitely disagree. In the simple case of something like:
for (i=0; i<lim; i++)
it is completely pointless in my opinion. On some longer or more complex
instances it can make sense to split it.

5) when splitting up a conditional clause(?:),write it on three lines:
the condition line,the true-value line, and the false-value
line.indent the last two lines an extra level

Again, a stupid rule in my opinion. Think what it would do to...
fprintf(fp,"stuff %d more stuff",ptr?*ptr:0);
Then imagine you have more parameters before and after that one.
I come across requirements most easily implemented like this when
producing interfacing files to be sent to other systems.

6)allow no more than 5 parameters to a function

A bit arbitrary and people will certainly argue about precisely what the
limit should be, but makes more sense.

7)avoid do/while use while and break instead.

This is just plain stupid. If the problems maps properly on to a
do/while loop then use that rather than trying to bend some other
construct to your needs. I don't use them very often, but when they are
the correct construct they are the correct construct.

8)use the comma operator inside a for statement only to put together
two statements. never use it to combine three statements

Again, rather arbitrary, people will definitely argue over what the
limit should be.

9)always put a break at the end of the last case in a switch statement

At last one that I can completely agree with.
Once again, I recommend not using this set of rules.
--
Flash Gordon

[Mark McIntyre]

aa*****@gmail.com wrote:

Hi all,

I was going through the book "C Elements of style" by steve oualline.
in this book many guidelines are given.

the following were seen in the book as rules

1) while(1) is preferred over for(;;)

any decent compiler will convert them into exactly the same opcodes.

2) use of const is preferred over #define

Try using a const to define an array size (in C89), or as a case label.

3) unless extreme efficiency is warranted, use printf instead of putc
& puts

again identical if you have a decent compiler.

can anyone give examples for the justification of above rules ..????

No, they're stylistic, not practical.

[Richard Heathfield]

Mark McIntyre said:

aa*****@gmail.com wrote:

>Hi all,

I was going through the book "C Elements of style" by steve oualline.
in this book many guidelines are given.

the following were seen in the book as rules

1) while(1) is preferred over for(;;)

any decent compiler will convert them into exactly the same opcodes.

True - but that isn't really the point, is it? The point is that you have
two different ways of describing the same thing in the source language,
and Mr Oualline is expressing a preference for one over the other,
presumably because he finds it more readable or more logical or something.
There is nothing wrong with favouring one mode of expression over another
when the two both mean the same thing (i.e. will be converted into exactly
the same opcodes), but one should not normally expect that everybody else
will agree with one's choice or one's reasoning.

>2) use of const is preferred over #define

Try using a const to define an array size (in C89), or as a case label.

>3) unless extreme efficiency is warranted, use printf instead of putc
& puts

again identical if you have a decent compiler.

I'd have thought a decent library would be more relevant here. :-)

>can anyone give examples for the justification of above rules ..????

No, they're stylistic, not practical.

I agree that there doesn't seem to be any practical purpose behind any of
these three recommendations. To call them "rules" is just silly.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

"Default User" <de***********@yahoo.comwrites:

aa*****@gmail.com wrote:

>>
I was going through the book "C Elements of style" by steve oualline.
in this book many guidelines are given.

the following were seen in the book as rules

1) while(1) is preferred over for(;;)

This will lead to warnings in some cases. That being said, it's my
preferred way.

>2) use of const is preferred over #define

That won't work for array dimensions. There should at least be
exceptions for that case.

If your compiler supports VLAs, it *will* work for array dimensions.
And that could be a problem.

"const" doesn't create a constant expression. If you don't need a
constant expression (i.e., one that must be evaluable at compile
time), then by all means use "const"; it's cleaner IMHO than #define.
But if you need a constant expression, "const" just won't do the job.

>3) unless extreme efficiency is warranted, use printf instead of putc
& puts

I can't see why this would be preferable. Besides being possibly less
efficient, printf() is often less readable and more prone to error.

puts() also avoids problems like:

char *message = "Hello, %d world";
printf(message);

But the solution to that is to understand who printf works.

I have no strong preference one way or the other for printf vs. puts
in cases where either will do the job.

[...]

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"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:

Mark McIntyre said:

>aa*****@gmail.com wrote:

[...]

>>3) unless extreme efficiency is warranted, use printf instead of putc
& puts

again identical if you have a decent compiler.

I'd have thought a decent library would be more relevant here. :-)

Quibble:

No, it's the compiler that's relevant. A library implementation of
printf can't avoid parsing the format string, even if it optimizes the
case where there are no '%' characters. A compiler, on the other
hand, can sometimes convert a printf call to an equivalent puts call.

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

[Himanshu Chauhan]

aa*****@gmail.com wrote:

Hi all,

I was going through the book "C Elements of style" by steve oualline.
in this book many guidelines are given.

the following were seen in the book as rules

1) while(1) is preferred over for(;;)
2) use of const is preferred over #define

One benefit of using (2) I can see is, while debugging you can see the
symbol rather than a value.

--Himanshu

[Ben Pfaff]

Himanshu Chauhan <hs********@gmail.comwrites:

aa*****@gmail.com wrote:

>2) use of const is preferred over #define

One benefit of using (2) I can see is, while debugging you can see the
symbol rather than a value.

Not in any C implementation of which I am aware. But many
extend this benefit to enums.
--
Ben Pfaff
http://benpfaff.org

[schiller1800]

On 3 Apr., 05:05, Keith Thompson <[e-mail]:

Richard Heathfield <[e-mail]:

Mark McIntyre said:

[e-mail] wrote:

[...]

>3) unless extreme efficiency is warranted, use printf instead of putc
& puts

again identical if you have a decent compiler.

I'd have thought a decent library would be more relevant here. :-)

Quibble:

No, it's the compiler that's relevant. A library implementation of
printf can't avoid parsing the format string, even if it optimizes the
case where there are no '%' characters. A compiler, on the other
hand, can sometimes convert a printf call to an equivalent puts call.

Do you know ANY compiler which actually does this?! Because I have
never heard of that kind of optimization before.

[Ben Pfaff]

sc**********@yahoo.com writes:

On 2 Apr., 21:26, [e-mail] wrote:

>1) while(1) is preferred over for(;;)

Obviously, "while(1)" (or even better C99ish "while(true)") looks more
pleasing. It is clearer to the human reader.

This is not obvious to me after many years of seeing "for (;;)"
in C code. Perhaps "while (1)" is clearer to C novices, but C
programmers who experience with diverse code bases should
recognize either form with equal ease.
--
"...Almost makes you wonder why Heisenberg didn't include postinc/dec operators
in the uncertainty principle. Which of course makes the above equivalent to
Schrodinger's pointer..."
--Anthony McDonald

[Ben Pfaff]

sc**********@yahoo.com writes:

On 3 Apr., 05:05, Keith Thompson <[e-mail]:

>A library implementation of
printf can't avoid parsing the format string, even if it optimizes the
case where there are no '%' characters. A compiler, on the other
hand, can sometimes convert a printf call to an equivalent puts call.

Do you know ANY compiler which actually does this?! Because I have
never heard of that kind of optimization before.

GCC will do this:

blp@blp:~(0)$ cat test.c
#include <stdio.h>

int main (void)
{
printf ("Hello, world!\n");
return 0;
}
blp@blp:~(0)$ gcc -O3 test.c -o test
blp@blp:~(0)$ nm test | grep printf
blp@blp:~(1)$ nm test | grep puts
U puts@@GLIBC_2.0
blp@blp:~(0)$ gcc -v 2>&1|grep version
gcc version 4.1.3 20070718 (prerelease) (Debian 4.1.2-14)
blp@blp:~(0)$

--
"Some people *are* arrogant, and others read the FAQ."
--Chris Dollin

[santosh]

sc**********@yahoo.com wrote:

On 3 Apr., 05:05, Keith Thompson <[e-mail]:

>>
A compiler, on the other
hand, can sometimes convert a printf call to an equivalent puts call.

Do you know ANY compiler which actually does this?! Because I have
never heard of that kind of optimization before.

In my experience the GNU C compiler does this.

[Richard Tobin]

In article <Zy******************@en-nntp-09.am2.easynews.com>,
Mark McIntyre <ma**********@spamcop.netwrote:

>1) while(1) is preferred over for(;;)

any decent compiler will convert them into exactly the same opcodes.

Irrelevant to whether it is better style.

>3) unless extreme efficiency is warranted, use printf instead of putc
& puts

again identical if you have a decent compiler.

Again irrelevant.

>can anyone give examples for the justification of above rules ..????

No, they're stylistic

The OP knows that. That's why the subject line is "C elements of
style". The fact that they are rules of style doesn't mean they don't
have justifications.

>not practical.

The reasons for style rules are usually practical ones, such as
readability and maintainability.

-- Richard
--
:wq

[Richard Tobin]

In article <97**********************************@13g2000hsb.g ooglegroups.com>,
<sc**********@yahoo.comwrote:

>Obviously, "while(1)" (or even better C99ish "while(true)") looks more
pleasing. It is clearer to the human reader. However, many compilers
will produce a warning when confronted with "while(1)", because a
constant condition in the head of a while loop is usually a bug.

Obviously it isn't usually a bug, since "while(1)" is a common
idiom. It would make much more sense for the compiler to complain
only about non-trivial expressions that turn out to evaluate to
a constant.

-- Richard


--
:wq

[aarklon]

On Apr 2, 4:15 pm, [e-mail] wrote:

On Apr 3, 12:58 am, Eric Sosman <[e-mail]:

Does this Rulemaker go on to

recommend pow(x,2) instead of x*x, or pow(2,6) instead of 64?

he gives many rules, some of them are as follows

4) always split a for statement into 3 lines

5) when splitting up a conditional clause(?:),write it on three lines:
the condition line,the true-value line, and the false-value
line.indent the last two lines an extra level

6)allow no more than 5 parameters to a function

7)avoid do/while use while and break instead.

8)use the comma operator inside a for statement only to put together
two statements. never use it to combine three statements

9)always put a break at the end of the last case in a switch statement

more rules fro the same book

10) do not use absolute paths in #include directives. let the -I
compile option do the work

11) begin all debug printfs with ##
ex:- printf("## state=%d",state);

12) the best indentation is 4 spaces

13) if a macro contains more than one statement, use a do while
structure to enclose the macro

ex:- #define ABORT \
do{ \
puts("abort"); \
exit(8); \
}while(0);

[Ben Bacarisse]

aa*****@gmail.com writes:
<snip some rather dubious style rules>

13) if a macro contains more than one statement, use a do while
structure to enclose the macro

ex:- #define ABORT \
do{ \
puts("abort"); \
exit(8); \
}while(0);

I hope it does not include the ; at the end. As you have it,

if (C)
ABORT;
else
go_on();

is a syntax error.

--
Ben.

[Eric Sosman]

aa*****@gmail.com wrote:

>
more rules fro the same book

10) do not use absolute paths in #include directives. let the -I
compile option do the work

Usually good, but follow established convention for
the environment you're writing in. E.g., POSIX code should
include <sys/types.hrather than <types.h>.

11) begin all debug printfs with ##
ex:- printf("## state=%d",state);

It's nice to distinguish them in *some* consistent way.
It's also nice to mark "ordinary" messages in a way that aids
automated scanning of log files and so on. Also, consider
whether such messages might be better on stderr than stdout.

12) the best indentation is 4 spaces

Does the author cite any research for this conclusion?
The only study I've ever seen -- and it was long ago and I
can no longer cite the source -- found that a two-space
indent was too narrow and four just a bit too wide; that
study's conclusion was that a three-space indent was most
likely "best."

13) if a macro contains more than one statement, use a do while
structure to enclose the macro

ex:- #define ABORT \
do{ \
puts("abort"); \
exit(8); \
}while(0);

Oh, and he was doing *so* well until that final character!
Tsk, tsk.

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

[Default User]

Keith Thompson wrote:

"Default User" <de***********@yahoo.comwrites:

aa*****@gmail.com wrote:

2) use of const is preferred over #define

That won't work for array dimensions. There should at least be
exceptions for that case.

If your compiler supports VLAs, it will work for array dimensions.
And that could be a problem.

Good point, because you can different behavior than you were going for.
I'm still not really getting into the C99 mindset, I'm afraid. I know
the basic concept of VLAs, but I've never used them and they don't leap
to mind sometimes.

Brian

[Ben Pfaff]

aa*****@gmail.com writes:

13) if a macro contains more than one statement, use a do while
structure to enclose the macro

ex:- #define ABORT \
do{ \
puts("abort"); \
exit(8); \
}while(0);

If you do this, then you should omit the ; at the end of the
do...while statement. Otherwise it defeats the purpose, because
you cannot use the macro as if it were a statement.

It is unconventional, in my experience, to define an object-like
macro this way. It would be more conventional to name it
ABORT(), so that it looks like a function.

The value 8 is not a portable exit status.
--
"Give me a couple of years and a large research grant,
and I'll give you a receipt." --Richard Heathfield

[Richard Heathfield]

Eric Sosman said:

aa*****@gmail.com wrote:

>>

<snip>

>

>12) the best indentation is 4 spaces

Does the author cite any research for this conclusion?
The only study I've ever seen -- and it was long ago and I
can no longer cite the source -- found that a two-space
indent was too narrow and four just a bit too wide; that
study's conclusion was that a three-space indent was most
likely "best."

The study was correct to identify that four space indent is too wide, but
erroneous in recommending three spaces because, obviously, it has to be a
power of two. One space is clearly too few, but two is just right.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ben Pfaff]

Eric Sosman <es*****@ieee-dot-org.invalidwrites:

aa*****@gmail.com wrote:

>>
more rules fro the same book

10) do not use absolute paths in #include directives. let the -I
compile option do the work

Usually good, but follow established convention for
the environment you're writing in. E.g., POSIX code should
include <sys/types.hrather than <types.h>.

I would ordinarily consider both sys/types.h and types.h to be
relative paths. /usr/include/sys/types.h would be an absolute
path (and indeed, I avoid them in #include directives to the
extent that I don't recall ever using one).
--
"...deficient support can be a virtue.
It keeps the amateurs off."
--Bjarne Stroustrup

[aarklon]

On Apr 3, 11:51 am, Ben Pfaff <[e-mail]:

>
The value 8 is not a portable exit status.

then can you give examples for portable exit status, other than
EXIT_FAILURE,EXIT_SUCCESS

[Ben Pfaff]

aa*****@gmail.com writes:

On Apr 3, 11:51 am, Ben Pfaff <[e-mail]:

>The value 8 is not a portable exit status.

then can you give examples for portable exit status, other than
EXIT_FAILURE,EXIT_SUCCESS

0 is the only other portable exit status.
--
Ben Pfaff
http://benpfaff.org

[Walter Roberson]

In article <QO******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>The study was correct to identify that four space indent is too wide, but
erroneous in recommending three spaces because, obviously, it has to be a
power of two. One space is clearly too few, but two is just right.

3 is representable as a power of 2. Not an integral power, but you
didn't specify integral power ;-) (And if you had, some wag like
me would have specified 1/2 a space, since -1 is integral.)
--
"All is vanity." -- Ecclesiastes

[aarklon]

On Apr 3, 12:25 pm, Ben Pfaff <[e-mail]:

[e-mail] writes:

On Apr 3, 11:51 am, Ben Pfaff <[e-mail]:

The value 8 is not a portable exit status.

then can you give examples for portable exit status, other than
EXIT_FAILURE,EXIT_SUCCESS

0 is the only other portable exit status.

why 1 is not considered as a portable exit status, AFAIK exit(1)
is usually used to indicate error conditions isn't it ...????

[Walter Roberson]

In article <7d**********************************@e10g2000prf. googlegroups.com>,
<aa*****@gmail.comwrote:

why 1 is not considered as a portable exit status, AFAIK exit(1)
is usually used to indicate error conditions isn't it ...????

"usually" is not the same as "portably". There are real operating
systems (with real C compilers) for which exit(1) means something
specific to the operating system.

--
"Man's life is but a jest,
A dream, a shadow, bubble, air, a vapor at the best."
-- George Walter Thornbury

[Ben Pfaff]

aa*****@gmail.com writes:

On Apr 3, 12:25 pm, Ben Pfaff <[e-mail]:

>[e-mail] writes:

On Apr 3, 11:51 am, Ben Pfaff <[e-mail]:

>The value 8 is not a portable exit status.

then can you give examples for portable exit status, other than
EXIT_FAILURE,EXIT_SUCCESS

0 is the only other portable exit status.

why 1 is not considered as a portable exit status, AFAIK exit(1)
is usually used to indicate error conditions isn't it ...????

Here is what the standard says:

If the value of status is zero or EXIT_SUCCESS, an
implementation-defined form of the status successful
termination is returned. If the value of status is
EXIT_FAILURE, an implementation-defined form of the status
unsuccessful termination is returned. Otherwise the status
returned is implementation-defined.

Here is what the rationale says:

The argument to exit is a status indication returned to the
invoking environment. In the UNIX operating system, a
value of zero is the successful return code from a program.
As usage of C has spread beyond UNIX, exit(0) has often
been retained as an idiom indicating successful
termination, even on operating systems with different
systems of return codes. This usage is thus recognized as
standard. There has never been a portable way of
indicating a non-successful termination, since the
arguments to exit are implementation-defined. The
EXIT_FAILURE macro was added to C89 to provide such a
capability. EXIT_SUCCESS was added as well.

As I understand it, on some operating systems, e.g. OpenVMS,
particular return values are interpreted with specific and
nuanced meanings, and so it is best not to wantonly return values
other than the ones with standard meanings.
--
"To get the best out of this book, I strongly recommend that you read it."
--Richard Heathfield

[Eric Sosman]

Richard Heathfield wrote:

Eric Sosman said:

>aa*****@gmail.com wrote:

<snip>

>>12) the best indentation is 4 spaces

Does the author cite any research for this conclusion?
The only study I've ever seen -- and it was long ago and I
can no longer cite the source -- found that a two-space
indent was too narrow and four just a bit too wide; that
study's conclusion was that a three-space indent was most
likely "best."

The study was correct to identify that four space indent is too wide, but
erroneous in recommending three spaces because, obviously, it has to be a
power of two. One space is clearly too few, but two is just right.

... but three *is* a power of two! It's

22222 1.5849625007211561814537+
2 2
2
2
2
22
2222222

(Now that I think of it, though, the study's conclusion
was indeed probably wrong. The interpolation should have
been on the exponent, and the recommended indentation width
should have been 2^1.5 = 2.82842712474619009760+ spaces.)

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

[Eric Sosman]

Ben Pfaff wrote:

Eric Sosman <es*****@ieee-dot-org.invalidwrites:

>aa*****@gmail.com wrote:

>>more rules fro the same book

10) do not use absolute paths in #include directives. let the -I
compile option do the work

Usually good, but follow established convention for
the environment you're writing in. E.g., POSIX code should
include <sys/types.hrather than <types.h>.

I would ordinarily consider both sys/types.h and types.h to be
relative paths. /usr/include/sys/types.h would be an absolute
path (and indeed, I avoid them in #include directives to the
extent that I don't recall ever using one).

Yeah, I think the author's use of "absolute" is suspect.
Most likely (it seems to me), he was talking about

#include "libfoo/foo.h"
#include "../../libbar/bar.h"

.... and the like. Not "absolute" in any usual sense, but
certainly "location-dependent."

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

[Richard Heathfield]

Eric Sosman said:

<snip>

Yeah, I think the author's use of "absolute" is suspect.
[...] Not "absolute" in any usual sense, but
certainly "location-dependent."

Relatively absolute?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Default User]

aa*****@gmail.com wrote:

12) the best indentation is 4 spaces

Now, this is just insane. All right-thinking people know that the
correct answer is "three". Everything else is morally repugnant and/or
a terrorist plot.


Brian

[Richard Heathfield]

Default User said:

aa*****@gmail.com wrote:

>12) the best indentation is 4 spaces

Now, this is just insane. All right-thinking people know that the
correct answer is "three". Everything else is morally repugnant and/or
a terrorist plot.

Anyone who is concerned that you may be part of some kind of comp.lang.c
clique or cabal can now rest easy. No self-respecting cabalier would use a
three-space indent.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Joachim Schmitz]

Richard Heathfield wrote:

Eric Sosman said:

<snip>

>Yeah, I think the author's use of "absolute" is suspect.
[...] Not "absolute" in any usual sense, but
certainly "location-dependent."

Relatively absolute?

Absolutly relative!

[Joachim Schmitz]

Richard Heathfield wrote:

Default User said:

>aa*****@gmail.com wrote:

>>12) the best indentation is 4 spaces

Now, this is just insane. All right-thinking people know that the
correct answer is "three". Everything else is morally repugnant
and/or a terrorist plot.

Anyone who is concerned that you may be part of some kind of
comp.lang.c clique or cabal can now rest easy. No self-respecting
cabalier would use a three-space indent.

What's wrong with TAB? So everyone can adjust the tab width to his/her
liking?

Bye, Jojo

[Richard Heathfield]

Joachim Schmitz said:

Richard Heathfield wrote:

<snip>

>Anyone who is concerned that you may be part of some kind of
comp.lang.c clique or cabal can now rest easy. No self-respecting
cabalier would use a three-space indent.

What's wrong with TAB? So everyone can adjust the tab width to his/her
liking?

Firstly, it doesn't work terribly well on Usenet, since some news clients
strip tabs out before display. Worse, some clients strip tabs out *before
reply* - so it looks fine in the reader, but goes pear-shaped in a quote.

Secondly, let's take an example like this:

rc = myfunctioncall(arga,
argb,
argc);

which looks lovely with spaces. Now let's try it with an eight-space tab
(which I'm imitating with spaces, for the sake of Usenet clients!):

rc = myfunctioncall(arga,
argb,
argc);

If we replace those eight-space sequences with \t markers, we get this:

\trc = myfunctioncall(arga,
\t\t\t argb,
\t\t\t argc);

That's fine, although it looks messy, because the editor will expand the
tabs to eight spaces.

Now let's use a three-space tab setting, and see what it expands to:

rc = myfunctioncall(arga,
argb,
argc);

argb and argc still line up with each other, of course, but they no longer
line up with arga. So the three-space tabber takes code that was written
with eight-space tabs and loads it into his editor, and much of the
indentation is suddenly far less readable than the writer intended.

Either of these reasons is sufficient for a Usenetting programmer to stick
to spaces, and the latter is, in my view, sufficient even for a
non-Usenetting programmer, which is why I started using spaces-not-tabs
some time before I began posting to Usenet (so it's just as well for me
that the two reasons both point in the same direction!).

Incidentally, I generally set up my editor to convert tabs to spaces, so
that I can still /use/ the TAB key. My decision to drop from a four-space
indent to a two-space indent was a direct consequence of beginning to post
to Usenet - I haven't yet found a newsreader that converts tabs to spaces
(let alone a user-configurable number of spaces) on *writing*, and I got
sick and tired of typing spacespacespacespace at the start of practically
every code line.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Joachim Schmitz]

Richard Heathfield wrote:

Joachim Schmitz said:

>Richard Heathfield wrote:

<snip>

>>Anyone who is concerned that you may be part of some kind of
comp.lang.c clique or cabal can now rest easy. No self-respecting
cabalier would use a three-space indent.

What's wrong with TAB? So everyone can adjust the tab width to
his/her liking?

Firstly, it doesn't work terribly well on Usenet, since some news
clients strip tabs out before display. Worse, some clients strip tabs
out *before reply* - so it looks fine in the reader, but goes
pear-shaped in a quote.

I don't usually write code for Usenet (and if, I'd indeed rather use spaces
and avoid // comments). And I guess most programmers don't.

Secondly, let's take an example like this:

rc = myfunctioncall(arga,
argb,
argc);

which looks lovely with spaces. Now let's try it with an eight-space
tab (which I'm imitating with spaces, for the sake of Usenet
clients!):

rc = myfunctioncall(arga,
argb,
argc);

If we replace those eight-space sequences with \t markers, we get
this:

\trc = myfunctioncall(arga,
\t\t\t argb,
\t\t\t argc);

If there's a need to keep such alignement, I'd write this as
\trc = myfunctioncall(arga,
\t argb,
\t argc);

That's fine, although it looks messy, because the editor will expand
the tabs to eight spaces.

Now let's use a three-space tab setting, and see what it expands to:

rc = myfunctioncall(arga,
argb,
argc);
argb and argc still line up with each other, of course, but they no
longer line up with arga. So the three-space tabber takes code that
was written with eight-space tabs and loads it into his editor, and
much of the indentation is suddenly far less readable than the writer
intended.

Not in my case

Bye, Jojo

[Kenneth Brody]

Flash Gordon wrote:

>
Eric Sosman wrote, On 02/04/08 20:58:

aa*****@gmail.com wrote:

Hi all,

I was going through the book "C Elements of style" by steve oualline.
in this book many guidelines are given.

[...]

2) use of const is preferred over #define

[...]

(2) has appeared in the draft CERT "Secure C Coding
Standard," and some justification is given there. For what
it's worth, I find the justifications unconvincing. Still,
of the Three Rules this may be the most defensible.

The problem is that const does not introduce a compile time constant so
it is not suitable for a lot of purposes and can cause confusion in
others. I would say that (ab)using enum to create constants of type int
has value and #define for the rest often makes more sense.

It also causes problems in header files, as it creates multiple
definitions for the same variable.

ie:
const int MY_FLAG = 0x0001;
vs.
#define MY_FLAG 0x0001

And don't forget that consts can't be used in places like switch/case.

Well, at least #2 just says "is preferred", rather than making it
sound like "always do it".

[...]

--
+-------------------------+--------------------+-----------------------+
| 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]

aa*****@gmail.com wrote:

>
On Apr 2, 4:15 pm, [e-mail] wrote:

[...]

7)avoid do/while use while and break instead.

[...]

13) if a macro contains more than one statement, use a do while
structure to enclose the macro

ex:- #define ABORT \
do{ \
puts("abort"); \
exit(8); \
}while(0);

Doesn't that violate rule 7? :-)

--
+-------------------------+--------------------+-----------------------+
| 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 Heathfield wrote:

>
Eric Sosman said:

aa*****@gmail.com wrote:

>

<snip>

12) the best indentation is 4 spaces

Does the author cite any research for this conclusion?
The only study I've ever seen -- and it was long ago and I
can no longer cite the source -- found that a two-space
indent was too narrow and four just a bit too wide; that
study's conclusion was that a three-space indent was most
likely "best."

The study was correct to identify that four space indent is too wide, but
erroneous in recommending three spaces because, obviously, it has to be a
power of two. One space is clearly too few, but two is just right.

[...]

Goldilocks and the Three Programmers.

"This indent is too wide."
"This indent is too narrow."
"This indent is just right!"

--
+-------------------------+--------------------+-----------------------+
| 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 Heathfield wrote:

>
Default User said:

aa*****@gmail.com wrote:

12) the best indentation is 4 spaces

Now, this is just insane. All right-thinking people know that the
correct answer is "three". Everything else is morally repugnant and/or
a terrorist plot.

Anyone who is concerned that you may be part of some kind of comp.lang.c
clique or cabal can now rest easy. No self-respecting cabalier would use a
three-space indent.

If you use an indent of three, then the terrorists have won. :-)

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

[Chris Thomasson]

<aa*****@gmail.comwrote in message
news:23**********************************@u10g2000 prn.googlegroups.com...

On Apr 2, 4:15 pm, [e-mail] wrote:

>On Apr 3, 12:58 am, Eric Sosman <[e-mail]:

[...]

13) if a macro contains more than one statement, use a do while
structure to enclose the macro

ex:- #define ABORT \
do{ \
puts("abort"); \
exit(8); \
}while(0);

Why not write the macro like:

#define ABORT(msg, status) (puts("msg"), exit(status))
and call it like:
ABORT("Ahh CRAP!", 666);
;^)

[lawrence.jones]

Walter Roberson <ro******@ibd.nrc-cnrc.gc.cawrote:

>
"usually" is not the same as "portably". There are real operating
systems (with real C compilers) for which exit(1) means something
specific to the operating system.

On VMS, for example, it means normal successful termination, which is
hardly the status you'd want for an error condition. That's why the
EXIT_SUCCESS and EXIT_FAILURE macros exist.

-Larry Jones

You can never really enjoy Sundays because in the back of your
mind you know you have to go to school the next day. -- Calvin