assert.h: style(9): Space after #define, between #endif and comment

[olce]

Summary

style(9) still allows TAB after #define but this is a historical
artifact and by far the minority of uses cases. Going forward, we would
like to promote the use of a single space, as it allows alignment to
survive line prefixing (such as in diffs).

style(9) also has prescribed a single space between '#else' or '#endif'
and a comment recalling the guard since 2002.

So, commit 157c184689ea ("assert.h: Remove leading tabs for whitespace
consistency") was good, and in line with rules about whitespace changes
(since the file was heavily modified by surrounding commits).

This commit is thus basically a revert of 439710cf003b ("assert.h:
Revert "Remove leading tabs for whitespace consistency"), which extended
replacing spaces with TABs in the code introduced in the meantime (after
commit 157c184689ea).

Fixes: 439710cf003b ("assert.h: Revert "Remove leading tabs for whitespace consistency")

[fuz]

I don't have strong opinions about this.

[olce]

If there are no objections in a few days, I'll commit it.

[kib]

Going forward, we would
like to promote the use of a single space, as it allows alignment to
survive line prefixing (such as in diffs).

I do not agree. 'We' qualifier is too broad there. BSD has the history of using the 'tab', as I understand, going back to real Bell labs Research Unix.

[imp]

In D57391#1315057, @kib wrote:

Going forward, we would
like to promote the use of a single space, as it allows alignment to
survive line prefixing (such as in diffs).

I do not agree. 'We' qualifier is too broad there. BSD has the history of using the 'tab', as I understand, going back to real Bell labs Research Unix.

So we, the FreeBSD project relaxed this rule in style(9) due to wide-spread non-compliance with the hard tab rule. This practice does originate at bell labs. It's present in the earliest C artifacts we have from Bell Labs, and the practice continues through v7. Berkeley observed this, by and large in 4BSD, but by 4,3BSD there were a number of places in the tree that were non-compliant with this. I've not done a deep dive into all the revs of FreeBSD, but have noticed this has become more non-compliant.

I think that the specific need that drove the bell labs folks have aged out. It doesn't matter that much anymore. So I agree we're transitioning to spaces for new code, which this clearly is. I'm mostly agnostic, but I lean towards this is fine.

[olce]

In D57391#1315144, @imp wrote:

I think that the specific need that drove the bell labs folks have aged out. It doesn't matter that much anymore. So I agree we're transitioning to spaces for new code, which this clearly is. I'm mostly agnostic, but I lean towards this is fine.

That's exactly my thinking. TABs are not forbidden, and we are not going to do a big sweep to remove them. But let's move to spaces as much as possible, as I really don't see any advantages of TABs now (please correct me if I'm wrong) and there is a clear drawback (breaks alignment in diffs, as long as this is mixed with spaces, which we have in similar places).

It's a bit of a mistery to me that TABs were chosen to fit these places back in the day. It might have been because editors could not align intelligently and TABs were used as well with other preprocessor directives.

In D57391#1315057, @kib wrote:

'We' qualifier is too broad there.

Sorry, I was perhaps a bit fast here (more of a royal "we" than a real poll at that point), actually I expected to build some consensus around this as really I thought it quite uncontroversial (and still think it is). imp@ dealt with the historical aspect. If there are non-historical reasons to continue using TABs, I'd like to know about them.