To make this slightly more portable still I have removed the hard-coding
of gcc to make it just be cc. In modern systems this should be fine.
This involved updating the magic numbers by subtracting one from each,
making them (in the primary version 43 and 45 and 94 and 96 in the
alternate code for macOS) but since one of the purposes of the fixes of
code include making them work in more systems I have made it use cc as
it should work (gcc is most likely in all systems anyway but it seemed
like a better idea for 2023).
I previously noted in the thanks-for-fixes.md that the mode in fopen()
could remain 44+__FILE__ (though as noted above it's now 43) but that I
had changed it to "r". This was a mistake and it is now restored though
again it is now 43 not 44.
The FILE * which was renamed to G has been changed back to H. Observe
how there is a macro with the same name. There was actually no need to
change it.
I have restored some of the control codes in the C preprocessor
directives. Unfortunately that is only prior to the #define because some
systems will give an annoying warning otherwise. For instance fedora
linux shows:
schweikh1.c:6:8: warning: form feed in preprocessing directive
6 | #define
x
)
==
0
?__LINE__:0){O
=__LINE__;break;}
}
|
and possibly vertical tab too.
So although it would be ideal to have them closer to the original I deem
that preventing warnings that cannot be, for whatever reason, disabled.
The thanks-for-fixes.md was updated for these changes and now includes
more details on the fixes to match the rest of the other entries (though
some might also be lacking in details).
This was a fun one to figure out and fix!
The original code did not work; there were several things wrong with it
as below. The macOS version was even more complicated but also fun and
also described below.
The problem with the original was a bad call to freopen() where the arg
parameter was actually 5+__FILE__ when it should be "r" (though of
course it used to work fine). A call to fopen() had a similar mode:
44+__FILE__ though this actually did not seem to affect the output. But
it didn't work with macOS at all. The following is some of what I put in
the README.md so that one can see here too what was wrong. Spoilers for
the original entry (at least some spoilers) are here!
For this alternative version you will need the command line tools which
you can install like:
```sh
sudo xcode-select --install
```
This how it works: if you look at line 55 you see a funny command.
This goes for both versions. Now the key are two magic numbers, one on a
different line shortly below the string. In the original the numbers are,
respectively, 44 and 46. But how does this work? Well the string is:
"0gcc -ansi -E -dM -undef %s /usr/include/%s>r\0 ("
The first number means: the length starting from 0 up through the `>`. The
second number is the same starting point but up through the `\0` which is why
it's +2. Somehow it was basic intuition that made me figure out these
two numbers and a quick test confirmed it. But what happens if only the
first number is updated? Most of the output will be just `#define` by
itself; in the cases where there was text after that it was macros that
certainly were not defined. There might have been other errors as well.
This allows for opening the right files. The problem with the macOS is
/usr/include does not exist: instead it's
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include which is
why the different command line and the different numbers.
Cody Boone Ferguson