« Return to Thread: solution for UIDs bigger than 2^31
Re: solution for UIDs bigger than 2^31
by Paul Lesniewski
::
Rate this Message:
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
> 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
« Return to Thread: solution for UIDs bigger than 2^31
| Free embeddable forum powered by Nabble | Forum Help |
