Re: solution for UIDs bigger than 2^31

>>>>> 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.
>
> all patches, we were talking about are ready (attached).

> I've tested both of them with dovecot and manually created messages with
> high
> uids. Both versions were working on systems with 64bit php, both of them
> resulted with imap error on 32 bit system.
>
> Now both of them works on 64 and 32 bit systems. I've checked this
> functions:
> send email (created email got big uid from dovecot) - successfully stored in
> Sent and readable
> move emails between folders
> next & prev
> delete and next & delete and prev
> delete email
> forward
> edit
> view header
> forward as attachment and read both email and the attachment in Sent folder
>
> Both patches has only changes to the code text for changelog/other document
> is missing.