Re: Change of contract in UT_URL_ENCODING.unescaped_utf8

Looking at the latest code in SVN, I see that ?STRING is used on
return type of unescape_utf8, but unescape_string has plain STRING
(not !STRING).

Is this the policy to follow? Doesn't it mean that the library will
only be Void-safe if types are considered attached by default?

2009/5/6 Colin Adams <[email protected]>:
> 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