Software maintenance

[jacob navia]

Le 21/09/10 20:26, Seebs a écrit :

Because you might be splitting ALL lines of code, and you don't want
to have to parse them to see whether or not they're comments.

I have never seen \ at end of line used by anything but mechanical
code processors.


And since existing installations are using trivial conversions to handle
line length limits in C implementations, we're stuck with those existing.

Who is stuck?

Not me. People using this feature (I have never seen one) are stuck
then, unless they write a slightly more complicated software that cuts
lines at the right places.

Is there actually any such bug in the real world? I mean, outside of
completely contrived test programs, has there EVER been a program which
was actually broken because someone had a "//" comment which was
unintentionally continued by a \ at the end of the line?

I've never seen one.

I did. It took me several days at a customer site... That is why I hate
this misfeature. Customer complained that a syntax error was wrong and
my compiler was buggy. They wrote:

some_code (); // what is THIS???????/
}

The closing brace was ignored because the one line comment was extended
by an unintentional trigraph. The syntax error was 200 or so lines later.

 

[Seebs]

Who is stuck?

People who want other people to use their implementations.

Not me. People using this feature (I have never seen one) are stuck
then, unless they write a slightly more complicated software that cuts
lines at the right places.

No, they're fine. They just don't use your implementation, and all is
well. Since every other implementation in the world works for them,
no loss to them.

I did. It took me several days at a customer site... That is why I hate
this misfeature. Customer complained that a syntax error was wrong and
my compiler was buggy. They wrote:

some_code (); // what is THIS???????/
}

The closing brace was ignored because the one line comment was extended
by an unintentional trigraph. The syntax error was 200 or so lines later.

On the one hand, the trigraph thing is a real surprise.

On the other hand, how did this take several days to debug? Look at
the preprocessed output. Note the missing }. You've now narrowed it down
to two lines of code.

-s

 

[Alan Curry]

The "//" style comment (outside of a string literal) means that the rest of
the line is a comment. However, it appears that another exception is when
it appears within a "/* */" comment. For example:

char *pt = "one" /* "two" // "three" */ "four";

Comments don't nest.

In this case, the "//" is just another part of the comment, and you end up
with the string "onefour".

Also, starting a "/* */" after "//" doesn't work, as the "/*" is already
within a comment. This is a syntax error at "*/":

char *pt = "one" // "two" /* "three"
"four" */ "five";

Comments don't nest.

I can't see why anyone would try the first case, but I can imagine the
second case should someone use "//" to comment out a line which happens to
start a multi-line "/* */" comment.

Is it simply a matter of which one is encountered first, that determines
which type of comment is being handled? (ie: a "/*" after "//" on the same
line has no special meaning, and neither does a "//" within "/* */".)

Did you also notice that /* long comment containing /*short*/ comment */
doesn't work? Comments don't nest. That's the rule, and it neatly applies to
all 3 of these observations.

 

[John Bode]

Yes. Why would you want to split comments?

[...]

The above statement got me wondering about mixing "//" and "/* */" style
comments.  Specifically, mixing them on the same line.  I see how my
compiler is handling it, but I wonder if the Standard says anything on the
subject.

6.4.9 Comments

1 Except within a character constant, a string literal, or a comment,
the characters /* introduce a comment. The contents of such a
comment are examined only to identify multibyte characters and
to find the characters */ that terminate it.71)

2 Except within a character constant, a string literal, or a comment,
the characters // introduce a comment that includes all multibyte
characters up to, but not including, the next new-line character.
The contents of such a comment are examined only to identify
multibyte characters and to find the terminating new-line character.

3 EXAMPLE
"a//b" // four-character string literal
#include "//e" // undefined behavior
// */ // comment, not syntax error
f = g/**//h; // equivalent tof = g / h;
//\
i(); // part of a two-line comment
/\
/ j(); //part of a two-line comment
#define glue(x,y) x##y
glue(/,/) k(); // syntax error, not comment
/*//*/ l(); // equivalent to l();
m = n//**/o
+ p; // equivalent tom = n + p;

 

[Jorgen Grahn]

The only consenus is on // comments. Everything else some swear by,
others abominate.

If you mean people agree to like // comments, then I disagree. I use
C++ a lot, but I really find them quite useless (because I find really
short comments mostly useless, I guess).

It's also the number one reason I cannot compile people's C code as
strict C89.

Apart from that, I disagree with your description, but I agree with
the grandparent: it's going to be hard to have a team write in a
small subset of C++. Things mostly fit together: when you use A, you
see that you'd really want to use B, too.

Some things are easy to block automatically though. You can easily
make the build fail if you detect virtual inheritance, for example --
by looking for vptr:s in the symbol table.

/Jorgen

 

[jacob navia]

Le 21/09/10 22:06, Seebs a écrit :

People who want other people to use their implementations.


No, they're fine. They just don't use your implementation, and all is
well. Since every other implementation in the world works for them,
no loss to them.

Exactly. And if the standard is changed they will stay in C 89 forever.

On the one hand, the trigraph thing is a real surprise.

On the other hand, how did this take several days to debug? Look at
the preprocessed output. Note the missing }. You've now narrowed it down
to two lines of code.

-s

Sure. Once I told you what the bug WAS, it is easy to see. But the
syntax error appeared 200 lines later at the end of the procedure. I did
not see immediately that 200 lines before there was a trigraph...

Anyway, we have had this dicussion many times, and nothing has changed.
Trigraphs are still there for histerical reasons.

 

[Ian Collins]

If you mean people agree to like // comments, then I disagree. I use
C++ a lot, but I really find them quite useless (because I find really
short comments mostly useless, I guess).

It's also the number one reason I cannot compile people's C code as
strict C89.

Apart from that, I disagree with your description, but I agree with
the grandparent: it's going to be hard to have a team write in a
small subset of C++. Things mostly fit together: when you use A, you
see that you'd really want to use B, too.

No, it isn't. I've been there and done that. All it takes is an agreed
coding standard and good practice. All teams have that, don't they?

Some things are easy to block automatically though. You can easily
make the build fail if you detect virtual inheritance, for example --
by looking for vptr:s in the symbol table.

That won't work, but why is also off-topic here.

A lot of C++ compilers have options to disable specific language
features, which helps.

 

[Seebs]

Exactly. And if the standard is changed they will stay in C 89 forever.

Not necessarily. The thing about C99 or C1X is that, even if only a few
people implement them at first, everyone's likely to agree that these are
basically good features to have, and even compilers that don't claim to
fully conform to C99 are very likely to adopt C99 features.

Very few compilers are likely to adopt a non-standardized change to the
semantics of the preprocessor.

Sure. Once I told you what the bug WAS, it is easy to see. But the
syntax error appeared 200 lines later at the end of the procedure. I did
not see immediately that 200 lines before there was a trigraph...

Again, though, the first thing to do with a syntax error that doesn't make
sense is to go to the preprocessed source and check brace matching.
Braces and quotes and the like are the most common cause of weird syntax
errors in code that looks fine.

-s

 

[Ian Collins]

I did. It took me several days at a customer site... That is why I hate
this misfeature. Customer complained that a syntax error was wrong and
my compiler was buggy. They wrote:

some_code (); // what is THIS???????/
}

The closing brace was ignored because the one line comment was extended
by an unintentional trigraph. The syntax error was 200 or so lines later.

Nasty!

I tried this with a couple of compilers, one ignored the trigraph, but
gcc was on the ball:

gcc /tmp/u.c
/tmp/u.c:3:34: warning: trigraph ??/ ignored, use -trigraphs to enable

A good example of my first rule of debugging - compile with gcc as well
as your compiler of choice. Which is another good reason to avoid
non-standard compiler extensions.

 

[Seebs]

No, it isn't. I've been there and done that. All it takes is an agreed
coding standard and good practice. All teams have that, don't they?

Not really, no. From what I've seen, "good practice", for basically any
remotely coherent definition of the same, is the exception rather than the
rule. When I mention that all code has to be reviewed before checkin, people
sometimes sympathize with the horrible working conditions I must be living
with. The idea that the review process could be effective and beneficial
is, to many people, foreign -- it doesn't even *occur* to them.

As to coding standards, the coding standard we use is called, roughly,
When In Rome. Which is to say, since we are doing integration of hundreds
of packages which have different coding standards, you code to the standards
of the package you're working on as much as possible. The one thing I've
worked on that wasn't just working on someone else's stuff, I've been mostly
using something somewhere between Linux coding standards and BSD coding
standards.

In principle, I like the notion of coding standards, if they're any good
(it is well within the realm of possibility to make a coding standard
worse than no coding standard at all). And I like good practices. However,
many of the things people promote as "good practice" are some combination
of inapplicable, impractical, not a good fit for some developers, or
otherwise not things we can do. For instance, pair programming doesn't
seem like it'd do well for me -- I can't handle that much face-to-face
interaction with other people. Or for that matter, consider the paeans
written to the certain truth that, if we just flowcharted everything before
coding, there would be no bugs...

-s

 

[Ian Collins]

Not really, no. From what I've seen, "good practice", for basically any
remotely coherent definition of the same, is the exception rather than the
rule. When I mention that all code has to be reviewed before checkin, people
sometimes sympathize with the horrible working conditions I must be living
with. The idea that the review process could be effective and beneficial
is, to many people, foreign -- it doesn't even *occur* to them.

Maybe I'm too autocratic! I normally insist on a pre-checkin hook that
runs a "make test".

As to coding standards, the coding standard we use is called, roughly,
When In Rome. Which is to say, since we are doing integration of hundreds
of packages which have different coding standards, you code to the standards
of the package you're working on as much as possible. The one thing I've
worked on that wasn't just working on someone else's stuff, I've been mostly
using something somewhere between Linux coding standards and BSD coding
standards.

There is that, but a team can its own rules to its own code.

In principle, I like the notion of coding standards, if they're any good
(it is well within the realm of possibility to make a coding standard
worse than no coding standard at all). And I like good practices. However,
many of the things people promote as "good practice" are some combination
of inapplicable, impractical, not a good fit for some developers, or
otherwise not things we can do. For instance, pair programming doesn't
seem like it'd do well for me -- I can't handle that much face-to-face
interaction with other people. Or for that matter, consider the paeans
written to the certain truth that, if we just flowcharted everything before
coding, there would be no bugs...

Which is why each project team should define its own standards and
practices. I know this is not always possible in a a large
organisation, but often as not what management doesn't know, they don't
worry about!

 

[lawrence.jones]

I suggest that there's really no such thing as a "very small change"
when you're trying to modify the translation phase model.

There's no such thing as a "very small change" when you're trying to
modify the standard.

 

[Seebs]

Maybe I'm too autocratic! I normally insist on a pre-checkin hook that
runs a "make test".

That's not necessarily a bad idea. However, it can be hard to apply,
depending on the context of development. There's a big difference
between the way I work on things if I'm trying to design something for
long-term bulletproofing and the way I work on things if we need to
have something customers can be using tomorrow, even if it has a few
bugs left.

Which is why each project team should define its own standards and
practices. I know this is not always possible in a a large
organisation, but often as not what management doesn't know, they don't
worry about!

Heh.

I think there's a lot to be said for building better standards and
practices, and I've seen a lot of benefit come from pushing these things.
In the long run, I think most of them pay off, but there are often compelling
reasons to do things from a short-run perspective; if whether or not you
get a paycheck in May depends on whether you provide something which
meets the letter of the contract in April, you may not be able to do some
things that will dramatically improve your life from June through September...

I once had to get a web store working "in time for spring break". I had
about three weeks to do it in, and I had other activities that couldn't
be postponed, too. The resulting code was not particularly robust or
durable, and we've spent a lot of time agonizing over that since. But, if
I hadn't been willing to cut those corners, we wouldn't have spent any
time agonizing over that code, because there wouldn't have been a business
in place to care whether the web store was running...

Even at work, with our nicely stable and well-planned review process, a few
times a year, we have compelling reasons to check things in without review.
I've done that. Heck, I've checked in stuff that I could *prove* still
had at least one bug without review -- because it moved us from 90% failure
to 10% failure and allowed people to get work done while we searched for
the last bug.

-s

 

[robertwessel2]

Is there actually any such bug in the real world?  I mean, outside of
completely contrived test programs, has there EVER been a program which
was actually broken because someone had a "//" comment which was
unintentionally continued by a \ at the end of the line?

I've never seen one.

It's actually happened to me. I was testing a change, and I
duplicated and commented out a line, and then changed the duplicate
(which was now just after the commented out original line). I didn't
notice that the line I duplicated had a continuation, and the
continuations from the now commented original line, elided the entire
statement.

It wasn't that hard to find, but it was definitely a detour for a few
minutes.

I have to agree through, that the C line continuation behavior is
broken with regards to the no-whitespace rule after the backslash.
But then I *really* dislike significant whitespace in a programming
language. I can't help dealing with that in make files (seriously,
tabs vs. spaces means something? what idiot thought that up?), but I
can refuse to program in Python.

 

[Ian Collins]

I have to agree through, that the C line continuation behavior is
broken with regards to the no-whitespace rule after the backslash.
But then I *really* dislike significant whitespace in a programming
language. I can't help dealing with that in make files (seriously,
tabs vs. spaces means something? what idiot thought that up?), but I
can refuse to program in Python.

Or use make?

 

[Seebs]

I can't help dealing with that in make files (seriously,
tabs vs. spaces means something? what idiot thought that up?), but I
can refuse to program in Python.

I can't. So far, my impression is: For the most part, it's harmless,
but if you ever do have an indentation thing Go Wrong (say, tabs get
inserted somehow, or something gets lost in email), you're screwed.

I agree with the basic complaint that, in C, if you see:

if (foo)
bar;
else
baz;
quux;

you cannot tell whether quux is supposed to be in the else clause or not.

However, I don't think it's any better in Python. In python:

if foo:
bar
else:
baz
quux

The good news is, you are now totally sure that the second line is part of
the else clause. The bad news is, that doesn't mean it was supposed to
be.

At least in C you have a warning that the writer was probably confused.

-s

 

[Felix Palmen]

Not really, no. From what I've seen, "good practice", for basically any
remotely coherent definition of the same, is the exception rather than the
rule. When I mention that all code has to be reviewed before checkin, people
sometimes sympathize with the horrible working conditions I must be living
with. The idea that the review process could be effective and beneficial
is, to many people, foreign -- it doesn't even *occur* to them.

As long as you don't add "into the trunk / main branch", I'd agree with
them. Of course, the main branch should always be properly reviewed and
functional, but in all other development branches, checking in any small
subset regardless of broken code, but with descriptive log messages,
should be considered "good practice", as it helps a lot with tracking
down bugs and reverting an individual not properly thought of change
later.

Regards,
Felix

 

[Seebs]

As long as you don't add "into the trunk / main branch", I'd agree with
them. Of course, the main branch should always be properly reviewed and
functional, but in all other development branches, checking in any small
subset regardless of broken code, but with descriptive log messages,
should be considered "good practice", as it helps a lot with tracking
down bugs and reverting an individual not properly thought of change
later.

Interesting point. I think most of that happens in local git trees; the
only stuff that gets pushed anywhere else is usually stuff that's expected
to be used by everyone else.

-s

 

[Tim Streater]

Or use make?

I was put off for *years* building any programs under OS X because I
assumed I'd get to get to grips with f***ing make. Then I accidentally
double-clicked a .h file and up popped Xcode - the civilised way to
build a program.

 

[jacob navia]

Le 22/09/10 00:54, (e-mail address removed) a écrit :

There's no such thing as a "very small change" when you're trying to
modify the standard.

I know. Leave like it is, do not change anything since it would break
existing code. Leave existing bugs since they are known and only affect
new users, since the old ones know all the tricks.

This kind of reasoning is known, and proven false for decades, but it
will be proposed by the same people again and again, and this discussion
has been done a hundred of times.

The examples of Thompson are easy to solve. Whitespace after a backslash
is not ignored NOW and if we change line splicing behavior concerning
comments it should stay the same as it is now. The line splicing AFTER
comments parsing has nothing to do with all OTHERS usages of splicing as
Mr Thompson mistakenly proposes. All his examples are NOT any problem
with line splicing AFTER comment parsing.

Concerning strings, apparently Mr Thompson did not receive my earlier
explanation: Within a string, a backslash followed by CR should join the
two lines, as it does now. This is a slight change in the syntax of
strings that gets a new escape sequence. Nothing really complex.