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 cygwin.org). 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:

qr!/\*.*\*\/!

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:

/*
  Comment
*/

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:

qr!/\*.*\*\/!s

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

qr!/\*[^*]*\*/!

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:

qr!/\*([^*]|\*+[^/])*\*/!

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

qr!/\*([^*]|\*+[^/])*\*+/!

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.

qr!/\*.*?\*/!s

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

qr!//.*$!

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 = "https://www.google.com";

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

A regex to match a C string looks like this:

 qr/"(\\"|[^"]*)"/

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 =~ /^".*"$/) {
    next;
    }
# 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.

Check compression in web page

This module offers a way to check your web pages for correct gzip compression. It not only checks that your web page is compressed properly when required, but also checks that the web page is not accidentally compressed when not required, and that the compression actually does something useful in terms of reducing the page size. I wrote it because I couldn't find anything to do that on CPAN.

It's compatible with Test::More if you want to run the compression checks automatically.

New ways to include images in CPAN modules

The latest release of Test::podimage, version 0.05, shows a few interesting experimental ways to include images in CPAN modules.

It seems there is a way to show image files from the distribution on metacpan by using a leading slash, which I'd never heard of until now. There's also a new "=for image" tag. Oddly enough, although this was proposed five days ago, the CPAN grep search site tells us that this tag actually appears in some CPAN modules such as this one from 2010, although the above don't actually display on metacpan, perhaps because there is no leading slash in the image name.

A data URL can also be used.

Most of the image formats don't work on search.cpan.org.