Geçen hafta sonu benim web sitesi için webhosts değişti. Ben vardı ana sunucu bir 32-bit işletim sistemi ve ben taşındık bir 64-bit. Beklenmedik bir şekilde, benim PHP betikleri bazı yanlış sonuçlar vermeye başladı.
Benim durumumda << ve >> (bit shift) işlemleri suçlu idi. Ben 0xFFFFFFFF ile sonuç maske olan ve daha önce yaptığı gibi çalışmak için negatif eğer sonuç değiştirilmesi sona erdi.
Ben bakmak gerekir benim PHP betikleri diğer olası sorunları var mı?
Bir tamsayı yerine 32bit 64bit olabilir. Bazı tuhaf cases Bu neden olabilir sorunlar vardır.
bit manipülasyon sistemleri / mimarileri arasında taşınabilir kılmak için özel bir bakım gerektirir.
C, << ve >> işlemleri negatif sayılar için olanlar / ikişerli iltifat kuralları kaldırır ki, unsigned değişkenleri kullanılarak taşınabilir yapılabilir.
Genel bir kural olarak, (gibi & ve |) bit manipülasyon için sabit uzunlukta maskeler kullanmak Yüklü. Bu mimariye bağımlıdır.
Eg. Resetting the last 4 bits: the mask 0xF0 will work on an 8-bit architecture, but not 16-bit. The results will be different (16-bit may have other bits that are set that are not included in the mask).
Bu sorunu aşmak için, ~ operatör faydalanmak. Maske ~ 0xf 0xF0 eşdeğerdir, ancak any mimarisi üzerinde çalışacak. Son 4 hariç tüm bitleri sıfırlanır olacak
strtotime 64 bit farklı davranır. PHP.net Gönderen:
Not:
Bir damgası geçerli aralığı, genellikle Cum, 13 Ara 1901 Sal, 19 Ocak 2038 03:14:07 UTC için 20:45:54 UTC. (Bu bir 32 bitlik imzalı tamsayı için minimum ve maksimum değerlerine karşılık tarihler.) Ayrıca, tüm platformlar olumsuz damgalarını desteklemiyor, bu yüzden tarih aralığı Unix dönemi daha erken sınırlı olabilir. Bu demektir ki, örneğin önce 1 Ocak 1970 için tarihi Windows, bazı Linux dağıtımları, ve birkaç diğer işletim sistemlerinde çalışmaz. PHP 5.1.0 ve üstü sürümleri olsa bu sınırlamanın üstesinden.
64 bit iki yönde de yaklaşık 293 milyar yıl temsil gibi PHP 64-bit sürümleri için, bir zaman damgası geçerli aralığı, etkili sonsuzdur.
Biz strtotime ('0000-00-00 ') yapıyordu kodu vardı ve sonuç olarak biz 64 bit taşındı biz geri bir negatif tamsayı var, yanlış olması bekleniyor.
Only problem's you'll see are when you relied on 32-bit binary representation of data. Mainly because PHP uses signed integers, you'll see issues in Hashing, key generation, etc... when explicitly casting to int with (int), numbers > 2^32 will wrap where as they will not wrap in a 64 bit environment unless they are > 2^64 of course.
4 bit örnek 8 vs:
Ondalık değer konular:
0010 >> 1 = 0001 [ 1 dec ]
0000 0010 >> 1 = 0000 0001 [ 1 dec ]
Ancak bunlar, aynı sonucu (ondalık bilge) üretmek hem de:
0100 << 1 = 1000 [ -8 dec ]
0000 0100 << 1 = 0000 1000 [ 16 dec ]
Sarma konular:
1000 << 1 = 0000 [ 0 dec ]
0000 1000 << 1 = 0001 0000 [ 32 dec ]
Son sonucu 32bit parçalar dayanır eğer böyle telafi etmek zorunda kalacak, böylece tüm tamsayı / kayan nokta operasyonlar, 64-bit değerleri olarak kabul edilecektir.