Hmm, isn't this backwards as style(9) requires tabs? Probably not worth swapping back at this point, but maybe avoid future style regressions?

In D49970#1141594, @jhb wrote:

Hmm, isn't this backwards as style(9) requires tabs? Probably not worth swapping back at this point, but maybe avoid future style regressions?

style(9) was changed somewhat recently to be OK with either, as long as you're consistent within a file.

In D49970#1141594, @jhb wrote:

Hmm, isn't this backwards as style(9) requires tabs? Probably not worth swapping back at this point, but maybe avoid future style regressions?

I thought that was OK:
"Put a single space or tab character between the #define and the macro name, but be consistent within a file."

There was a mix of tabs and spaces, with a slight majority of spaces (and using spaces is my personal preference as well, as TABs sometimes cause misalignment in diffs).

In D49970#1141597, @olce wrote:

In D49970#1141594, @jhb wrote:

Hmm, isn't this backwards as style(9) requires tabs? Probably not worth swapping back at this point, but maybe avoid future style regressions?

I thought that was OK:
"Put a single space or tab character between the #define and the macro name, but be consistent within a file."

There was a mix of tabs and spaces, with a slight majority of spaces (and using spaces is my personal preference as well, as TABs sometimes cause misalignment in diffs).

Originally it ways always tab. The change to permit spaces is recent, and older code from BSD should probably stay as it was to avoid churn. It seems the recent additions to this file just failed to follow the part about "match the existing style".

In D49970#1141669, @jhb wrote:

Originally it ways always tab. The change to permit spaces is recent, and older code from BSD should probably stay as it was to avoid churn. It seems the recent additions to this file just failed to follow the part about "match the existing style".

FWIW, I've added the corresponding commit to .git-blame-ignore-revs (as requested by markj@) so that it doesn't show up in git blame (provided git is so configured).

Would you like me to switch to all tabs instead?

In D49970#1141843, @olce wrote:

In D49970#1141669, @jhb wrote:

Originally it ways always tab. The change to permit spaces is recent, and older code from BSD should probably stay as it was to avoid churn. It seems the recent additions to this file just failed to follow the part about "match the existing style".

FWIW, I've added the corresponding commit to .git-blame-ignore-revs (as requested by markj@) so that it doesn't show up in git blame (provided git is so configured).

Would you like me to switch to all tabs instead?

No, it is not worth the churn. Just check match the existing style in the future was my only real original point.

In D49970#1142028, @jhb wrote:

In D49970#1141843, @olce wrote:

In D49970#1141669, @jhb wrote:

Originally it ways always tab. The change to permit spaces is recent, and older code from BSD should probably stay as it was to avoid churn. It seems the recent additions to this file just failed to follow the part about "match the existing style".

FWIW, I've added the corresponding commit to .git-blame-ignore-revs (as requested by markj@) so that it doesn't show up in git blame (provided git is so configured).

Would you like me to switch to all tabs instead?

No, it is not worth the churn. Just check match the existing style in the future was my only real original point.

We noticed years ago that this style was changing. We thought about changing style(9) to mandate one or the other and settled on "Put a single space or tab character between the #define and the macro name, but be consistent within a file." I agree with jhb: Don't churn unless it's only a couple (which this is not).

@imp @jhb I agree with both of you that we should minimize churn (and it's also common software development practice), and actually that was my intention when doing this. Prior commits of mine to sys/queue.h adding new macros were using TABs. I evaluated the number of #define followed by space and those followed by TABs, and for some reason flipped the conclusion (I've just checked now that TABs were indeed way more numerous than spaces). So that's a plain practical mistake, sorry about that.