Ulysses Stuff > Releases
ERS - EMail Reporting System
DarKevin:
Alright, I can set something up for you I guess ;l
Gonna PM you the Login details when it's done.
EDIT:
Hey, since you removed the "browser block" I went and opened the last php code you sent me in my browser, and it gave me an error
saying the last } bracket at the end of code is unexpected.
I removed it, fixing the error, but still didn't receive an E-Mail.
However, in my webhost control panel it says that it sent the Mails like "2 of the maximum of 100 mails a day have been sent"
To make sure it wasn't from my simple test code, I tried it again, and it is what those "sent" mails were coming from.
Something tells me that I should contact my webhost, regarding the where-the-f**k-abouts of my dang mail, lol.
But I'll copy the php files in the test folder that I prepared for you, and send you the login details by PM soon.
PS: I also checked my mailbox's spam/virus folders, they're empty.
MrPresident:
Thanks, I'll take a look soon when I get the chance. It'll be nice having access to another server to test on. (Especially one that someone has a known problem)
fortyeightthousand:
Haven't seen anything new with this topic in a couple weeks. Any updates?
MrPresident:
Nothing yet. Haven't had the time.
Neku:
Here's a quote from http://php.net/manual/en/function.crc32.php.
--- Quote ---Because PHP's integer type is signed many crc32 checksums will result in negative integers on 32bit platforms. On 64bit installations all crc32() results will be positive integers though.
So you need to use the "%u" formatter of sprintf() or printf() to get the string representation of the unsigned crc32() checksum in decimal format.
For a hexadecimal representation of the checksum you can either use the "%x" formatter of sprintf() or printf() or the dechex() conversion functions, both of these also take care of converting the crc32() result to an unsigned integer.
Having 64bit installations also return negative integers for higher result values was considered but would break the hexadecimal conversion as negatives would get an extra 0xFFFFFFFF######## offset then. As hexadecimal representation seems to be the most common use case we decided to not break this even if it breaks direct decimal comparisons in about 50% of the cases when moving from 32 to 64bits.
In retrospect having the function return an integer maybe wasn't the best idea and returning a hex string representation right away (as e.g. md5() does) might have been a better plan to begin with.
For a more portable solution you may also consider the generic hash(). hash("crc32b", $str) will return the same string as dechex(crc32($str)).
--- End quote ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version