From: Paul L. <pa...@sq...> - 2009-02-01 02:27:34
|
Please do not top-post. Please review our mailing list posting guidelines (linked at the bottom of all messages on this list) for more information about how to post on our lists. >>>>> 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). Thank you. (No need to paste them in the email body too.) > 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. Thank you. We won't be applying this to 1.4 for now, but I have attached it to the tracker item you created. For 1.5, I have just applied some changes that are different from yours, so we'd really appreciate if you could download the newest 1.5.2 SVN code (if using snapshots, wait at least 24 hours, or see the attached patch) and test that it works. I have a couple plugins (beside the core ones I changed in 1.5.2) that need corresponding changes, which I will release soon, especially if I can get feedback on the 1.5.2 changes. Thanks again very much for your help. > 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. |