> 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 <
[hidden email]>:
>> 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 <
[hidden email]>:
>>>>>>>> "Eric" == Eric Bezault <
[hidden email]> 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
>>>
[hidden email]
>>>
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop>>>
>>
>
processing features enabled.
