Re: solution for UIDs bigger than 2^31

On Thu, Nov 27, 2008 at 9:01 AM, Michal Hlavinka <[email protected]> wrote:
> Paul Lesniewski wrote:
>> On Wed, Nov 26, 2008 at 7:50 AM, Michal Hlavinka <[email protected]> wrote:
>>
>>> In fact it's not so much code. Only replace $a=(int)$b; to
>>> $a=sqrestrict_to_num($b);
>>> sqrestrict_to_int contains only : return (is_numeric($b) ? $b : 0);
>>> Casting not int to int
>>> results to 0, so there is no change.
>>>
>>
>> Not sure what you mean by "no change", but this seems about right.
>>
> "no change" as invalid values will still be changed to 0.
>
>> The "this much code" comment was based more on the number of pages
>> that may need to be changed, not that the change itself is big.
>>
> the number of pages (at least in 1.4svn) wasn't so high
>
>> However, I'm not sure we'd want to use is_numeric().  See the PHP
>> manual regarding how it accepts scientific notation and hex numbers
>> and decimal points.  Rather, I believe we only want
>> preg_match('/^[0-9]$/'), no?
>>
> I've preferred is_numeric because it checks if variable is a numeric
> string or a number.
> The reason for is_numeric/other check is because of sanitizing "ugly"
> "accidental" values

SquirrelMail does not create "accidental" values.  As far as I know,
UIDs should only contain digits.  is_numeric() allows things other
than digits.  My regexp is very easy to understand - easier than
looking up what is_numeric() allows in fact.  I do not see any reason
why using is_numeric() is better than that regexp, especially if the
target format is a string.

> and number (even in scientific form) can cause no harm at all. Also
> is_numeric was
> my first thought and it works :)
>
>>>>> but I've found squirrelmail uses also
>>>>> ++, -- and comparison operators for UIDs (in
>>>>> plugins/delete_move_next/setup.php: 152: delete_move_next_read(...)
>>>>> function). So strings can't be used for this
>>>> I think you are using an outdated version of SM.
>>>>
>>> svn 1.4 is outdated?
>>> (
>>> http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/
>>> )
>>>
>>
>> Hmm, well, your comments about the delete_move_next plugin didn't
>> match what I see there, but I am not sure I've updated it in a while.
>> I can double-check, but so should you.
>>
> in 1.4svn2008-11-27: plugins/delete_move_next/setup.php:
> function delete_move_next_read: lines 169-173
> there are used operators > and --

Right.

> in 1.5svn2008-11-27: there is no delete_move_next plugin and also I've
> found no arithmetic
> operators (just quick search).

Yes, the UIDs are kept in an ordered array, from which positional
judgments can be more accurately made.

> so... arithmetic operators are used only in 1.4 in delete_move_next
> plugin, but this is the
> version I need to fix the most (can't take devel version into on the
> production hosts).

Then I suggest you put a patch together for your float implementation
and put it on the SquirrelMail tracker (feel free to post a link to it
here).  We will review it, but again, as of now, I think the only
place we plan to make this change is in our 1.5.x branch.

Thanks a lot for your help.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: [email protected]
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel