WishUnderflow
-
Yeah, but what if the counter gets decremented before the wish gets granted, huh?
I love being a nerd
-
I had a visceral reaction to this because obviously the wish count should be decremented before the wish takes place. Even though I can't think up a convincing technical argument for it.
I had a visceral reaction to this because obviously the wish count should be decremented before the wish takes place.
Why? Shouldn't you decrement the limited resource the user has access to in case the thing you are doing fails?
-
If there's parallelism/async involved, then there definitely is an argument to decrement first, execute later. Otherwise you could make a wish for the genie to just wait for an hour and then make as many wishes as you want within that hour.
But how can you decrement a future dated wish, since you can't guarantee nothing will happen that prevents the genies ability from executing said wish? E.g. i mean like telling the Genie to do something 5 days from now, not your example which would begin immediately after making said wish.
-
This post did not contain any content.
Then you find out the genie uses a signed data value and you now owe him a wish. You're not granted magic. You're compelled to grant the wish. The only restrictions on the genie's wish is that it must be within your (soft, squishy) mortal power.
I can imagine you being reset to the point of the genie's wish every time you die (naturally or otherwise) without succeeding. This could well turn into a Groundhog Day type situation.
-
This post did not contain any content.wrote on last edited by [email protected]
Should've been "make -1 wishes" 0 is 0
Edit:oh I get it. First the gene fullfill the wish then subtract one from the 0 wishes.
-
But how can you decrement a future dated wish, since you can't guarantee nothing will happen that prevents the genies ability from executing said wish? E.g. i mean like telling the Genie to do something 5 days from now, not your example which would begin immediately after making said wish.
You decrement the wish counter first, execute the action (which includes waiting those 5 days), and if it fails you increment the counter back. Something like this:
wishes = wishes - 1; executeWish(wish).unwrap_or_else(|_| { wishes = wishes + 1; })?This way if the action fails in the future, you get a wish back and can ask something else.
-
This post did not contain any content.
Now make it 2.5 wishes. Now 0.9. Now 999.
-
Yeah, but what if the counter gets decremented before the wish gets granted, huh?
I would assume this to be the case since you cannot un-utter a wish—once you say it, it is counted as a wish before it's fulfilled.
If the counter is decremented only after the wish is fulfilled, then this means you can go back on wishes because they don't count until they're fulfilled, which goes against the lore.
-
Now make it 2.5 wishes. Now 0.9. Now 999.
Found the QA tester.
-
Now make it 2.5 wishes. Now 0.9. Now 999.
After you made it 0.9 you no longer have enough wishes left.
-
This post did not contain any content.
Wouldn't it depend on the order of operations, you'd think even vibe coding a genie would still have the sense to lower the counter before granting the wish.
So logically
Wishes = 3
Make wish count zero.
*wish used, wish count 2
Wish applied, wish count 0
-
I would assume this to be the case since you cannot un-utter a wish—once you say it, it is counted as a wish before it's fulfilled.
If the counter is decremented only after the wish is fulfilled, then this means you can go back on wishes because they don't count until they're fulfilled, which goes against the lore.
Nah theres just no process for undoing your submission.
It doesn't matter when it's decremented if you can't interrupt the process, anyway.
In a code sense we pause for input, feed it to the wishmaker function, and pause until the thread returns, then decrement.
We could decrement first, also, but neither violates the rules.
-
Yeah, but what if the counter gets decremented before the wish gets granted, huh?
Genie in the OP image would've said "OK you now have 0 wishes".
Since he said 255, my interpretation is a valid solution.
Of course, if we're talking hypothetical wish gaining prevention methods, I'd just have a check before,
previous_wishes = wishes;
{Do all the wish things. wishes ends up with a 255 because of our shenanigans}
If(wishes>=previous_wishes) wishes = previous_wishes-1;
;If the current number of wishes isnt less than the old number of wishes, set it to the old number and subtract 1
If(wishes==0) {/*TODO: write function to end wish giving sequence*/}
-
Then you find out the genie uses a signed data value and you now owe him a wish. You're not granted magic. You're compelled to grant the wish. The only restrictions on the genie's wish is that it must be within your (soft, squishy) mortal power.
I can imagine you being reset to the point of the genie's wish every time you die (naturally or otherwise) without succeeding. This could well turn into a Groundhog Day type situation.
Ooh I would gladly avenge everyone who had wishes before me by being very maliciously compliant.
-
This post did not contain any content.
Me: I wish you to tell me truthfully, exactly how many wishes I have remaining.
Genie: *crashes* -
I would assume this to be the case since you cannot un-utter a wish—once you say it, it is counted as a wish before it's fulfilled.
If the counter is decremented only after the wish is fulfilled, then this means you can go back on wishes because they don't count until they're fulfilled, which goes against the lore.
wrote on last edited by [email protected]Well, not entirely. There are cases for which a person utters the wish and it is not counted. "I wish for a million wishes!"
The standard is for the genie to explain the exceptions but not count that as a wish.
Now, it could decrement the count after this check. But just decrementing the count before verification would be sloppy.
But, then again, basic verification would also include checking that wishes_remaining <= MAX_WISHES.
Which, I think is a pretty standard check for genie's. Given that that constant has remained at 3 since their beta days and exceptions are thrown for violations of this rule.
-
This post did not contain any content.
Genie: these wishes are of type signed int64. you now have -1 wishes. you owe me a wish; i wish to be free.
-
Wouldn't it depend on the order of operations, you'd think even vibe coding a genie would still have the sense to lower the counter before granting the wish.
So logically
Wishes = 3
Make wish count zero.
*wish used, wish count 2
Wish applied, wish count 0
It seems logical to decrement after the wish is granted, imo. Just causes issues in this particular case...
-
If there's parallelism/async involved, then there definitely is an argument to decrement first, execute later. Otherwise you could make a wish for the genie to just wait for an hour and then make as many wishes as you want within that hour.
What if one of the threads crashes while executing the wish? I demand warranty!
-
It seems logical to decrement after the wish is granted, imo. Just causes issues in this particular case...
Dunno, I know enough duplicate exploits in games to know giving the effect then reducing the item, is a pretty common source of duplication hacks/bugs.
I guess it comes down to which is the designer is more afraid of happening, the chance of a wish being expended but not granted, or granted without expending.
Then again based on disney's aladin, tricking the genie into rescuing him without using a wish, it does seem practical to assume that the genie errors on the side of granting without expending.
