Landon Curt Noll
7712db4a17
Given how problematic leading tabs in markdown files can be,
we have expanded all leading tabs in markdown files by:
```sh
find * -type f -name '*.md' -print |
while read -r file; do
rm -f "$file.tmp" ;
expand < "$file" > "$file.tmp" ;
mv -f -v "$file.tmp" "$file" ;
done
```
Given the previous changes to `bin/pandoc-wrapper.sh` and other recent
commits and recent pull requests, the were were **NO** changes to
any HTML files. This is a **good thing** as the expression goes.
No there are no leading tabs in any markdown files.
A check to catch any re-introduction of leading tabs
into any markdown file is on the way.
BTW: We do not have anything against leading tabs in files,
even though we have had to deal with their impact on forming
HTML from markdown files (as well as the calc source code).
It is just that this is one of those cases where tabs conflict
(sometimes caused by people wanting to change the classic
8-space tab model) with a desired outcome.
Perform `make www` to perform the above and test under macOS.
To build:
make
NOTE: the use of the C compiler optimiser was disabled and -g was enabled for
this entry because it is SUPPOSED to crash and it needs debugging symbols.
Bugs and (Mis)features:
The current status of this entry is:
STATUS: INABIAF - please DO NOT fix
For more detailed information see 2019/endoh in bugs.html.
To use:
./prog
Try:
If you have gdb(1) installed:
./try.sh
Note that in macOS installing gdb(1) takes multiple steps - it's not just a
matter of installing gdb(1) and that's that. The try.sh script has
only been tested with linux.
You might also wish to try:
gdb ./prog || lldb ./prog
and then type in r (to run program) and then bt (for backtrace).
Judges' remarks:
The purpose of this program is to crash. You'll want to have memorized man 7 ascii when debugging it to reveal its purpose.
Author's remarks:
backtrace quine:
Compile prog.c with no optimization.
cc -g -O0 -o prog prog.c
Then, run it. You will see a segmentation fault.
$ ./prog
Segmentation fault (core dumped)
Let's debug. As usual, run it under gdb.
$ gdb ./prog
(gdb) run
Starting program: /home/.../prog
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
Okay, check the backtrace.
(gdb) backtrace
#0 0x0000000000000000 in ?? ()
#1 0x0000555555555201 in x23 () at prog.c:35
#2 0x000055555555571a in x64 () at prog.c:100
#3 0x0000555555555747 in x65 () at prog.c:101
#4 0x0000555555555774 in x66 () at prog.c:102
#5 0x00005555555557ce in x69 () at prog.c:105
#6 0x0000555555555828 in x6e () at prog.c:110
#7 0x0000555555555747 in x65 () at prog.c:101
...
See the line numbers and lookup the ASCII table.
35 = '#'
100 = 'd'
101 = 'e'
102 = 'f'
105 = 'i'
110 = 'n'
101 = 'e'
...
One more thing:
The original program can be used as a GDB command file.
gdb -q -x prog.c ./prog | cat
Reading symbols from ./prog...done.
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
#0 0x0000000000000000 in ?? ()
#1 0x0000555555555201 in x23 () at prog.c:35
#2 0x000055555555571a in x64 () at prog.c:100
#3 0x0000555555555747 in x65 () at prog.c:101
#4 0x0000555555555774 in x66 () at prog.c:102
#5 0x00005555555557ce in x69 () at prog.c:105
#6 0x0000555555555828 in x6e () at prog.c:110
#7 0x0000555555555747 in x65 () at prog.c:101
...
By using this, you can confirm that it is actually a quine.
gdb -q -x prog.c ./prog | sed -n -r 's/#.*:([0-9]+)/\1/p' | awk '{printf "%c",$1}' > prog2.c
diff prog.c prog2.c