[redland-dev] Bug in raptor_vsnprintf()

[John Emmas]

On 23 May 2012, at 10:46, Lauri Aalto wrote:

> 
> thanks for the report. The best place for bug reports is
> <http://bugs.librdf.org>.
> 
> I fixed this particular issue in commit
> <https://github.com/dajobe/raptor/commit/391e09a5acddaf3ed63005bec880804896ca860e>.
> 

Thanks Lauri.  I'll update from GIT later today and in future, I'll report bugs to the right place.

I've found something else which might be a bug (well, an oversight really) but before I report it, let me describe it here in case I'm misunderstanding something.

I'm working on a cross-platform app which uses lrdf to open and parse some files.  'lrdf_read_file()' eventually defers to 'raptor_parser_parse_file()' to open the actual disk file.  'raptor_parser_parse_file()' accepts a URI to identify the file to be opened.  According to this document by Tim Berners-Lee:-

http://tools.ietf.org/html/rfc3986

the specification states that before conversion to URI, a character string must first get converted to UTF-8 (see the final paragraph of Section 2 - just before Section 3).

'raptor_parser_parse_file()' calls 'raptor_uri_uri_string_to_filename()' to produce a string that identifies the local file.  However, after decoding, that string will be in UTF-8 format.  UTF-8 format seems to work for Linux and OS-X but on Windows, you cannot pass a UTF-8 string to 'open()'.  So 'raptor_uri_uri_string_to_filename()' only works reliably in an English language locale.  It will fail if there are non-English characters in the file path.  On Windows an extra layer of decoding is needed to convert the UTF-8 file path into a valid Windows file path (Windows has functions to achieve this, I think).

I could probably write a patch and submit it but before I do that, is there already some recommended way for dealing with this (i.e. have I simply missed something?)

John