Software maintenance

[Keith Thompson]

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

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.

Sarcasm *really* isn't helpful, jacob.

Breaking existing code is a real concern, you cannot reasonably
ignore it.

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.

What exactly has been "proven false"? Seemingly simple changes to
standards really do cause problems.

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.

Yes, I did see your earlier explanation. In your later message,
you said that all that was needed was the "simple" change of
performing line-splicing after comment recognition. If you're
seriously proposing a change to the standard, it's going to be
difficult to keep track if the various pieces of it are scattered
across different articles.

I asked several specific questions, starting with whether you intend to
swap translation phases 2 and 3. You didn't directly address them.

You've said (I think) that the overall idea of the translation phase
model is ok. How *exactly* does your proposed change fit into it?

If you can give us an unambiguous idea of what you're proposing,
then we can determine which corner cases are affected and how.
(And *maybe* we'll conclude that they're not so important that they
prevent adoption of your proposal.)

 

[Keith Thompson]

But, my mind comes up with all sorts of weird "what if" questions when
reading threads such as this, even though I would probably never use code
like this...

What does the standard say of "\" at the end of a line with a "//" comment?
My compiler gives a warning, but "continues" the comment onto the next line:

char *pt = "This is a line" // comment \
"(foo)" \
"(bar)"
"(baz)";

I get this warning twice:

single-line comment contains line-continuation character

and the string contains "This is a line(baz)".

Ditto for gcc (with "-Wall"), though the warning is worded

warning: multiline `//' comment

I know that compilers are allowed to give any "warnings" that they like (for
example, "warning: 'int i;' is cliche" would be perfectly legal), but
"inquiring minds want to know".

Line-splicing is handled in translation phase 2; comments are recognized
in phase 3.

In phase 2, the first three physical lines are spliced into a single
logical line, yielding (modulo white-space):

char *pt = "This is a line" // comment "(foo)" "(bar)"
"(baz)";

After comments are recognized and replaced by white-space in phase 3,
we have:

char *pt = "This is a line"
"(baz)";

It was kind of gcc to provide a warning, but of course it's not
required to do so.

 

[jacob navia]

Le 22/09/10 17:17, Keith Thompson a écrit :

Breaking existing code is a real concern, you cannot reasonably
ignore it.

Yes, but I ignore it in this case.

The problems that would arise if we join lines after throwing out
comments would be minimal.

Yes, I did see your earlier explanation. In your later message,
you said that all that was needed was the "simple" change of
performing line-splicing after comment recognition. If you're
seriously proposing a change to the standard, it's going to be
difficult to keep track if the various pieces of it are scattered
across different articles.

I asked several specific questions, starting with whether you intend to
swap translation phases 2 and 3. You didn't directly address them.

No, just the line splicing part. The rest of phase 2 should stay as it
is. Actually everything should stay as it is except that line splicing
should be done after comment processing.

You've said (I think) that the overall idea of the translation phase
model is ok. How *exactly* does your proposed change fit into it?

Line splicing goes into the same phase as comment processing, just right
after it.

If you can give us an unambiguous idea of what you're proposing,
then we can determine which corner cases are affected and how.
(And *maybe* we'll conclude that they're not so important that they
prevent adoption of your proposal.)

I am working in the container library now. This proposal is not very
important anyway. My position against trigraphs and all that crap is
known, and I do not feel like starting any of those discussions again.

 

[Keith Thompson]

Le 22/09/10 17:17, Keith Thompson a écrit : [...]

I asked several specific questions, starting with whether you intend to
swap translation phases 2 and 3. You didn't directly address them.

No, just the line splicing part. The rest of phase 2 should stay as it
is. Actually everything should stay as it is except that line splicing
should be done after comment processing.

Line splicing is pretty much all that happens in phase 2. So you'd
combine phases 2 and 3 into a single phase, with everything that's
currently in phase 2 inserted into phase 3 after "Each comment is
replaced by one space character."?

Line splicing goes into the same phase as comment processing, just right
after it.


I am working in the container library now. This proposal is not very
important anyway. My position against trigraphs and all that crap is
known, and I do not feel like starting any of those discussions again.

Fair enough.

Of course, without a concrete proposal (ideally in the form of
revised wording for the Standard), this won't go anywhere (unless
someone else picks it up).

That's ok; it's a reasonably interesting discussion even if it
doesn't result in a change to the Standard.

 

[Jorgen Grahn]

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.

Depends (as you probably suspect) a lot on the tools you use. It's
good when you get a record "the code looked like /this/, I suggested
/these/ changes, he kept those changes and also fixed /this/ other
thing."

/Jorgen

 

[Jorgen Grahn]

On 09/22/10 10:08 AM, Jorgen Grahn wrote: ....

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?

I don't think I've ever seen a team with a (good) agreed coding
standard and good practice ... just individuals trying to keep the
code quality from decreasing.

/Jorgen

 

[Malcolm McLean]

I don't think I've ever seen a team with a (good) agreed coding
standard and good practice ... just individuals trying to keep the
code quality from decreasing.

The pub test tells you whether or not you have a functional team.

From "lets go to the pub" time how long it takes for everyone to be in
the pub.
Five minutes, and you've got a good team. Half an hour and either no-
one cares or the team is full of office politics. If they don't arrive
in the pub at all it's "good team players with a passion for total
quality consumer service"

 

[Nick Keighley]

no, not all

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

not the same as a review