lda	#alpha
alpha	equ	5

On pass 1, alpha isn't defined, but by pass two, we have its value?5.

With this code, however:

	lda	#alpha
alpha	equ	bravo
bravo	equ	5

alpha is undefined on line 1, and it remains undefined even on line 2 because we haven't defined bravo yet. Thus when we end pass 1, alpha is still undefined. That it took me two years to even stumble across this issue is a bit surprising to me. I just haven't written 6809 assembly code like this.

Can I fix this? If I add another pass, probably. If I don't want to add another pass ? I don't know. I would have to track expressions that aren't fully defined in pass 1, which could be a lot of work for an issue that might not come up all that often (if my own code is to go by). I mean, things can get quite pathological:

		lda	#Alpha
Alpha 		equ	Bravo+1
Bravo           equ	Charlie+1
Charlie		equ	Delta+1
Delta		equ	Echo+1
Echo		equ	Foxtrot+1
Foxtrot		equ	Golf+1
Golf		equ	Hotel+1
Hotel		equ	India+1
India		equ	Juliet+1
Juliet		equ	Kilo+1
Kilo		equ	Lima+1
Lima		equ	Mike+1
Mike		equ	November+1
November	equ	Oscar+1
Oscar		equ	Papa+1
Papa		equ	Quebec+1
Quebec		equ	Romeo+1
Romeo		equ	Sierra+1
Sierra		equ	Tango+1
Tango		equ	Uniform+1
Uniform		equ	Victor+1
Victor		equ	Whiskey+1
Whiskey		equ	Xray+1
Xray		equ	Yankee+1
Yankee		equ	Zulu+1
Zulu 		equ	1

lsawm (part of LWTools) does properly handle this pathological case but it does six passes, not two. The other 6809 assembler I have, an older one written back in the 90s, doesn't and issues deceptive error messages, so it's not like I'm the only one to not handle this properly.

As of now, I just issue an error and let the programmer deal with it.

We ended up with three kids showing up. In one group. At around 7:30 pm. At least we avoided carving a pumpkin this year, opting instead for my ceramic, pre-carved pumpkin.

The good news?

Bunny bought candy we like.

The bad news?

Bunny bought candy we like.

It won't go to waste, but it will go to our waist.

On my public server, I have the following bit of code in the configuration:

process = require("org.conman.process")

-- --------------------------------------------------------------------
-- process limits added because an earlier version of the code actually
-- crashed the server it was running on, due to resource exhaustion.
-- --------------------------------------------------------------------

process.limits.hard.cpu  = "10m" -- 10 minutes
process.limits.hard.core =  0    -- no core file
process.limits.hard.data = "20m" -- 20 MB

-- --------------------------------------------------------
-- We now resume our regularly scheduled config file
-- --------------------------------------------------------

I load a module to configure bits of the environment that mod_blog runs in. The configuration file on the development server does not have such code. So when I compiled the email notification program, the fact that I did not include the -rdynamic compiler option was not an issue when I ran my tests.

Yes, a case where there was a difference between development and production that allowed a bug to slip through. So I decided to dig a bit deeper. A few days ago I explained why I had such directives in my configuration file when I was asked why didn't I use Apache's RLimitMEM directive. I answered that the cause of adding the process limits happened pretty early in the use of mod_blog and that I didn't recall seeing such a directive in Apache at the time.

But I did get curious as to when Apache might have added the RLimitMEM directive. I started this site using Apache 1.3 (when that was the current version of Apache?I've been blogging for quite a long time) and I was thinking that the RLimitMEM directive may have been added around version 2.0. In my archives, I found a copy of Apache 1.3.9 and wouldn't you know it?RLimitMEM existed!

Sigh.

I could have avoided yesterday's issue had I only read a bit further into the Apache documentation back in the day.

It wasn't in mod_blog per se, but in the hook running after an entry has been added, and therein is the bug?the entry was successfully added, but the hook failed.

The hook program failed due to a compilation error that was only triggered when it ran. I took the email notification code from mod_blog and turned it into a program. I also linked to the bloging core of mod_blog to avoid having to duplicate the code to read the configuration (the email notification block is now ignored by mod_blog itself), and because the configuration format is Lua, a compiler option is needed to support Lua modules written in C?basically, -rdynamic to allow C-based Lua modules to call Lua functions (which I allow, and need, to support my particular configuration).

This is the root cause of the issue.

But in the meantime, because the hook failed to run, the script I use that uses the HTTP PUT method received a status of ?500 Internal Server Error,? the entry was stored, but none of the statically generated files (index.html and the various feed files) were generated, nor email sent.

Once I figured out what happened, it was easily remedied, but that still leaves the question of what should happen? I intended the add entry post-hook to handle situations like notifications, so in this case, if the hook fails, normal processing should proceed, but how to send back that the entry post-hook failed? Looking over the HTTP status codes, perhaps I could return a ?202 Accepted? when the entry post-hook fails, with some information about the failure. That could work.

I've removed features in the past, like no longer supporting ?ping servers? when it became clear it wasn't worth it, or automatically updating Linked­Tik­Face­My­Insta­Pin­Me­Gram­We­Tok­In­Book­Space­Trest when Insta­Pin­Tik­My­Linked­Face­Me­Trest­Book­Gram­We­In­Space­Tok changed how it works often enough to make it annoying for me to continue. But this time ? this time it's different. This is removing functionality that has existed in the code base since the beginning!

To make it easier to write entries, I had code within mod_blog to process the input?mostly what existed was to convert sequences like ``quoted'' to ?quoted? and ?...? to ???, but with an option to add <P> tags around logical paragraphs. But given that I now use my own markup language, I rarely used the web interface (like, I can count on my fingers the number of times I've used it and still have a few left over should give an indication of how little I use it) and the code just sat there, unused. So unused that in fixing one bug I introduced another bug in the code I fixed!

To recap, here's the original code:

char UrlDecodeChar(char **psrc)
{
  char *src;
  char  c;
  
  assert(psrc  != NULL);
  assert(*psrc != NULL);
  
  src = *psrc;
  c   = *src++;
  if (c == '+')
    c = ' ';
  else if (c == '%')
  {
    assert(isxdigit(*src));
    assert(isxdigit(*(src+1)));
    c    = ctohex(*src) * 16 + ctohex(*(src+1));
    src += 2;
  }
  *psrc = src;
  return(c);
}

and the ?fixed? version:

char UrlDecodeChar(char **psrc)
{
  char *src;
  char  c;
  
  assert(psrc  != NULL);
  assert(*psrc != NULL);
  
  src = *psrc;
  c   = *src++;
  if (c == '+')
    c = ' ';
  else if (c == '%')
  {
    if (!isxdigit(*src))   return '\0';
    if (!isxdigit(*src+1)) return '\0';
    c    = ctohex(*src) * 16 + ctohex(*(src+1));
    src += 2;
  }
  *psrc = src;
  return(c);
}

I don't fault you if you can't spot the bug. I only found it when testing the web interface to ensure it wasn't completely broken with the conversion code removed (instead it's now only mostly broken but that's an interesting case in and of itself and requires its own post). The bug is in this line of code:

if (!isxdigit(*src+1)) return '\0';

The issue is due to C's precedence rules and dereferencing rules. The code above is parsed as src[0] + 1 instead of the src[1] that I was intending. When I modified the function, changing the calls to assert() into actual code to return an error (I typed in the new code as that's faster than modifying the existing code) I ? kind of missed that.

Oh, who am I kidding? I totally missed that. But because I don't use the web interface this bug went unnoticed. Sigh.

For the record, I changed the code to read:

if (!isxdigit(src[0])) return '\0';
if (!isxdigit(src[1])) return '\0';
c    = ctohex(src[0]) * 16 + ctohex(src[1]);

Another long time feature I've removed is email notification. I added it early on where you could submit your email address to get notified of posts, but spammers and a lack of outside interest pretty much put the kibosh on that. As I still have three users of the email notification (one is me, one is Bunny, and one is one other person whom I'm not sure still reads the emails but they haven't bounced yet) I don't want to drop support completely, so now the email notifications are sent via the hook mechanism I added a few years ago.

In total, I removed over 3,000 lines of code from mod_blog. Granted, over 2,000 of them were in one function that was removed, but still, it's 3,000 lines of code I don't have to worry about any more.

Still, it's a bit scary to remove features that have been there for so long, and thus, a Halloween release.