object file size is reduced after build

[Richard]

Ah, but the debugger never crosses my mind, because I virtually
never use them. If it is of real use to the end user, he is quite
welcome to insert a <return> before the goo call and recompile.

My objective is to make the source code readable and sensible. It

Which, if you read the comments, you have failed to do.

 

[James Kuyper]

Which, if you read the comments, you have failed to do.

He read the comments; he just has his own inscrutable sense of what
makes code readable which is different from yours and mine.

 

[Randy Howard]

I'll concede Richard Heathfield's point that the complexity of C code
can probably be measured somewhat more accurately by a count of
semicolons than by a count of newline characters, which is obviously
equally easy to calculate (but applicable only to C code). However, it's
only a small increment in accuracy. The only way to significantly
improve on LOC as a measure requires a much more complicated algorithm.

Even a pathetically bad C programmer (like one that thinks "C/C++" is a
language) could come up with

/*
* int some_function(void)
*
* ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
* Calculate something, taking no arguments, and return 0 on
* success, and 1 on failure.
* ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
*/


So, the measurement would either be completely worthless, and open to
abuse just like the newline one, or much smarter in how it measures.

Even so, the "complexity" of the code is not, imo, directly related to
the number of ; chars as actual ends of C code 'lines', as complexity
is far more than just the amount of it, but what each line contains.

 

[Randy Howard]

Well, duh, you don't TELL cow-orkers about it.

The first rule of Code Club, is that we don't talk about Code Club.

 

[santosh]

Even a pathetically bad C programmer (like one that thinks "C/C++" is
a language) could come up with

/*
* int some_function(void)
*
* ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
* Calculate something, taking no arguments, and return 0 on
* success, and 1 on failure.
* ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
*/


So, the measurement would either be completely worthless, and open to
abuse just like the newline one, or much smarter in how it measures.

Presumably comments would be skipped.

 

[Gordon Burditt]

/*

Presumably comments would be skipped.

#include <stdio.h>

int main(void)
{
printf("Hello, world\n");;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
return 0;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
}

My patch to this hole would be "run the source through GNU indent
with a specified and fixed list of options, remove comments, remove
empty lines and lines consisting only of whitespace, then count
lines. Since GNU indent knows how to parse a good portion of C,
this is getting a lot more complicated.

An immediate problem with this so-called "fix" is that you can insert
goto X; X:
before any statement that doesn't already have a label on it, provided
that you generate labels that aren't already in use. And you can do it
repeatedly.

Other things you can insert before a statement:

while (0);
if (VARIABLE) { ; } else { ; }
(where VARIABLE is declared, in scope, and of integer or pointer type).
do { ; } while (0);
for (;0 { ; }

It's going to take fairly complicated logic (of the same level as a compiler
optimizer) to determine that code like:

int n;

if(n) { goto k22571; k22571: for(;0 { while(0); } } else { do { ; } while (0); }

is completely useless.

 

[Richard Heathfield]

Randy Howard said:

I'll concede Richard Heathfield's point that the complexity of C code
can probably be measured somewhat more accurately by a count of
semicolons [...]

Even a pathetically bad C programmer (like one that thinks "C/C++" is a
language) could come up with

/*
* int some_function(void)
*
* ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
* Calculate something, taking no arguments, and return 0 on
* success, and 1 on failure.
* ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
*/

Presumably you missed the bit where I said the file should be
pre-processed. In any case, the only sensible use for complexity metrics
is for identifying bits of the code that need simplifying because the bozo
programmer was making the code too complicated - so the above is
self-defeating.

Even so, the "complexity" of the code is not, imo, directly related to
the number of ; chars as actual ends of C code 'lines', as complexity
is far more than just the amount of it, but what each line contains.

Yes, we know that. Do you really think we don't?