You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by André Malo <nd...@perlig.de> on 2003/03/09 01:43:10 UTC

mod_negotiation: get a rid of atof(3)

There's a PR dealing with atof() problems: 
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17564>.

I think, we should simply avoid that function call.
The attached patch does the following:

- quality values are converted by a specialized function atoq.
- level values are no longer parsed as float (instead as int, using atoi). 
According to our documentation this was already intended :)

Do you see any problems with this patch? (especially with the level thing? 
(Does anybody actually use it?))

nd
-- 
package Hacker::Perl::Another::Just;print
qq~@{[reverse split/::/ =>__PACKAGE__]}~;

#  André Malo  #  http://pub.perlig.de  #

Re: mod_negotiation: get a rid of atof(3)

Posted by André Malo <nd...@perlig.de>.
* Dirk-Willem van Gulik wrote:

>> Because no supplied qvalue is the same as qvalue = 1. If I'm wrong with
>> that assumption, please correct me.
> 
> Is -that- in the standard ? You sure even if it is mixed with entries
> which have a q?

RFC 2616, 14.1 (Accept:)states:
   Each media-range MAY be followed by one or more accept-params,
   beginning with the "q" parameter for indicating a relative quality
   factor. The first "q" parameter (if any) separates the media-range
   parameter(s) from the accept-params. Quality factors allow the user
   or user agent to indicate the relative degree of preference for that
   media-range, using the qvalue scale from 0 to 1 (section 3.9). The
   default value is q=1.
   
14.2 (Accept-Charset) and 14.4 (Accept-language) go similar. 14.3 
(Accept-Encoding) doesn't mention it explicitely.

... yes, I'd say so.

nd
-- 
Real programmers confuse Christmas and Halloween because
DEC 25 = OCT 31.  -- Unknown

                                      (found in ssl_engine_mutex.c)

Re: mod_negotiation: get a rid of atof(3)

Posted by André Malo <nd...@perlig.de>.
* Jim Jagielski wrote:

> At 7:16 PM +0100 3/11/03, André Malo wrote:
>>* Jim Jagielski wrote:
>>
>>> Not sure about
>>>
>>> +    if (!string || !*string) {
>>> +        return  1.0f;
>>> +    }
>>> +
>>>
>>> Why return 1 if passed a NULL??
>>
>>Because no supplied qvalue is the same as qvalue = 1. If I'm wrong with
>>that assumption, please correct me.
>>
> 
> methinks that's wrong. If atof/strtod is passed NULL, or a
> null string, they return 0. If atoq is supposed to be similar,
> then it should also return 0.

It looks like a definition on our side. What do we do with invalid qvalues?
ignore as it were no qvalue supplied (q=1) or ignore as it were q=0?

I'm also not sure, but in my feeling the former is better :)

> In any case, I'm unsure of the need for this anyway... Seems
> a lot of trouble to force a float that, we hope, will only have
> 3 places after the decimal (ie: that 12345.0/1000.0 will be exactly
> 12.345 all the time, on all systems in all uses). Does it really matter
> if internally we calculate the above as 12.3450001 if we actually
> make sure the entries in the headers conform?

No, it doesn't matter (aside from the chaos theory ;-). But multiplying 
several times with the (in IEEE 754 periodic) 0.1 is probably less 
efficient than one division by 1000. But I didn't benchmark it, just theory 
for now ...

nd
-- 
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~  # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=>map{chr(ord(  #             André Malo ;
$_)-1)}split//=>$_[0]).$_[1];s s.*s$_see;  #  http://www.perlig.de/ ;

Re: mod_negotiation: get a rid of atof(3)

Posted by Jim Jagielski <ji...@jaguNET.com>.
At 7:16 PM +0100 3/11/03, André Malo wrote:
>* Jim Jagielski wrote:
>
>> Not sure about
>>
>> +    if (!string || !*string) {
>> +        return  1.0f;
>> +    }
>> +
>>
>> Why return 1 if passed a NULL??
>
>Because no supplied qvalue is the same as qvalue = 1. If I'm wrong with
>that assumption, please correct me.
>

methinks that's wrong. If atof/strtod is passed NULL, or a
null string, they return 0. If atoq is supposed to be similar,
then it should also return 0.

In any case, I'm unsure of the need for this anyway... Seems
a lot of trouble to force a float that, we hope, will only have
3 places after the decimal (ie: that 12345.0/1000.0 will be exactly
12.345 all the time, on all systems in all uses). Does it really matter
if internally we calculate the above as 12.3450001 if we actually
make sure the entries in the headers conform? Agreed, however that
the locale/LC_NUMERIC stuff is an issue.
-- 
===========================================================================
   Jim Jagielski   [|]   jim@jaguNET.com   [|]   http://www.jaguNET.com/
      "A society that will trade a little liberty for a little order
             will lose both and deserve neither" - T.Jefferson

Re: mod_negotiation: get a rid of atof(3)

Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> Because no supplied qvalue is the same as qvalue = 1. If I'm wrong with
> that assumption, please correct me.

Is -that- in the standard ? You sure even if it is mixed with entries
which have a q?

Dw


Re: mod_negotiation: get a rid of atof(3)

Posted by André Malo <nd...@perlig.de>.
* Jim Jagielski wrote:

> Not sure about
> 
> +    if (!string || !*string) {
> +        return  1.0f;
> +    }
> +
> 
> Why return 1 if passed a NULL??

Because no supplied qvalue is the same as qvalue = 1. If I'm wrong with 
that assumption, please correct me.

(NULL should never occur anyway, but let's be safe)

nd
-- 
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~  # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=>map{chr(ord(  #             André Malo ;
$_)-1)}split//=>$_[0]).$_[1];s s.*s$_see;  #  http://pub.perlig.de/ ;

Re: mod_negotiation: get a rid of atof(3)

Posted by Jim Jagielski <ji...@jaguNET.com>.
Not sure about

+    if (!string || !*string) {
+        return  1.0f;
+    }
+

Why return 1 if passed a NULL??
-- 
===========================================================================
   Jim Jagielski   [|]   jim@jaguNET.com   [|]   http://www.jaguNET.com/
      "A society that will trade a little liberty for a little order
             will lose both and deserve neither" - T.Jefferson

Re: mod_negotiation: get a rid of atof(3)

Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
+1 one on this - it solves some nasty locale problems for compilers which,
say in France or the Netherlands swap the '.' and ','.

Dw.
-- 
Dirk-Willem van Gulik

On Sun, 9 Mar 2003, [ISO-8859-1] Andr� Malo wrote:

> There's a PR dealing with atof() problems:
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17564>.
>
> I think, we should simply avoid that function call.
> The attached patch does the following:
>
> - quality values are converted by a specialized function atoq.
> - level values are no longer parsed as float (instead as int, using atoi).
> According to our documentation this was already intended :)
>
> Do you see any problems with this patch? (especially with the level thing?
> (Does anybody actually use it?))
>
> nd
>