About parsing the following if else condition

[parag_paul]

if ((type == vhpiCompInstStmtK) || (type == vhpiRootInstK))
if (reason) *reason = "Object is a scope";
else if (reason)
*reason = "object is not writable";


Here the else will be treated as the else for 2nd if or for the first
if.

I dont want to debug GCC now. But just that, need some braces to get
across it .

 

[jacob navia]

if ((type == vhpiCompInstStmtK) || (type == vhpiRootInstK))
if (reason) *reason = "Object is a scope";
else if (reason)
*reason = "object is not writable";


Here the else will be treated as the else for 2nd if or for the first
if.

I dont want to debug GCC now. But just that, need some braces to get
across it .

second

 

[Mark Bluemel]

if ((type == vhpiCompInstStmtK) || (type == vhpiRootInstK))
if (reason) *reason = "Object is a scope";
else if (reason)
*reason = "object is not writable";


Here the else will be treated as the else for 2nd if or for the first
if.

If you want to ask a question, it would be good to phrase your posting
as a question.

I assume your question is "which 'if' will the 'else' in the code above
correspond to?"

The 'else' will relate to the second 'if' so my reading of the code
could be expressed with indentation and braces as this :-

if ((type == vhpiCompInstStmtK) || (type == vhpiRootInstK)) {
if (reason) {
*reason = "Object is a scope";
} else if (reason) {
*reason = "object is not writable";
}
}

which is clearly not a useful piece of code.

I think your intent would be expressed as :-

if ((type == vhpiCompInstStmtK) || (type == vhpiRootInstK)) {
if (reason) {
*reason = "Object is a scope";
}
} else {
if (reason) {
*reason = "object is not writable";
}
}

Some of the braces could, naturally, be removed...

 

[keith]

if ((type == vhpiCompInstStmtK) || (type == vhpiRootInstK))
if (reason) *reason = "Object is a scope";
else if (reason)
*reason = "object is not writable";

Here the else will be treated as the else for 2nd if or for the first
if.

I dont want to debug GCC now. But just that, need some braces to get
across it .

This is an excellent example of why conditional statements without
braces are evil. As a maintenance programmer myself I would certainly
throw the above code back to the author at code review time. Run the
code through indent or similar, and you'll immediately see how the
compiler will parse it.

 

[parag_paul]

Run the code through indent

What is the meaning of that ?

@others
Thanks for the replies. It helped.

@Mark
Your second answer was my original intent. Thanks for that. It is
pretty much same for all compilers . Is it?

Like Java and other languages.

-Parag

 

[Joachim Schmitz]

What is the meaning of that ?

A tool that formats code, by identing it properly.

Bye, Jojo

 

[santosh]

What is the meaning of that ?

It is widely used and powerful C source formatting tool. See below:
<http://www.gnu.org/software/indent/>
<http://en.wikipedia.org/wiki/Indent_(Unix)>
<http://www.linuxmanpages.com/man1/indent.1.php>

<snip>

 

[Joachim Schmitz]

A tool that formats code, by identing it properly.

s/identing/indenting/

 

[Spiros Bousbouras]

What is the meaning of that ?

indent is a common Unix application which does automatic
indentation of a C programme. I would imagine it also
exists for other platforms.

@Mark
Your second answer was my original intent. Thanks for that. It is
pretty much same for all compilers . Is it?

It would have been nice if you had actually quoted this
"second answer". I assume you mean the following piece of
code by Mark Bluemel:

if ((type == vhpiCompInstStmtK) || (type == vhpiRootInstK))
{
if (reason) {
*reason = "Object is a scope";
}
} else {
if (reason) {
*reason = "object is not writable";
}
}

And yes it is the same for every compiler which conforms
to the C standard.

 

[Willem]

(e-mail address removed) wrote:
) @mark
) Your second answer was my original intent. Thanks for that. It is
) pretty much same for all compilers . Is it?

Required by the standard, AFAIK.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Old Wolf]

On Oct 4, 3:33 am, (e-mail address removed) wrote:

I have a book called "The Bytes Brothers", is your
email address anything to do with that?

This is an excellent example of why conditional statements without
braces are evil.

Not really, it is an example of bad indentation being evil. Cf:
if ((type == vhpiCompInstStmtK) || (type == vhpiRootInstK))
if (reason)
*reason = "Object is a scope";
else if (reason)
*reason = "object is not writable";

In fact, even better than both ideas is:
if ( reason )
{
if ( type == vhpiCompInstStmtK || type == vhpiRootInstK )
*reason = "Object is a scope";
else
*reason = "object is not writable";
}

 

[jaysome]

On Oct 4, 3:33 am, (e-mail address removed) wrote:

I have a book called "The Bytes Brothers", is your
email address anything to do with that?


Not really, it is an example of bad indentation being evil. Cf:
if ((type == vhpiCompInstStmtK) || (type == vhpiRootInstK))
if (reason)
*reason = "Object is a scope";
else if (reason)
*reason = "object is not writable";

In fact, even better than both ideas is:
if ( reason )
{
if ( type == vhpiCompInstStmtK || type == vhpiRootInstK )
*reason = "Object is a scope";
else
*reason = "object is not writable";
}

But the braces are only necessary if you heed keith's advice (to whom
you responded), right?

Better yet is:

if ( reason )
{
if ( (type == vhpiCompInstStmtK) || (type == vhpiRootInstK) )
{
/* do something */
}
else
{
/* do something else */
}
}

Consistency is an important aspect of quality software. Whether it's
consistently good or bad is an entirely different matter.

I think you and keith are both right. You are welcome to apply to work
for me anytime :^)

Both unconditional use of braces, as keith purported, and proper
indentation, as you purported, should be specified in a properly
formed coding standard. Both of these rules are primarily intended to
reduce and ideally eliminate the probability that the "maintenance"
person will screw up the software with his or her changes.

In a desktop "Paint" program this may seem like a trivial pursuit, but
in the world of safety critical software, such conventions or
practices or standards go a real, real long way towards achieving high
quality software. You can bet your life on it, if you're so inclined.

And maybe--just maybe--what's good for safety critical software is
also good for the desktop "Paint" program. Based on my experience, I'd
bet my life on that.

Best regards,

 

[gw7rib]

[Discussion of which "if" an "else" will match with]

@Mark
Your second answer was my original intent. Thanks for that. It is
pretty much same for all compilers . Is it?

Like Java and other languages.

Well, it's off topic here, but BCPL (a predecessor of C) got round the
problem by using "TEST" if there was an ELSE, and "IF" otherwise, so
you would have either:

IF expression THEN command1

or

TEST expression THEN command1 ELSE command2

Paul.

 

[parag_paul]

Well, it's off topic here, but BCPL (a predecessor of C) got round the
problem by using "TEST" if there was an ELSE, and "IF" otherwise, so
you would have either:

IF expression THEN command1

or

TEST expression THEN command1 ELSE command2

Paul.

Well, Paul,
But does TEST work this way,
TEST expression THE command1 ELSE TEST expression2 THEN command2 ELSE
command3

 

[Chris Dollin]

Well, Paul,
But does TEST work this way,
TEST expression THE command1 ELSE TEST expression2 THEN command2 ELSE
command3

Yes.

(Oxford PRG BCPL also had `test X ifso A ifnot B`, where the `ifso` and
`ifnot` clauses could appear in either order.)

 

[Army1987]

On Oct 4, 3:33 am, (e-mail address removed) wrote:

Not really, it is an example of bad indentation being evil. Cf:
if ((type == vhpiCompInstStmtK) || (type == vhpiRootInstK))
if (reason)
*reason = "Object is a scope";
else if (reason)
*reason = "object is not writable";

....which will immediately show that the code is wrong. The last if
branch will never be executed (unless reason is volatile, and is
being written from somewhere else in the time between the two
evaluation. But it's much more likely the programmer intended the
else to refer to the first if).

 

[David Thompson]

Both unconditional use of braces, as keith purported, and proper
indentation, as you purported, should be specified in a properly
formed coding standard. Both of these rules are primarily intended to
reduce and ideally eliminate the probability that the "maintenance"
person will screw up the software with his or her changes.

And increase the probability that other readers, like reviewers and
auditors, have the correct understanding they need.

In a desktop "Paint" program this may seem like a trivial pursuit, but
in the world of safety critical software, such conventions or
practices or standards go a real, real long way towards achieving high
quality software. You can bet your life on it, if you're so inclined.

But I have to disagree with this. Style rules like this do help move
you in the right direction, and are worth it for that reason; but they
do not by themselves get you anywhere near the destination -- and the
delusion that they do is itself a serious perhaps greater danger.

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

 

[Christopher Benson-Manica]

But I have to disagree with this. Style rules like this do help move
you in the right direction, and are worth it for that reason; but they
do not by themselves get you anywhere near the destination -- and the
delusion that they do is itself a serious perhaps greater danger.

I think I agree with that statement, assuming that you mean to point
out that

if( gets() != NULL )
/* do something */

and

if( gets() != NULL ) {
/* do something */
}

are equally wrong. Good style is probably necessary, but not
sufficient, for achieving software nirvana.