Re: AW: AW: octstr_compare

+1 from me. Changing function semantics is a good
reason define new function (caller would definitely
notice the change of semantics)

Aarno

On 10.3.2004, at 13:58, Yury Mikhienko wrote:

>
>
> Begin forwarded message:
>
> Date: Wed, 10 Mar 2004 14:23:04 +0300
> From: Yury Mikhienko <[email protected]>
> To: Jorg Pommnitz <[email protected]>
> Subject: Re: AW: AW: octstr_compare
>
>
> On Wed, 10 Mar 2004 11:42:14 +0100
> Jorg Pommnitz <[email protected]> wrote:
>
>>> But if I use disable_assertion option?
>>
>> If you need this at all, then you should handle the NULL case before 
>> the
>> seems_valid tests. And you should cover all the cases, e.g.
>> (octstr1 == NULL) && (octstr2 == NULL) -> true
>> (octstr1 == NULL) && (octstr2 != NULL) -> false
>> (octstr1 != NULL) && (octstr2 == NULL) -> false
>>
>> Than do the seems_valid tests and the normal code.
>>
>> But seriously, I doubt that this is a good idea. Just don't compare 
>> invalid
>> octstr
>> or, if you really need this, than write a wrapper:
>>
>> int
>> octstr_compare_null_safe (octstr1, octstr2)
>> {
>>   if (!octsr1 && !octsr2)
>> 	return 1;
>>   else if ((!octsr1 && octstr2) || (octstr1 && !octstr2))
>> 	return 0;
>>   else
>>      return octstr_compare (octstr1, octstr2);
>> }
>>
>> This way you do not pollute the general code.
>>
>
> May be that:
>
> int
>  octstr_compare_null_safe (octstr1, octstr2)
>  {
>    if (!octstr1 && !octstr2)
>  	return 0; //octstr1 == octstr2 == NULL
>    else if (!octsr1 && octstr2)
>  	return -1; //(octstr1 == NULL) < (octstr2 != NULL)
>    else if (octsr1 && !octstr2)
>  	return 1; //(octstr1 != NULL) > (octstr2 == NULL)
>    else
>       return octstr_compare (octstr1, octstr2);
>  }
>
> -- 
>
> Best regards,
> Yury Mikhienko.
> IT ERP group head, ZAO "Mobikom-Kavkaz"
> tel: (8632) 704188
>
>
> -- 
>
> Best regards,
> Yury Mikhienko.
> IT ERP group head, ZAO "Mobikom-Kavkaz"
> tel: (8632) 704188
>