Re: [SM-DEVEL] solution for UIDs bigger than 2^31

[Michal Hlavinka <mhlavink@re...>]

one note... in patch for 1.4 there is wrongly specified tag @since 1.5.3 
instead of 1.4.18
(squirrelmail/functions/global.php, on the top of the patch)

Michal Hlavinka wrote:
> Hi,
>
> all patches, we were talking about are ready (attached).
>
> patches are against 1.4 svn and 1.5 svn (yesterday)
> In the end, I've used conversion to string in both of them. Only 1.4 
> contains
> additional conversion in sources of delete_and_next plugin to float
> to perform arithmetic operations.
>
> 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.
>
> Regards,
>
> Michal Hlavinka
>

Re: [SM-DEVEL] solution for UIDs bigger than 2^31

[Michal Hlavinka <mhlavink@re...>]

Hi,

all patches, we were talking about are ready (attached).

patches are against 1.4 svn and 1.5 svn (yesterday)
In the end, I've used conversion to string in both of them. Only 1.4 
contains
additional conversion in sources of delete_and_next plugin to float
to perform arithmetic operations.

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.

Regards,

Michal Hlavinka


Paul Lesniewski wrote:
> On Thu, Nov 27, 2008 at 9:01 AM, Michal Hlavinka <mhlavink@...> wrote:
>   
>> Paul Lesniewski wrote:
>>     
>>> On Wed, Nov 26, 2008 at 7:50 AM, Michal Hlavinka <mhlavink@...> 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: squirrelmail-devel@...
> List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
> List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel
>