Weblog Without Honor or Humanity

Weekend came, weekend went but what it left is another release of SumatraPDF - my humble reader for PDF files.

This release adds some of the most requested (in the forums) features and fixes.

This is the first release to have printing, a feature contributed in great part by Omar. It had limited testing (there are only so many pages I’m willing to print).

It has improved support for portable usage (i.e. running off of e.g. USB drive). When it detects it’s not running from Program Files directory, it assumes portable usage and doesn’t write any files or registry items on the computer. It writes its preferences files in the same directory as the executable. Because of that I changed the name of preferences file from prefs.txt to sumatrapdfprefs.txt, to make it clear it is related to Sumatra. Unfortunate side effect is that settings from 0.3 will be lost.

It no longer blindly registers itself as a default handler for PDF files. It asks the user nicely first.

Under the covers a lot of effort went into supporting alternative PDF rendering engine. This new engine is significantly faster than poppler so I’ve enabled it by default. You can switch back to poppler by unchecking menu item.

And a bunch of fixes, most of them reported at some point on those forums:

• scrolling with mouse wheel works
• fix toolbar issues on win2k
• improve the way fonts directory is found (hopefully)
• uninstaller completely removes the program

A side effect of using new engine is that support for link inside PDF files was disabled. Well, one more reason to wait for the next version…

Conclusion: use memzero(addr, size) instead of memset(addr, 0, size) to avoid making frequent memset() mistake of giving parameters in the wrong order.

memset() is another example where following established convention leads people to doing the wrong thing. One of the most frequent uses for memset() is to zero-out a piece of memory. The problem with memset() is that it’s easy to swap the “value to set” with “count of values to set” parameters. They’re both ints, so the compiler won’t complain and humans are not that good at remembering things of that nature. Combined with laziness, another human affliction, it leads to many cases where memset() is misused and ends-up being a no-op (because 0, the value, is passed as size, so it ends up doing nothing). I’ve seen this in my own code, I’ve seen this in other people’s code and you can see for yourself how many people got it wrong with this query.

And a solution is so simple: write a trivial wrapper memzero(void *s, int size). Not only is it a better name but removes possibility of this particular mistake to ever happen again. On Windows you don’t even have to write it since it’s there as ZeroMemory(). Some unixes have bzero(), but it’s an ugly name and I don’t think it’s widely available so writing memzero() utility function is a good idea anyway.