Re: Change of contract in UT_URL_ENCODING.unescaped_utf8

There is a complication in that UT_FILE_URI_ROUTINES is buggy. In
particular, the routine uri_to_pathname has too liberal a contract.
I've discussed this extensively with Franck.

One possible solution is to strengthen the precondition so that the
argument wither contains no colon characters, or it contains exactly
one, and then the argument starts with "file:" (this would be in
accordance with the class-level documentation).

With such a precondition, it would then be possible to leave the
postcondition unchanged - that is, a non-Void Result. In such cases we
could simply return "create Result.make" for an invalid URI. Since
this is equivalent to the URI "file:///" (the rot of the file system),
this isn't attractive.

The more attractive (to me) alternative is to weaken the
postcondition, so that the return only returns non-Void if a good file
URI is passed to it. So http://www.some.host/my/path/to/file will
return Void (currently it returns the same pathname as
file:///my/path/to/file, which is a clear bug). Then if decoding a
percent-encoded URI fails (returns Void), we simply return a Void
pathname.

This means that this routine will always return Void for URIs which
include percent-encodings which are intended to be in Latin-1. Well,
that has never been supported by this class, so it should be added to
the class-level documentation. Note that the inverse routine,
pathname_to_uri, always produces UTF-8 encoded URIs (when encoding is
necessary).

2009/5/3 Colin Adams <[email protected]>:
> The contract for the routine is correct (the preconditions do not
> exclude a string which includes escapes representing a non-valid UTF-8
> byte sequence,
> such as Latin-1 bytes, or just pure garbage).
>
> There is a test that unescape_string returns no byte greater than 255
> - I think this is redundant (but it would need a postcondition on
> unescape_string to make it secure),
> but this is not relevant to the issue in hand.
>
> So the clients need changing to accept the possibility of a Void
> result. I'll look into this on Wednesday (or possibly Tuesday if I
> have more time than expected).
>
> 2009/5/2 Colin Paul Adams <[email protected]>:
>>>>>>> "Eric" == Eric Bezault <[email protected]> writes:
>>
>>    Eric> Hi Colin, On January 18, 2007, in commit svn#5840, you
>>    Eric> changed the implementation and contracts of feature
>>    Eric> `unescaped_utf8' in UT_URL_ENCODING. However, after this
>>    Eric> change of contracts, it looks like you didn't update its
>>    Eric> callers. For example feature `decoded_utf8' in class
>>    Eric> UT_URI_STRING, and hence its callers, still rely on the fact
>>    Eric> that the result of `unescaped_utf8' is supposed to be
>>    Eric> non-void.
>>
>>    Eric> Can you have a look at that? This is a bug which is blocking
>>    Eric> the conversion of Gobo to void-safe mode.
>>
>> I'll take a look early next week.
>> --
>> Colin Adams
>> Preston Lancashire
>>
>> ------------------------------------------------------------------------------
>> Register Now & Save for Velocity, the Web Performance & Operations
>> Conference from O'Reilly Media. Velocity features a full day of
>> expert-led, hands-on workshops and two days of sessions from industry
>> leaders in dedicated Performance & Operations tracks. Use code vel09scf
>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>> _______________________________________________
>> gobo-eiffel-develop mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>>
>

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com