From d7c6c4717cdf1b7bd8550e37da66c52275c802f0 Mon Sep 17 00:00:00 2001
From: John Ericson <git@JohnEricson.me>
Date: Wed, 10 Jul 2019 11:54:47 -0400
Subject: Expunge #ifdef and #ifndef from the codebase

These are unexploded minds as far as the linter is concerned. I don't
want to hit in my MRs by mistake!

I did this with `sed`, and then rolled back some changes in the docs,
config.guess, and the linter itself.
---
 docs/coding-style.html | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

(limited to 'docs/coding-style.html')

diff --git a/docs/coding-style.html b/docs/coding-style.html
index 6be9263d97..dbf0f8729a 100644
--- a/docs/coding-style.html
+++ b/docs/coding-style.html
@@ -88,7 +88,7 @@ together implement a subsystem which is described by a single external
 header file).
 
 <p><li>We use the following GCC extensions, but surround them with
-<tt>#ifdef __GNUC__</tt>:
+<tt>#if defined(__GNUC__)</tt>:
 
 <ul>
 <li>Function attributes (mostly just <code>no_return</code> and
@@ -169,7 +169,7 @@ Instead, add an appropriate test to the configure.ac script and use
 the result of that test instead.
 
 <pre>
-  #ifdef HAVE_BSD_H
+  #if defined(HAVE_BSD_H)
   // use a BSD library
   #endif
 </pre>
@@ -192,10 +192,10 @@ than trying to find a bug which only shows up when running GHC on
 itself and doesn't manifest itself until 10 seconds after the actual
 cause of the problem.
 
-<p>We put all our debugging code inside <tt>#ifdef DEBUG</tt>.  The
+<p>We put all our debugging code inside <tt>#if defined(DEBUG)</tt>.  The
 general policy is we don't ship code with debugging checks and
 assertions in it, but we do run with those checks in place when
-developing and testing.  Anything inside <tt>#ifdef DEBUG</tt> should
+developing and testing.  Anything inside <tt>#if defined(DEBUG)</tt> should
 not slow down the code by more than a factor of 2.
 
 <p>We also have more expensive "sanity checking" code for hardcore
@@ -472,7 +472,7 @@ and by keeping it to 80 columns we can ensure that code looks OK on
 everyone's screen.  Long lines are hard to read, and a sign that the
 code needs to be restructured anyway.
 
-<li> When commenting out large chunks of code, use <code>#ifdef 0
+<li> When commenting out large chunks of code, use <code>#if defined(0)
 ... #endif</code> rather than <code>/* ... */</code> because C doesn't
 have nested comments.
 
-- 
cgit v1.2.1