1

Recently upgraded my PHP version from 8.0 to 8.1, now it's displaying tons of error regarding this, mainly

Severity: 8192 --> Implicit conversion from float-string "1651218180.598425" to int loses precision

I have already turned error_reporting for E_DEPRECATED off, but now, I would also like to turn it off for error logs (don't log errors regarding to Severity : 8192).

I know that the proper way is to actually fix it, but this project is 9 years old, the effort required to fix this will be rather huge, so I'm hoping if there's any leeways that can be taken to prevent this from being logged, instead of my final resort of going back to PHP8.0.

Thanks

Patrick Teng
  • 58
  • 8
  • "Severity : 8192" is [E_DEPRECATED](https://www.php.net/manual/en/errorfunc.constants.php). You can turn them off in php.ini, see e.g. https://stackoverflow.com/questions/10591958/how-to-turn-down-php-error-logging – IMSoP Nov 17 '22 at 15:12
  • Since you haven't actually shown what you're trying to do that's triggering this message, it's hard to give very specific advice. – IMSoP Nov 17 '22 at 15:13
  • As per above, i mentioned that I have already turned error reporting off, its appearing in my error logs instead. In regards to how to trigger, I thought it was straight forward. $a = "1651218180.598425"; $b = (int) $a; – Patrick Teng Nov 24 '22 at 08:18
  • The `error_reporting` settings applies to both logging errors and displaying them (if `display_errors` is on, which it never should be on a production server). Possibly you have some custom logging function that's ignoring the setting, which would explain the "Severity: 8192" which is not how it shows in the default message. Meanwhile, [that example doesn't trigger the message](https://3v4l.org/9WMqY); the message is specifically that there is an *implicit* conversion, i.e. you're doing something that requires an integer but *not* telling PHP explicitly that you want the conversion. – IMSoP Nov 24 '22 at 08:38

1 Answers1

-1

I've had to start making "safe" functions for PHP 8.1 and the ticking timebomb of PHP9 to ensure that any numeric comparisons are always done using floats.

function safe_number($strNumber){

/* 
    Removes commas from numbers
    2022-10-06: Null safe, returns 0 on empty string instead of returning a non numeric value

    Not locale sensitive
*/

return floatval(str_replace(",","",($strNumber ?: 0)));



}


$varSomething=safe_number(1234) % safe_number("1234.01234");

Unfortunately, in a big project the refactoring and regression testing is a total nightmare and expense. I am hoping the PHP core team realize what a clusterbomb they've made here and haul themselves in.

Chris Barnes Clarumedia
  • 13
  • 4
  • I'm not really clear what "clusterbomb" you think you've found here, other than an old bug in your own code - strings with commas in will *never* have done the right thing if you just treat them as numbers. https://3v4l.org/hZMPt – IMSoP Nov 17 '22 at 15:16
  • So after you've finished getting hung up on my removal of commas from numbers, the point of my response is that now in PHP8.1 it's necessary to perform ANY arithmetic operations on numbers of exactly the same type: integers with integers, floats with floats. I've found it easiest to convert them all to floats and then perform the arithmetic operation. In a big legacy project there can be a LOT of places where this is happening. That's why I call it a clusterbomb. It's expensive and time consuming to regression test (if you have realized in advance what is happening). – Chris Barnes Clarumedia Nov 17 '22 at 15:41
  • I assumed the removal of commas was significant, because other than that your function just seems to wrap `floatval` - both `floatval('')` and `floatval(null)` already return `0`. Also, your example [does not produce any deprecation notices](https://3v4l.org/Vj5VK), so that doesn't help explain the problem either. As I understand it, the deprecation occurs in places where *the previous behaviour was dangerous* (that is, probably giving unexpected results) because the fractional part of the number was being discarded. – IMSoP Nov 17 '22 at 16:12
  • This does not produce a deprecation warning: print 1234 * "1234.01234"; However, this does: print 1234 % "1234.01234"; The problem is backwards compatibility, time and expense. This is just one of many issues that are showing up. Sure, my code isn't the best, but it has worked for years... – Chris Barnes Clarumedia Nov 17 '22 at 16:29
  • Again, not the best example: `%` specifically works with integers, so an input with a fraction doesn't make much sense, and converting both sides to floats won't help: https://3v4l.org/sFK5P If you actually wanted floating point numbers to work there, you'd need to use [fmod](https://www.php.net/fmod), and the deprecation would again be pointing out a real bug. – IMSoP Nov 17 '22 at 16:42
  • @IMSoP the overall issue is that PHP used to be a very accommodating and flexible langauge and now each new version is less and less flexible, this is one factor along with `E_WARNING`s about checking a non-existant value comparison; theoretically it sounds logical but it's abaolute codebloat and error log bloat for things that have always previously worked exactly as intended without error (such as user generated `$_SESSION` array values. etc. etc.). – Martin Nov 17 '22 at 16:49
  • @IMSoP I agree, in that situation conversion to floats would not help. However in PHP 8.1 this works and will only throw a deprecation warning but in PHP 9 it will be fatal. ```$varSomething=1234 % "1234.01234"; $something=null; $varSomethingElse=htmlentities($something); ``` The problem is the volume of breaking changes to functions. – Chris Barnes Clarumedia Nov 17 '22 at 16:51
  • @Martin This is not a forum to have a long debate about the general direction of the PHP language. I'm trying to encourage the writer of this answer to give an example that is a) clear, and b) relevant to the question at the top of the page. The current answer is neither. – IMSoP Nov 17 '22 at 17:01
  • @Martin, you've hit the nail on the head far better than my clumsy illustrations. This is exactly the place for this conversation because it will be read by other crusty devs who will begin to realise the ClusterBomb that is coming. – Chris Barnes Clarumedia Nov 17 '22 at 17:03
  • To reiterate **this is not a forum**, as the [tour] and [help] make very clear. You are welcome to your opinion on the design of recent versions of PHP, but this is not the place to do that. If you want advice on alternative approaches to some of the problems you're seeing in your code, you can open a new question that's better worded than this one; if you just want to rant, do it on your own blog. – IMSoP Nov 17 '22 at 17:06
  • Would this be a better question ? "To whom should I sent the bill for all the breakages caused by largely unnecessary changes to the PHP programming language ?". Oh ! I forgot ! It's an Open Source Community Project ! I'd better find some public space to bring up these concerns..... hmmm.... ;-) My answers and questions are 100% relevant to the OP. – Chris Barnes Clarumedia Nov 17 '22 at 17:26