[ragel-users] Path handling of the native Windows build

[ragel-user at jgoettgens.de]

Recently Austin Hastings reported about a bug of the native Windows build when further machines are included when the include directories are given on the command line. There is more than the bug Austin discovered as path handling for non Posix platforms is at least somewhat incomplete and inconsistent.  You can blame the maintainer of the Windows port for this :)

I have patched the source code such that you can now include additional machines by specifying sub directories from the include statement and by specifying them on the command line with the -I option. All include directories may be specified as relative or absolute paths and the path separator may be either '/' odr '\'---you can even mix them.

The patched sources and binaries can be downloaded from:

http://www.jgoettgens.de/Meine_Bilder_und_Dateien/ragel-vs2008-patched.7z

Please test the patched version as I have done only basic testing, and drop a line in case of any dodgy behavior.

Although there is a Windows specific (aka _WIN32 is defined) definition for a path separator, include statements like  #include inner "xdir\testinc.rl";  work, because the current Windows runtime libraries accept also the separtor '/'.  Using '\' is not enforced by Ragel.  Interestingly, statements like  #include inner "xdir\testinc.rl";  fail, because the include file is handled by the scanner inside Ragel which calls prepareLitString() for new tokens.  If the path contains a valid '\', the next char is either dropped or translated, because the '\' is interpreted as an escape character.  So when it is time to open the include file, its name has been changed to "xdir<tab char>estinc.rl". Obviously, this file exists only by coincidence.

Since I did not want to touch the data structures of Ragel, I simply hacked argv as various paths are just pointers into argv.  The only source code change was to remove the constness of argv in addition to a routine that normalizes paths.  If Adrian decides to copy the names, my patches are obsolete, but then his path data will be no longer read-only and a similar patch could be applied to these variables. Of course a better solution would be to make Ragel platform path agnostic...

As far as the failing -I <include dir> is concerned, it's just that the Microsoft compiler doesn't let you read or write to a file when its state is not "good".  The good old days are over when gcc was the stricter compiler.  When iterating through all possible file names, the state of the ifstream is "fail".  The patch (the correct way?) is to call  inFile->clear()  if opening fails.  If you specify a sub directory inside your FSM description, the current algorithm at first tries to open this file relative to the path of the main file (unless it is an absolute path, which also works).  The first file never suffers from the state problem, so this method worked without patching, although the same routines are involved.

To explore my source code changes use WinMerge or Meld on the entire source trees.

jg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.colm.net/pipermail/ragel-users/attachments/20110326/1143a800/attachment-0001.html>
-------------- next part --------------
_______________________________________________
ragel-users mailing list
ragel-users at complang.org
http://www.complang.org/mailman/listinfo/ragel-users