An alternative to HTML::Tagset

HTML::Tagset is a popular module on CPAN and has nearly nine thousand descendants in the "River of CPAN". Unfortunately its last version was in March 2008, nearly ten years ago, so it doesn't feature the HTML5 tags yet. There has been some discussion on the HTML tag set bug tracker but so far that has not come to fruition. As an alternative to HTML::Tagset, I made the module HTML::Valid::Tagset, which incorporates the data tables of the "Tidy HTML5" project.

It's partly based on HTML::Tagset's interface, so it can substitute for some of that module's functionality, and it also has specific tag sets for each version of HTML, including HTML5.

Having the Tidy HTML5 data tables means I was also able to add a function attributes which returns a list of valid attributes for a tag, and tag_attr_ok, which returns true or false depending on whether a particular tag can take a particular attribute. This is part of a larger distribution called HTML::Valid, based on the Tidy HTML5 project.

Why I recommend using the "++" system of Metacpan

A few days ago I bought some Christmas tree lights from, the Japanese version of Amazon:

One of the words in the description of the item is パーティスマスツリー, which seems to be "party-mas-tree". You might think that is some kind of Japanese neologism, but there's no such word as "パーティスマスツリー" in Japanese. A google search just brings you back to…

Cygwin interesting problems

According to this test my module JSON::Parse wasn't working on Cygwin. I have a Windows computer with Cygwin installed, so I thought I would try to compile the module myself. The first problem I encountered was that the cpan shell command didn't work. It would print odd-looking errors and hang up at the following prompt:

What approach do you want?  (Choose 'local::lib', 'sudo' or 'manual')

So I decided to download the module myself with wget and compile it. The next problem was that I hadn't got wget in my cygwin, so I had to install that. After downloading and untarring the file, I tried the usual

perl Makefile.PL

then "make", and got a rather baffling error

fatal error: EXTERN.h: No such file or directory

I was able to find some assistance at this site. It turned out that the C compiler gcc was not included in my cygwin, and the gcc on my path was actually the Strawberry Perl version, so I installed the Cygwin gcc.

Next, the following problem occurred.

$ make
rm -f blib/arch/auto/JSON/Parse/Parse.dll 
g++ --shared -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--enable-auto-image-base -fstack-protector-strong Json3.o -o blib/arch/auto/JSON/Parse/Parse.dll \
/usr/lib/perl5/5.22/x86_64-cygwin-threads/CORE/cygperl5_22.dll \

g++.exe: error:
/usr/lib/perl5/5.22/x86_64-cygwin-threads/CORE/cygperl5_22.dll: No
such file or directory

I spent quite a while searching around for "cygperl5_22.dll" and related things before I noticed that the g++ in my path was pointing at the Strawberry Perl one. I had only installed gcc, because I had assumed that would be enough for my non-C++ module, but it seems to use g++ regardless of whther the code is C or C++. I went back and installed g++-gcc from the Cygwin installer (setup64.exe, see Finally, with the Cygwin g++, it compiled and built the module, and I was able to reproduce the issue that the tester had demonstrated and come up with a possible solution.

Unfortunately I'm not really sure why the original problem only happened on Cygwin. There is some sort of memory management issue which I don't understand properly.

"inf" doesn't work everywhere, apparently

I've just got this CPAN Testers report which says that my module Compress::Huffman had an error due to $minkey not being set to any value on line 176. Tracing this back, it seems to be due to the use of the word 'inf' on line 166, then this being not converted to infinity but to zero for some reason, and $minkey never getting set.

I don't remember where I got the idea to use 'inf' for infinity, but I'm switching over to the method given here of using 9**9**9 instead.

Incidentally, for those interested in the Huffman algorithm, $minkey here is the least probable key, and its probability is $min, which is set to the value of infinity at the start so that every key will have a lower value than it.

C comments and regular expressions

C comments and regular expressions

The C programming language has two kinds of comments, ones with a start and end marker of the form /* comment */, and another one which starts off with two slashes, //, and goes to the end of the line, like Perl comments. The /* */ kind are the original kind, and the // kind were borrowed from C++.[1]

Let's suppose you need to match the original kind of C comments. A simple regex might look something like this:


Here we've escaped the asterisks in the comment with a backslash, \, and used exclamation marks, !, to demark the start and end of the regex, so that we don't have to escape / with a backslash.

However, C comments have the feature that they can extend over multiple lines:


which means that the above regex doesn't work. The problem is that the dot, ., doesn't match new lines. If we add the s flag to the end of the regex, the match succeeds:


The s flag alters . so that it matches newlines.

However, unfortunately this still doesn't solve the problem of matching C comments. Here is an example program where it will fail:

int x; /* x coordinate */
int y; /* y coordinate */

Can you see why? The problem is that the . in the regular expression always matches as much as it can, so it will swallow up the first */ in the regular expression and go on consuming until it reaches the second one.

One way to solve this problem is to use something like [^*], "match anything except an asterisk".


This seems to work, but there is a flaw. Although

 * comment 

is OK as far as C is concerned, the regex refuses to match it because of the extra asterisk on the middle line, so now we have to add an extra clause to match an asterisk, except where followed by a slash:


But even this still has a problem. With a comment like

/***** comment ******/

it can't match the final */, so we need to change that to


with a + after the final * so that it can match multiple asterisks before the final slash.

If you're using something like lex, that's the best you can do,[2] but fortunately Perl regexes have a few more useful abilities. The one which is useful here is the non-greedy matching ?, which changes .* from matching as much as possible to matching as little as possible.


matches all kinds of original C comments without swallowing the ends of them.

The other kind of comments look much easier to match - there are no multiple lines, and the end marker is the end of the line, so a regex like


should be enough to match them all.

Let's consider matching all comments in a C program. Suppose we have two regexes $trad_comment_re for the first kind of regex and $cxx_commment_re for the second kind. Naively we might write something like

 $c =~ m/$trad_comment_re|$cxx_comment_re/

Can you guess the pitfall? The problem is false positives with things which look like comments but aren't:

 char * c = "/* this is not a comment. */";

That's not a comment but a string. Although that one might seem unlikely, you'll also get false positives with things like

 const char * web_address = "";

because of the // in the URL.[3]

A regex to match a C string looks like this:


C strings start and end with double quotes, and they can also include double quotes after a backslash, hence we need to also match \".

Let's say we want to match all comments, then we need to also match for C strings, then discard the C strings, something like this:

while ($c =~ /($string_re|$trad_comment_re|$cxx_comment_re)/g) {
    my $comment = $1;
if ($comment =~ /^".*"$/) {
# Now we have valid comments.

If this all sounds like too much work, try my module C::Tokenize, which offers all the regular expressions. The function strip_comments also takes into account some features of the C language itself, such as that

int/* comment */x;

is a valid C declaration, by inserting a space in place of the comment.

It can even be used to strip C-style comments from JSON, since JSON strings are identical to C strings for the purpose of matching.

[1] According to Dennis Ritchie, the // comments were the comment style of BCPL, a predecessor of C, and were resurrected by C++.

[2] See my C parser cfunctions for an example of lex regexes.

[3] Apparently these were a mistake which Sir Tim Berners-Lee only noticed when he tried to match C comments using a regex.