A situation

[nrk]

Thanks Captain Obvious........

You'd be surprised by how many people find that completely non-obvious (is
there such a word?). Surf through some of the current threads in this
group for a sample. Here's an argument that anyone can use effectively in
discussing style non-issues (and possibly for other such useless subjective
discussions as well):

This style is best, because I follow it.

-nrk.

 

[James Beck]

You'd be surprised by how many people find that completely non-obvious (is
there such a word?). Surf through some of the current threads in this
group for a sample. Here's an argument that anyone can use effectively in
discussing style non-issues (and possibly for other such useless subjective
discussions as well):

This style is best, because I follow it.

-nrk.

I have changed my style so much over the last 20 years or so I
can't even look at my early work and I'm sure the way I write code would
be horrifying to some one that writes for a feature rich platform and
just because I do something one way definitely does not make it the
right way, AND I can think of some hardware I worked with that just
about required the use of multiple returns when dealing with some
hardware errors. When you are running at 4MHz you can't assume that
code and hardware respond infinitely fast. I think in the world of
multiple GHz PCs programmers get a bit spoiled (and arrogant).

Jim

 

[August Derleth]

signed char ....

???

Why not? A char is simply an integral type of a certain width (defined
by the CHAR_BITS constant in the standard header limits.h, and narrower
than the width of an int except in pathological cases). It can be signed
or unsigned, just like an int, and to make sure it's unsigned you need
to add a type qualifier to the delcaration.

C doesn't specify /what/ you must do with the types it gives you, it
simply gives them to you. Remember: C is not Pascal.

 

[pete]

Why not? A char is simply an integral type of a certain width (defined
by the CHAR_BITS constant in the standard header limits.h,
and narrower than the width of an int except in pathological cases).
It can be signed or unsigned, just like an int,
and to make sure it's unsigned you need
to add a type qualifier to the delcaration.

C doesn't specify /what/ you must do with the types it gives you, it
simply gives them to you. Remember: C is not Pascal.

"const" and "volatile" are qualifiers.
Whether (char) is signed like (signed char) is,
or unsigned like (unsigned char) is, is implementation defined.
They are considered to be three distinct types.

 

[Randy Howard]

Why not? A char is simply an integral type of a certain width (defined
by the CHAR_BITS constant in the standard header limits.h, and narrower
than the width of an int except in pathological cases).

Of course. The point I meant to make, but obviously wasn't clear about,
was why not just use signed char instead of adding a comment about making
an assumption on the type of unadorned char?

Remember: C is not Pascal.

Thank you so much for that reminder, I had almost forgotten.

 

[Zoran Cutura]

just because I do something one way definitely does not make it the
right way, AND I can think of some hardware I worked with that just
about required the use of multiple returns when dealing with some
hardware errors. When you are running at 4MHz you can't assume that
code and hardware respond infinitely fast. I think in the world of
multiple GHz PCs programmers get a bit spoiled (and arrogant).

I'm not saying that multiple returns are bad (I use 'em when I think
they are appropriate and I don't where I think they are not), but I
don't see a connection between Real-Time and multiple returns. I don't
believe that it speeds up your programs and though 4 MHz sounds somewhat
slow it is not the slowest device I could think of and I just cannot
think about a case where

if(test) {
return;
} else {
}
return;

would be any faster than

if(test) {
} else {
}
return;

At least it would be optimized in one or the other way by the compiler.

 

[James Beck]

I'm not saying that multiple returns are bad (I use 'em when I think
they are appropriate and I don't where I think they are not), but I
don't see a connection between Real-Time and multiple returns. I don't
believe that it speeds up your programs and though 4 MHz sounds somewhat
slow it is not the slowest device I could think of and I just cannot
think about a case where

if(test) {
return;
} else {
}
return;

would be any faster than

if(test) {
} else {
}
return;

At least it would be optimized in one or the other way by the compiler.

Well, I don't think that having returns sprinkled throughout a function
helps its readability. In fact, even with well documented code I have
spent inordinate amounts of time making mods that would have been much
easier to perform had the function not had multiple exit points. If you
KNOW that the code runs to the bottom of the function and then returns I
find it much easier to read during some far distant modification
session.

Jim

 

[CBFalconer]

.... snip ...
Well, I don't think that having returns sprinkled throughout a
function helps its readability. In fact, even with well
documented code I have spent inordinate amounts of time making
mods that would have been much easier to perform had the
function not had multiple exit points. If you KNOW that the
code runs to the bottom of the function and then returns I
find it much easier to read during some far distant
modification session.

Nor do the multiple returns necessarily improve efficiency and/or
code size. In fact I believe (on the basis of some cursory looks)
that GCC for the x86 -O3 or -O2 reorganizes the control flow to
place the actual return at the end in all cases.

So my attitude, based on ease of reading alone, is one exit, with
the sole exception of entry validation tests. Something like:

if (foo) return 1;
else if (bar) return 2;
else {
/* the meat */
}
return foobar;

 

[Nick]

James Beck wrote:


... snip ...



Nor do the multiple returns necessarily improve efficiency and/or
code size. In fact I believe (on the basis of some cursory looks)
that GCC for the x86 -O3 or -O2 reorganizes the control flow to
place the actual return at the end in all cases.

So my attitude, based on ease of reading alone, is one exit, with
the sole exception of entry validation tests. Something like:

if (foo) return 1;
else if (bar) return 2;
else {
/* the meat */
}
return foobar;

A well thought out exception to the rule. If it fails early, return
early, and it is obvious why you
have returned the value you did.

In device drivers I have seen and written, the common practice was to put
all of these things up front, e.g.

if(some_condition) return ENODEV;
if(some_other_condition /*based on the input parameters*/) return EFAULT;
etc.

Then, finally, the "meat" when all error checks on the input had been
performed.

I find this more readable than:

retval = 0;
if(some_condition) retval = ENODEV;
if(some_other_condition) retval = EFAULT;
....
if (retval == 0) {
/*meat*/
retval = whatever;
}
return retval;

but your preferences may vary.