4294967295 is 2^32-1, the maximum 32 bit unsigned integer, which has 10 digits if my eyes don't deceive me. 9999999999 exceeds that internal limit (even though it's still 10 digits) and is likely to cause an error.
I don't know why my code wouldn't work for you, unless your original $attachment['filesize'] is not a 32 bit or smaller integer. Is it a decimal value (floating point)? 1073741824 should fit comfortably within any int or bigint (32 or 64 bit, signed or unsigned). The comparison is done by subtracting one number from the other, so that should work OK. Possibly to do the division, it's converting the values to floating point first, and you're losing enough precision to cause a problem, although the result should be of the correct magnitude: 1100000000/1073741824 might be handled as 1.1E+09/1.07374E+09, but that should still be in the ballpark of 1.02 (GB). I'll have to play around with it a bit, and will post any news here.
Update: OK, add some ( ) as shown in the edited post above. PHP has some peculiar precedence rules!
I read up on the MySQL data types, and it appears that the length, e.g., (10) is ignored except when you have ZEROFILL on to left pad with 0's out to the given length for command line display purposes. It is not supposed to affect the actual value in either command line or via API. It's not clear whether a ZEROFILL'd value exceeding the given width simply displays at the needed width (exceeding the given field width); nor is it clear what happens if a signed integer is negative (the use of width 11 leads me to suspect that an extra digit is needed for the minus sign).