Advogato blog for mitr

7 Nov 2004

Sun, 7 Nov 2004 22:15:59 GMT

I have seen one too many instances of checking strtol () results wrong, so, for the record:

Update: Sigh, two too many, a portable check for empty input added.

To convert const char *str to a long, properly checking for overflow, invalid trailing characters and empty input, it is necessary to do the following:

char *p;
errno = 0;
result = strtol(str, &p, base);
if (errno != 0 || *p != 0 || p == str)
  error_handling ();

It is necessary to check both errno and *p; if you don't check errno, you get 0 for empty input and LONG_MAX or LONG_MIN for overflow or underflow. On empty input the return value is 0 and errno might be set to EINVAL; the portable way of checking for empty input is comparing p and str.

This will still accept strings that start with white space; check for !isspace((unsigned char)*str) if you want to reject them.

I hope that helps someone.

12 Apr 2004

Mon, 12 Apr 2004 11:51:58 GMT

I was cleaning up cereal a bit and I contemplated replacing db2* (using openjade and DSSSL) with xmlto (using passivetex and XSLT). HTML generation went down from 6 s to 4 s, PDF generation up from 30 s to about 5 min.

Needless to say I'm staying with the DSSSL styles. At least I got a chance to fix some errors caught by the stricter XML parser used by xmlto.

5 Apr 2004

Mon, 5 Apr 2004 13:22:11 GMT

Well, we (Charles University Prague) didn't win the ACM ICPC this year. I had fun anyway.

11 Mar 2004

Thu, 11 Mar 2004 17:16:52 GMT

Installed current CVS GNOME and checked the translations (which turned out to be mostly fine). New GNOME looks really good. I can't wait for FC 2 with Bluecurvized GNOME 2.6; my eyes are too accustomed to the theme, which makes the work with Simple a bit uncomfortable.

25 Feb 2004

Wed, 25 Feb 2004 06:06:26 GMT

A new release of cereal after six months, again with virtually no code changes.

Hopefully it will make the one or two people trying to build cereal on Gentoo happy.

23 Feb 2004

Mon, 23 Feb 2004 19:30:03 GMT

Writing what is supposed to be a noddy program and finding a bug in glibc during the process does not happen every day :).

23 Feb 2004

Mon, 23 Feb 2004 08:33:16 GMT

I have spent the weekend writing a GUI in Python. It's not too bad, but not that great either.

Using Python is quite easy and I'm sure I couldn't have written the same application in C as fast. The automatic memory management helps a lot too.

Fast as the development is, it is also quite painful for someone (me) used to static syntax and type checking. The ten edit-test cycles needed to fix a stupid error (defining a variable that shadows a built-in function) certainly were not faster than ten edit-compile cycles in C.

I'm also a bit worried about shipping an application without a way to make sure there are no "obvious" typos in the notoriously hard-to-test error-checking paths. Adrian probably knows what I mean.

And yes, I know about pychecker. It helps somewhat, but it executes all code outside of class definitions and class __init__ methods, which breaks horribly if the code fails a check and calls sys.exit.

2 Feb 2004

Mon, 2 Feb 2004 19:08:13 GMT

Now that is an useful ChangeLog entry:

2004-02-01  somebody
        * project/*:
        * extra/*:
        * testing/*: Lots of bug fixes and improvements.

2003-09-29  somebody other

(details hidden to protect the guilty party).

30 Jan 2004

Fri, 30 Jan 2004 08:16:59 GMT

Want some silly fun? Do a competition with your roommates in Minesweeper!

21 Jan 2004

Wed, 21 Jan 2004 19:26:18 GMT

Out of curiosity I have checked all files that get bundled in a tarball of an autoconfiscated project. I haven't found anything interesting among them, but noticed gettext.h (copied from the gettext package, as suggested in the manual), which is under LGPL.

The project is licensed under OSL 2.0, so I got curious about the combination. LGPL paragraph 6 requires that with each binary of my project the distributor must "give prominent notice that the Library is used in it" ..., "supply a copy of this License", "include the copyright notice of the Library" and "a reference directing the user to the copy of this License".

So, apparently I can ship gettext.h in the tarball as long as I also ship COPYING.LIB. But anyone distributing a binary must make sure there is a "prominent notice" and modify the program to add the copyright notice for gettext and a pointer to COPYING.LIB. I ended up rewriting gettext.h from scratch; I don't want to "accidentaly" put such requirements on users of my software.

It gets worse, though. Reading /usr/include/string.h from glibc you see that if you compile with gcc -O (and don't define __NO_STRING_INLINES), #include <string.h> pulls also /usr/include/bits/string2.h, which contains very large inline functions that can not be considered trivial (due to the C aliasing model they can not even be written in strictly conforming C99). So any executable that uses the functions from glibc is clearly a derived work of glibc and falls under LGPL paragraph 6. (Even though LGPL paragraph 6 seems to indicate that they consider executables using shared linking to still be derived works of the library, I can imagine the judge would disagree; but the string inlines are not a case of shared linking.)

What does it mean? Since gcc is the canonical compiler on Linux, almost everybody is using optimization and almost every program calls memset (), strcpy (), strncpy () or strcmp () (this list is not exhaustive), almost any program for Linux distributed in binary form must be shipped acompanied with COPYING.LIB, must give a prominent notice it uses glibc and must contain the glibc copyright notice along with other copyright notices.

I find it quite surprising. In fact I don't know about any program that does that.