Month: May 2008

Name That Code
OnePlusYou via Melkein Blogi

I’ve thrown together a little plugin which sorta anonymises the comments your WordPress blog receives. As you probably know, WordPress stores your commenters’ IP addresses to help you fight spam and other forms of abuse. Obviously, this also helps authorities in tracking down people for saying things that are forbidden in your society. If you believe in freedom of speech as vehemently as I do, you wouldn’t want them to be able to do that, and you certainly wouldn’t want to provide them with such unintended assistance in their hunt for people exercising freedom of expression.

This is where IP Address Eraser may help. It replaces the commenter’s IP address with a static address (by default, 127.0.0.1), so in order to track down the commenter, you would have to have access to your ISP’s web server logs. Note that through this route, your commenters might and probably will still be exposed, depending on your local laws regarding data retention by ISPs. That’s why I wouldn’t recommend that you advertise the fact that you’re using this plugin to your commenters, as they might be left with a false sense of security. If you want them to be truly safe (or at least, as safe as they can be), I suggest you recommend that they use Tor.

Also note that, again, depending on your local legislation, you might yourself be held accountable for your commenters’ opinions. Unfortunately, this is equally true even without the use of this plugin.

A technical note: Akismet, the default spam-fighting plugin employed by WordPress, takes a precedence in the order of filters employed to comments. I’ve not verified this, but I suspect that makes it use the comment poster’s IP address prior to it being erased by IP Address Eraser. I haven’t come across any tangible compatibility problems, so I’m hoping there are none, but please don’t take my word for it. I’m publishing this in the hopes that it’ll be useful, but there’s absolutely no warranty of any kind associated with this software.

Another, final techical note: What I’d really hope to have is the best of both worlds. It would be a plugin which wouldn’t erase the IP addresses right away, but after a set delay (say, 24 hours). This would put you in charge: to be able to use the data to tackle abuse when you deem necessary, yet leave you unworried about storing privacy-compromising data for far too long (forever, which is the WordPress default). Unfortunately my WordPress hacking skills are too lame to come up with such a plugin. If anybody takes a crack at it, I’d be interested to know. Please, feel free to use/abuse my plugin in doing so.

The pointers always get me when I try my hands at C. Now, I’m not dumber than most people, and the basic idea is pretty clear to me. But what trips my brain each time is the notation of declaration.

It’s not always illogical. After all, as K&C points out, int *ip is intended as a mnemonic; it says that the expression *ip is an int. Okay, that seems innocent enough, but in fact it’s a two-edged sword. What about when you’re declaring a pointer as a parameter for a function, then calling the function? Compare these two short programs below:

int foo(int i);
int main() {
 int j = 1;
 foo(j);
 return 0;
}

int foo(int i) {
  /* do something with i */
  return 0;
}

int foo(int *ip);
int main() {
  int j = 2;
  foo(&j);
  return 0;
}

int foo(int *ip) {
  /* do something with (*)ip */
  return 0;
}

For the first program, it’s easy to see that the parameter of foo(), i, is assigned the contents of j from main(): you’re in effect saying:

1. Let foo() have one parameter, i, of type int.
2. From main(), assign the value of j, also of type int, to i.

But for the second one, foo() has to be called with an address (a pointer), and yet the declaration, with the mnemonic notation in place, seems to call for an int:

1. Let foo() have one parameter, *ip, of type int.
2. From main(), assign the value of &j, of type… uhh… pointer, to… uhh… ???

This difficulty for me to grasp what type of a parameter foo() should be called with is due to the mnemonic notation in int *ip: when you have an int <something> as a parameter declaration, you expect to assign the parameter something that is of type int — not something that is a pointer to an int.

Now, if I give up the mnemonic and instead write the declaration as int* ip, the code translates to natural language quite fluidly:

int foo(int* ip);
int main() {
  int j = 2;
  foo(&j);
  return 0;
}

int foo(int* ip) {
  /* do something with (*)ip */
  return 0;
}

1. Let foo() have one parameter, ip, which is a pointer to an int.
2. From main(), assign the value of &j, also a pointer to an int, to ip.

Of course, this notation opens a whole new can of worms. Consider the following declaration:

int* i, j;

Is j a pointer now, or just an int? It’s way too open to misinterpretation to make this notation commendable despite the previous advantage in readability.

So I’m better off sticking to the mnemonic notation, and just trying to get my head around it. For that, I’m still in desperate need for an easy translation of such code into natural language.

Maybe the mnemonic is the root of the problem. It’s a really bad mnemonic because it almost always works, but then there’s (at least) this one case, where you’re better off not remembering it, because it screws up your logic if you do. So I should think of int *ip as ip is a pointer to an int and just forget about the fact that it resembles a declaration of an int called *ip.

For some time now, I’ve been using a Greasemonkey script to fix the most prevalent spelling mistakes on the Interwebs. Incorrect apostrophes are particularly painful, particularly prevalent and also particularly cumbersome to fix — the latter two being due to the complexity of the rules governing the use of apostrophes, obviously.

To tackle this, I’ve now adopted brute tactics: I simply replace each instance of it’s with an its. So far I must say it has felt less painful to encounter an its which should have been an it’s than it is the other way round.

Lähtökohta

Kotihakemistossani on arkisto.lha -niminen, LHAlla pakattu arkistotiedosto. Haluan purkaa sen sisällön, joten avaan tiedoston Pakettienkäsittelyohjelmalla.

Ongelma

Pakettienkäsittelyohjelma ei näytä arkistotiedoston sisältöä, vaan seuraavanlaisen virheilmoituksen:

Tiedoston "arkisto.lha" avaaminen epäonnistui

Arkistotyyppi ei ole tuettu.

Ongelman syy

Lha-pakettia ei ole asennettu.

Ratkaisu

Asennan Synaptic-pakettienhallinnassa lha-paketin. Sen jälkeen voin avata ja purkaa LHAlla pakatun arkistotiedoston Pakettienkäsittelyohjelmalla.

I have been (mis)using the title attribute of stylesheets to identify and grab a specific one for further processing with my JavaScript. I did this by comparing stylesheet.title with a specified title for my embedded stylesheet. However, as I didn’t really intend the titled stylesheet to be a preferred one, once I added a title to another stylesheet higher up in the document, my other one (being lower in the document hierarchy) stopped working.

This lead me to investigate the real significance of title, when applied to stylesheets. From what I’ve read, I have to say I’m somewhat confused by the logic with which the attribute has been named. After all, a title applied or left unapplied, to just about anything else on a web page is completely harmless, save perhaps for some decrease in the fine-tuning of your site’s accessibility. A title with relation to a stylesheet however, is so significant that HTML 4.01 categorizes stylesheets according to the presence or absence of a title. Although I don’t claim to know anything about writing specifications, I think they should have associated this categorization with the rel attribute, or at least name it differently so its significance wouldn’t get blurred by the use of title elsewhere. A stylesheet’s title‘s role would then reduced to accessory information similar to what it is when associated with, say, an a element.

Anyway, I’ve now come up with what I at least think is a better way of identifying my embedded stylesheet. I tag the style element with an id attribute, and then compare stylesheet.ownerNode.id with whatever the string I’ve tagged it with is. I’m not sure if it’s the correct way or even whether there is one, but it seems to be working and is valid. From the specification I gather there is no id attribute associated with style in HTML 4, so it probably wouldn’t validate there. This isn’t a problem for me, since I nearly always use XHTML (Strict).