• (disco)

    How does PHP deal with integer overflow? Error? Exception? Silently?

  • (disco) in reply to aliceif
    aliceif:
    How does PHP deal with integer overflow? Error? Exception? Silently? 
    <?php
    $a = PHP_INT_MAX ;
    echo $a . '<br />';
    $a++;
    echo $a;
?>

    9223372036854775807
9.22337203685E+18
  • (disco) in reply to aliceif
    aliceif:
    How does PHP deal with integer overflow? Error? Exception? Silently?

    By turning it into a bowl of petunias.

    If PHP encounters a number beyond the bounds of the integer type, it will be interpreted as a float instead. Also, an operation which results in a number beyond the bounds of the integer type will return a float instead.

  • (disco)

    This topic is now listed. It will be displayed in topic lists.

    - At least the linking seems to work.

  • (disco) in reply to PJH

    And while we're on the subject of integer overflow and PHP - and for those that haven't seen it yet - this is talking about the source code to PHP:

    http://use.perl.org/use.perl.org/_Aristotle/journal/33448.html

    It starts off with:

    This is a tale of an integer overflow vulnerability (paraphrased for the purposes of the tale, as are all following snippets):

        dest = calloc(EXPR, sizeof(char));
    /* where EXPR is a calculation that is never checked for overflow */

    Of course, the maintainers of the software in question are studious and busy types and they would not let this go unfixed for long – they instituted a check to make sure that such a thing would never happen again:

        int size;

    size = EXPR;

    if (size > INT_MAX || size <= 0) {
        return NULL;
    }

    dest = calloc(size, sizeof(char));

    Marvelous! Now the code is safe...

    and goes downhill from there.

  • (disco)

    I actually had to write a progress bar in PHP yesterday... I don't think my solution is as elegant as their idea though.

        /**
     * Show the current progress
     *
     * @param int $current Current Progress
     * @param int $total   Total Work
     *
     * @return null
     */
    protected function showProgress($current, $total)
    {
        $percent = ($current / $total)*100;
        $barLength = 100;
        $barProgress = floor($percent);
        $barRemain = $barLength - $barProgress;


        $progress = sprintf("%3.2f%% %4d/%4d", $percent, $current, $total);

        $progress .= ' [' . str_repeat('#', $barProgress) . str_repeat(' ', $barRemain) . ']';
        $progress .= "\r";

        fwrite(STDERR, $progress);
}
```
  • (disco)

    The only WTF here is that a series of "if"s are being used to construct, what is in effect, a 7 bar LED display for use elsewhere.

    That the code is PHP is immaterial. That $count may or may not cause an integer overflow is equally immaterial.

    Because this is just a snippet of code within "something" else that will deal with integer overflows, and places to which 7bar LED displays can be shoved, etc etc.

    The only thing that could be a real WTF of the minor WTF (that this story is), that the 7bar LED is not scalable or mutable. But then it may not need be -"... we have 7 spare pixels / lights / blobs, let's do a quick progress bar..."

  • (disco) in reply to aliceif

    More importantly, is the threshold for strangeness portable? Spoiler: nope!

  • (disco) in reply to loose

    However, on further analysis, assuming the sample is complete:

    1. A "something" is "run".
    2. At some point during the run $count is initialised with 0.
    3. A WHILE LOOP is created that monitors the "truthfulness" of a TASK.
    4. TASK is initiated.
    5. If TASK does not complete.....well
    6. If TASK completes $count is incremented by 1 , and tested to see if it has a value of 50.
    7. The WHILE LOOP ENDS
    8. The "something" ends

    $count never gets to 50. $dots never gets constructed let alone displayed

    Even if "something" loops this snippet, the above holds true because $count gets reinitialised.

  • (disco)

    Everyone is so focused on overflow and other possible WTF's that I think the obvious was overlooked: $dot will be set to "." and that's it...for the whole life of the task.

    EDIT: Except, of course, for @loose, who posted just before I did (1-2 minutes) while I was scrolled to the top where I didn't see his message.

  • (disco) in reply to CoyneTheDup
    CoyneTheDup:
    Everyone

    :unamused:

    :wink:

  • (disco) in reply to loose

    Well, sorry, Your post appeared while I was writing and ...scrolled up toward the top of the messages. I didn't see it until after I posted. So much for the Discourse communication model, huh?

  • (disco) in reply to CoyneTheDup

    I know, that's why the wink.

    And yeah. I have that problem too 'cos I'm looking at the keyboard and not the screen.

  • (disco) in reply to loose
    loose:
    TASK is initiated.

    Could running in a separate thread, not stated in the article. And its state could be what's inside $task which could be set to false when the task finishes.

  • (disco) in reply to loose
    loose:
    $count never gets to 50.

    Huh? It's initialized to 0 before the while loop.

    I assume the snipped content is something like

    process_record_by_number($count);
if (no_more_records()) { $task = false; }

    What doesn't work is that $count is = 50 only once then, instead of being zeroed when it's equal to 50, so dots get constructed only once (and obviously, the display code is missing). Guess it's a line too many being snipped.

    Filed under: good old dots 1.0

  • (disco) in reply to Maciejasjmj

    Maybe we should ask @remy for the original code?

  • (disco) in reply to aliceif
    aliceif:
    Maybe we should ask @remy for the original code?

    @Samuel_Schoenberg, you can come out now, we know it's you.

  • (disco) in reply to Maciejasjmj

    That'd be one hell of a front page troll. I approve!

  • (disco) in reply to aliceif

    Whilst PHP can make system calls etc. It has to wait for them to complete - one of the many reasons for blank white screens in PHP Web Servers.

    To prevent the (PHP) world coming to a grinding halt, it has a settable maximum script execution time. But, this can be set to "forever" and it, perversely, does not account for time taken for system calls: Just internal operations like DB queries and array iterations and the like.

    That aside: If run the task is 1337 WTF commenting for take a peek at task and see how it is doing. Then, yeah. You have a potential infinite loop situation where the programming language's ability / methods to deal with integer overflow, could vastly alter the final result.

    @CoyneTheDup Ummm.... Looks like you were right. Somehow overflowing integers have become core to the topic.

  • (disco) in reply to aliceif
    aliceif:
    Could running in a separate thread, not stated in the article.

    In PHP? Not likely.

    But the exit condition sure is weird. Then again, PHP, given the quality of most PHP code, who knows what's happening there. Maybe $task is a poorly named array of tasks, getting cleared as each one is finished? if(array()) evaluates to FALSE in PHP...

  • (disco) in reply to Maciejasjmj

    Yes. $count will only ever be 50 once. In passing, so to speak, as it rapidly accelerates to INT_OVERFLOW / INFINITY / FILE_NOT_FOUND.

    Maciejasjmj:
    Huh? It's initialized to 0 before the while loop.

    Didn't I say that?

  • (disco)

    I'm pretty sure I've written something similar to this before, though it wasn't in PHP...

  • (disco) in reply to Onyx

    An array with zero elements will be evaluated as FALSE

  • (disco) in reply to Onyx

    Yes and,

    Onyx:
    `if(array())` evaluates to `FALSE` in PHP

    ===

    loose:
    An array with zero elements will be evaluated as FALSE

    evaluates to TRUE.

    And that, children, is how boolean logic works...

  • (disco) in reply to Onyx

    I think :sweat: ... I see what you did there. :relieved:

    Good job I'm not impulsive and respond immediately and violently to Trolls. Real or imagined. :laughing:

  • (disco) in reply to Onyx
    Onyx:
    In PHP? Not likely.

    Multi-threaded PHP? Is that a thing? (If it is, please pass the valium/strychnine mix…)

  • (disco)

    I have just realized: We have a catch 22 here.

    While task is running true, Schrodinger's progress indicator may or may not tell us it is running. But, as $task is started after entering the loop, it is by definition false SO.....

    $task will never enter the loop, but we can't be sure if it has or has not

    Perhaps TRWTF is that the WHILE loop should be a DO loop.

  • (disco) in reply to dkf

    I'm sure someone tried a creative hack to make it kinda possible already, since Apache (and presumably nginx) will run multiple PHP scripts in separate threads. You can't use that in your own PHP code, of course, but you do have exec... and PHP CLI...

    I better stop now before I get tempted...

  • (disco)

    I have dallied here too long. I have a meeting in 30 mins to present some proposals for some changes to code that need modernising but cannot be changed. And I need to doo three things to prepare myself:

    1. Have a fag (yeah, yeah, funny for some)
    2. Grab a coffee
    3. ....well it's personal, and I will not resort to toilet humour....
  • (disco) in reply to loose
    loose:
    Whilst PHP can make system calls etc. It has to wait for them to complete - one of the many reasons for blank white screens in PHP Web Servers.

    Well, there's popen. And proc_open.

  • (disco) in reply to PleegWat

    I have used them. But your script had better be better than immortal otherwise it dies an orphan and sooner or later there is no room left in the cemetery.

  • (disco) in reply to loose
    loose:
    But your script had better be better than immortal otherwise it dies an orphan and sooner or later there is no room left in the cemetery.

    You just need a zombie reaper. Duh!

  • (disco) in reply to CoyneTheDup
    CoyneTheDup:
    Everyone is so focused on overflow and other possible WTF's that I think the obvious was overlooked: $dot will be set to "." and that's it...for the whole life of the task.

    EDIT: Except, of course, for @loose, who posted just before I did (1-2 minutes) while I was scrolled to the top where I didn't see his message. :hanzo:

    FTFY

    :hanzo: Oh disgorge.

  • (disco) in reply to loose
    loose:
    'cos I'm looking at the keyboard and not the screen.

    lern2touchtype n00b!

  • (disco) in reply to Maciejasjmj

    This is what happens when you let Visual Basic programmers design languages.

  • (disco) in reply to another_sam
    another_sam:
    lern2touchtype n00b!

    Personally I'm sympathetic because while I used to be able to touchtype I now have to be able to cope with English and Russian keyboards in more than one size, and virtual keyboards. It may be possible to touchtype on a glass keyboard, but not by me it isn't.

  • (disco) in reply to kupfernigk
    [image]

    You can just talk to the MCP program from that console, so the keyboard's kind of redundant.

  • (disco) in reply to blakeyrat
    blakeyrat:
    the MCP program

    The Master Control Program Program? Is that what you use when you type your PIN number into the ATM machine?

  • (disco) in reply to NedFodder

    I didn't write the fucking screenplay, go away and leave me alone.

  • (disco) in reply to dkf
    dkf:
    Onyx:
    In PHP? Not likely.

    Multi-threaded PHP? Is that a thing? (If it is, please pass the valium/strychnine mix…)

    PHP has had a pthreads extension for a very long time, though I haven't used the new OO version (which, surprise surprise, looks a lot like Java's).

  • (disco) in reply to NedFodder
    NedFodder:
    The Master Control Program Program? Is that what you use when you type your PIN number into the ATM machine?

    I read it as the "Male chauvinist pig program". That's an AI that tries to keep women out of software engineering, probably by making disparaging remarks about their typing skills.

  • (disco) in reply to kupfernigk

    http://www.cnn.com/2015/06/10/europe/hunt-women-scientists/

  • (disco) in reply to another_sam

    It occurs to me that the (previously withheld) information that I have a 22" 10 point Touch Screen, and make occasional use of the screen keyboard. Could put a different spin on my relpy :stuck_out_tongue:

  • (disco) in reply to kupfernigk
    kupfernigk:
    That's an AI that tries to keep women out of software engineering, probably by making disparaging remarks about their typing skills.

    IIRC there were plenty of female characters in the computer world.

  • (disco) in reply to Dragnslcr
    Dragnslcr:
    PHP has had a pthreads extension for a very long time, though I haven't used the new OO version (which, surprise surprise, looks a lot like Java's).

    Good grief! What on earth are they doing in there? The options are:

    • Big honkin' lock protects resource management code. The Python way. Kiss performance goodbye if you're doing anything CPU-intensive. (Really. Python's threading is its own special collection of WTFs.)
    • No locks other than explicit ones. The C way. Better know what you're doing because if you don't, weithihaprdpngens.
    • The C# and Java ways are variants of this. The difference is that their libraries are more designed with threading in mind, and so have fewer fuck-ups. Still gotta be really careful.
    • Partitioned resource space, so that most threads never get the chance to even try to stomp on each others' toes. Lots of functional languages do this, but the post-child is probably Erlang. Many programmers seem to think that this is a bad idea as they get so attached to the C way, but it's the only way we know that actually seems to scale up in terms of our ability to figure out WTF is going on, and so it's what actually happens in very large scale deployments (deadlocks being a lot more benign to debug than cross-thread memory smashes).

    I'm guessing that they've gone for the C way. Because we're talking PHP and that can deliver by far the greatest :wtf: factor…

  • (disco) in reply to dkf
    dkf:
    Partitioned resource space, so that most threads never get the chance to even try to stomp on each others' toes. Lots of functional languages do this, but the post-child is probably Erlang. Many programmers seem to think that this is a bad idea as they get so attached to the C way, but it's the only way we know that actually seems to scale up in terms of our ability to figure out WTF is going on, and so it's what actually happens in very large scale deployments (deadlocks being a lot more benign to debug than cross-thread memory smashes).

    Quoted For Serious Truth -- why is it that people seem to have this misguided belief that threads are the One True Way to Parallelize?!?! (Hint: *nix systems did parallelization way before they got threading.)

  • (disco) in reply to tarunik

    There are cases where shared-memory threading is useful, such as some of the really heavy math processing we need at work when extracting the sense out of the data read off the lab instruments. Most people don't hit those cases. :smile:

  • (disco) in reply to tarunik

    Threading is actually the best way to parallelize. It just doesn't work well because software developers write code that is too dependent on each other. If everything were developed in a more independent manner, such as spawning a new instance of a database for every each thread. Then we could fully utilize parallel computing via threads.

  • (disco) in reply to xx_Micr0s0ftpwns_xx
    xx_Micr0s0ftpwns_xx:
    Threading is actually the best way to parallelize. It just doesn't work well because software developers write code that is too dependent on each other. If everything were developed in a more independent manner, such as spawning a new instance of a database for every each thread. Then we could fully utilize parallel computing via threads.

    You clearly have not had to bust out Helgrind on a threading bug before...

    (I agree with you re: we need more parallel code -- but threads have far too many footguns attached to them to be anywhere near the "best" way to do it. Hint: if you spawn a thread and it then proceeds to get itself hosed in an unrecoverable way, what do you do about it?)

    Also, FPT :warning:

  • (disco) in reply to xx_Micr0s0ftpwns_xx
    xx_Micr0s0ftpwns_xx:
    Threading is actually the best way to parallelize.

    Threading bugs are a complete COMPLAIN. Seriously awful. They're bad enough when those threads are in different processes (so at least the threads aren't stomping on each others' toes directly) but that's nothing by comparison with what happens when two threads that share memory decide to do a number on each other.

    What's more, most programmers have had no idea that threads were such a dangerous tool until pretty recently. That's because it's only recently that we've started to see true multicore systems become widespread. Emulating by context switching on a single CPU core is not the same at all; for one thing, when emulating you at least keep consistency between the CPU and the memory, even if not what the program was expecting. With real multicore systems, you lose that. Happy Fun Times ensue! :anguished:

Leave a comment on “Making Progress”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article