4 ms·

Whenever the @-operator is used, PHP needs to invoke the INI settings mechanism to change the temporary value of the error_reporting setting to 0. Can't make

• jiggy2011 14y ago
  That's not too bad assuming that only that thread is affected. I can't think of another way to do it that wouldn't effectively reduce to this anyway.
  • lonnyk 14y ago
    PHP doesn't use threads unless you are using the pthreads extension [1]. I am not sure how it would affect that ext. Normally it won't affect any other PHP scripts that are running. [1] https://github.com/krakjoe/pthreads https://github.com/krakjoe/pthreads
• TazeTSchnitzel 14y ago
  Oh, it's just one of thousands of nonsensical PHP features. Like the fact that the language's grammar is used to do primitive type checking, meaning some combinations of accessors cause errors. Or the fact the mail sending function doesn't work if one of the lines in the email begins with a period, but only if you're on Windows.
  • acabal 14y ago
    Some of the weirder OS-specific function behaviors can be a rationalized a little better if you view PHP functions not as sane, complete library functions, but rather as thin wrappers to the underlying OS. For mail() it basically just wraps the system's mail program in Linux (which comes with a huge number of dangerous gotchas for the uninitiated) and I imagine in Windows it wraps the local mail program which seems to have a gotcha with periods. I think a lot of the file management functions are the same. That's one of the many problems with PHP's underlying design philosopy: instead of providing a higher-level interface that stays consistent across platforms, it exposes low-level OS gunk and gotchas through its thin wrappers on low-level-ish functions. I put together phpbestpractices.org a few months ago in an attempt to document some of those common gotchas and provide sane alternatives.
    • TazeTSchnitzel 14y ago
      >PHP functions not as sane, complete library functions, but rather as thin wrappers to the underlying OS. Except they're not really that thin. >in Windows it wraps the local mail program which seems to have a gotcha with periods Nope, in Windows it implements the SMTP protocol, on UNIX it runs sendmail. >instead of providing a higher-level interface that stays consistent across platforms, it exposes low-level OS gunk and gotchas through its thin wrappers on low-level-ish functions. Except it doesn't. There's quite a few things that are named like OS functions, but are implemented internally. For example, all the C stdlib-like string functions.
      • acabal 14y ago
        My mistake then :) I admit I haven't read the source, I'm just going off of the quirkiness of cross-platform PHP and the way the functions seem to behave.
• lonnyk 14y ago
  It doesn't actually change the INI file. It changes the error_reporting setting in memory while that one function is executing and when it finishes it changes it back.
  • VMG 14y ago
    It still is a weird unexpected side effect and at least a hash lookup in a map
    • lonnyk 14y ago
      I don't see how this is a 'side effect'. It accomplishes the exact task it is designed to and doesn't do any quirky, or 'side', behavior to the script. Also, I wouldn't be worried about one lookup. I'm pretty sure everything in PHP is in a hash map.
    • maratd 14y ago
      No, it's actually a good idea. That way I can programmatically check if any error is going to be reported inside of a method or function that's being silenced. And, on top of that, override the silencing within a method or function directly. Using an established interface provides me with a ton of options ... options I wouldn't have if it did some sort of internal voodoo.
      • VMG 14y ago
        But you then can never know what the actual real ini value is. The override should be a different interpreter state variable (if at all).