Category: Uncategorized

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).

Lähtökohta

Tulostimeni on USB-liitännän kautta tietokoneeseeni kytketty Epson Stylux C42UX. Olen ladannut siihen paperia, ja käynnistänyt sen.
Lataan Näytön lukitseminen pikanäppäimellä -ratkaisumerkinnän Firefox-selaimeen. Haluan tulostaa merkinnän, joten valitsen Firefoxin Tiedosto-valikosta kohdan Tulosta.... Valitsen avautuvan ikkunan tulostinlistasta tulostimeni (Stylus_C42), ja määrittelen tulostusalueeksi pelkästään ensimmäisen sivun valitsemalla Tulosta sivut -otsikon alla olevan Alue-kohdan käyttöönotetuksi, ja kirjoittamalla siihen liittyvään tekstikenttään 1-1. Lopuksi painan ikkunan alalaidassa olevaa Tulosta-nappia.

Ongelma

Sivu ei tulostu. Sen sijaan näytölle ilmestyy otsikoton ikkuna, joka sisältää seuraavanlaisen virheilmoituksen:

XML-jäsennysvirhe: virhe käsiteltäessä ulkoista olioviittausta
URL: chrome://global/content/printProgress.xul
Rivinumero 6, sarake 67:<!DOCTYPE window SYSTEM "chrome://global/locale/printProgress.dtd">
------------------------------------------------------------------^

Ongelman syy

Firefoxin suomennokset sisältävässä kielipaketissa on ohjelmavirhe, jonka takia tulostaminen ei toimi Firefoxissa.

Ratkaisu

Ratkaisua ei vielä ole. Ongelman voi kiertää ottamalla XULRunnerin kielipaketin pois käytöstä seuraavasti:

1. Valitsen Firefoxin Työkalut-valikosta kohdan Lisäosat.
2. Valitsen avautuvasta Lisäosat-ikkunasta Kielet-välilehden.
3. Valitsen Kielet-välilehdellä olevalta listalta Xulrunner (fi) -kohdan, ja painan siihen liittyvää Poista käytöstä -nappia.
4. Painan Lisäosat-ikkunan yläosaan ilmestyvää Käynnistä Firefox uudelleen -nappia.

Kun tämän jälkeen otan merkinnän uudelleen esille ja kehotan Firefoxia tulostamaan sen, tulostaminen toimii.