Trigger question (PHP warning)
-
I keep doing mistakes like this one, getting weird results:
php -r ' error_reporting(0); $param = "rofl"; $params = ["param"=>$param]; /* ... later in a template ... */ echo $param["param"]; '
I can stare right at it and not see the error. What will it echo? [spoiler]It echoes the string "r".[/spoiler]
The example is extremely simplified. I know,
error_reporting(0)
is but that's just the conditions I'm operating under. Specifically, the templating engine works that way.
-
That's PHP type juggling for you. For even more amusement:
php -r ' error_reporting(0); $param = "rofl"; $params = ["3 little piggies" => $param]; echo $param["3 little piggies"]; '
-
php -r '
error_reporting(0);
$param = "rofl";
$params = ["3 little piggies" => $param];echo $param["3 little piggies"];
'At first I thought you didn't even understand the problem, then I noticed the numeral
-
I don't know what it will echo, but that typo is pretty obvious. This is why I prefer strongly typed languages so the compiler can detect my typos for me...
-
that typo is pretty obvious
When you know it's there.
strongly typed
I expected a strongly typed wonk to show up . And I agree it could have saved me a lot of time in this case.
-
When you know it's there.
+1 - the only times I have spent multiple hours debugging something is when I was blind to a simple typo like this. But when you present the code to us in this context we are actively looking for typos - when you're trying to find a bug in your own code you don't expect it to be a typo because the compiler usually catches that sort of mistake.
-
it could have saved me a lot of time in this case
What could also save you a lot of time is to not use the singular and plural form of a variable, and then not double-check that you did not mistype it.Also, "error_reporting(0)" should be used the same way as VB's "on error, resume next", which is NEVER.
But yes, I would really like it if PHP was a strongly typed language. Would save a lot of headaches.
-
TRWTF is always PHP when it comes to automatic type
conversionsfuckups as they always go down to integer for some reason.
-
TRWTF is always PHP
when it comes to automatic type conversionsfuckups as they always go down to integer for some reason.
Yes.
-
The PHP devs actually did try fixing this once. Using
$string[3]
to access a single character was deprecated in favor of$string{3}
for exactly this reason. They got so much pushback, though, that they had to give up the planned change.
-
The PHP devs actually did try fixing this once. Using
$string[3]
to access a single character was deprecated in favor of$string{3}
for exactly this reason. They got so much pushback, though, that they had to give up the planned change.or you know, maybe don't treat a string literal as a numeric indexer
-
or you know, maybe don't treat a string literal as a numeric indexer
I came across some ``joke'' code containing the ``expression'' 5["abcdef"] . How can this be legal C?
-
Exactly what you asked for. $param is not $params (obvious typo). PHP Strings can be accessed as an array. As $param = "rofl" is a string, accessing $param["param"] will result in the key "param" being evaluated to nothing i.e non existant so the next available "key" is 0.
From http://php.net/manual/en/language.types.array.php
...PHP arrays can contain integer and string keys at the same time as PHP does not distinguish between indexed and associative arrays...
...The key is optional. If it is not specified, PHP will use the increment of the largest previously used integer key...
Like every other programming language RTFM. Rightly or wrongly, it does exactly what it says on the tin.
-
Like every other programming language RTFM. Rightly or wrongly, it does exactly what it says on the tin.
That's true, but your reasoning is incorrect. The key being optional only applies to creating arrays or adding elements to an array.
$string[] = "a";
is a fatal error.As others have explained, accessing a string as if it were an array only allows integer keys, so PHP coerces the string to an integer. Since the string doesn't begin with anything that could be a number, PHP coerces it to the integer 0.
-
I usually prefer
&p[n]
overp + n
.
-
I'm the opposite because I never trust order of operations. What if it was
(&p)[n]
? (It isn't, but it's still scary)
-
The PHP devs actually did try fixing this once. Using
$string[3]
to access a single character was deprecated in favor of$string{3}
for exactly this reason. They got so much pushback, though, that they had to give up the planned change.Uhhhh, no, that's not what happened. { and } was originally the canonical way, then it was switched to [ ] and braces were supposed to be deprecated in PHP 6 but are still on the table.
Partially this is because {} syntax is used inside double quoted strings to encapsulate variables, partially this is because strings are really just byte arrays with handwaving goodness (much like PHP arrays are really a handwaving of ordered hashmaps and conventional arrays under one title)
-
Like every other programming language RTFM.
inb4 blakeyrant about having to read documentation
-
Is this the same kind of braindamage as Lua, where the interpreter encounters a typo, and thinks to itself: "Clearly, I need to instantiate a new global variable here, and keep on trucking. What do you mean, a warning would be nice?"
Filed under: i hate Lua so goddamn much...
-
that's why sensible php coders use
error_reporting(E_ALL | E_YES_I_MEAN_EVERYTHING_TYVM)
-
Like every other programming language RTFM.
With the exception you go :WTF: while reading it.
-
-
-
"param pam pam, param pam pam" (not sure if it makes sense in english, but in my language it's basically how you'd write a person rytmically humming to themselves in a way)
I keep doing mistakes like this one, getting weird results:
php -r '
yeah, that's a pretty big and silly mistake
-
-
-
-
The 'PHP' part excludes the 'sensible' part.
There's a reason my title is 'PHP enthusiast-masochist'
-
-
Triangle
The Codeless Code #161
A new monk of the Spider Clan had become lost in the Temple at night. After several twists and turns he had the misfortune of passing through a heavy door that locked behind him with an awful clack.
The monk found himself in the middle of a staircase that spiralled up the inside walls of a hollow tower. Timidly he peered over the railing. Far below lay a courtyard shrouded in darkness, while far above hung a black sky identical to the courtyard in every respect. The monk proceeded to ascend the stair, hoping to find either an egress or a more enlightening vantage point.
Every door he passed on his right was locked. The weary monk had almost resolved to go back down when he spied a shaft of light escaping from the cracks of a door ahead.
The door was labelled “123”. The monk hesitated, then knocked. There was a sound of footsteps, then the door swung open to reveal an old woman holding a lantern aloft.
“Yes? Yes? Yes?” said the nun impatiently.
“A dozen pardons for disturbing you at this late hour,” said the monk, feeling suddenly lightheaded from the long climb. “But... where am I?”
“The Abbey of Hidden Absurdities,” said the nun, “in the tower where PHP is written.”
“What is so absurd about PHP?” asked the monk.
The old nun laughed. “I take it you haven’t done much work in that language. Ask my older sister upstairs that question; she’s sure to help you.” The nun then slammed her door, locking it with a dreadful clack.
The monk sighed and continued up the stairs, around and around, eventually coming to another door with a light behind it.
This door was labelled “456A”. The monk knocked, and was answered by another old woman.
“A dozen pardons for troubling you at this late hour,” said the monk, “but what is so absurd about PHP?”
The old nun chortled. “I take it you haven’t done much string processing in that language. Ask my older sister upstairs that question; she’s sure to help you.” The nun then slammed her door, locking it with a terrible clack.
The monk grumbled and continued up the stairs, around and around, eventually coming to another door with a light behind it.
This door was labelled “78”. The monk knocked, and was answered by another old woman.
“A dozen pardons for intruding at this late hour,” said the monk, “but what is so absurd about PHP?”
The old nun cackled. “I take it you haven’t done much with the numerical comparison operators in that language. Ask my older sister upstairs that question; she’s sure to help you.” The nun then slammed her door, locking it with a horrible clack.
The monk groaned and continued up the stairs, around and around, eventually coming to another door with a light behind it.
This door was labelled “123”.
The monk hesitated, then knocked. There was a sound of footsteps, then the door swung open to reveal an old woman holding a lantern aloft.
“Yes? Yes? Yes?” said the nun impatiently.
“A dozen pardons for disturbing you at this late hour,” said the monk, feeling suddenly lightheaded. “But... where am I?”
[spoiler]
'123' < '456A' < '78' < '123'
[/spoiler]
-
Why not just
error_reporting(-1);
if you want all errors ever?
-
because the manual tells you that that is
-
Not quite:
Tip
Passing in the value -1 will show every possible error, even when new levels and constants are added in future PHP versions. The E_ALL constant also behaves this way as of PHP 5.4.
-
Using named constants is strongly encouraged to ensure compatibility for future versions. As error levels are added, the range of integers increases, so older integer-based error levels will not always behave as expected.
And while yes, technically, -1 will have that result, it's like much of PHP, it's by accident. You're supposed to use the named constants, which is guaranteed future compatible.
I mean, what if someone recompiles PHP on a 1's complement architecture? That magical -1 value now won't emit error messages of
E_ERROR
, it'll just fail silently. WhereasE_ALL
will work correctly.(inb4 rest of PHP won't work correctly on a 1's complement architecture )
-
You are correct, the -1 option is now redundant since 5.4, as "all" named constants are embraced with E_ALL. And yes using named constants is good practise because the underlying integer value could change. However, the possibility of more named constants being introduced that would not be captured by E_ALL is greater than the recompilation scenario, outside of a conscious individual choice, which is relatively low.
That said, it comes down to a personal choice based on circumstances and experience (or ignorance). I personally use named constants, I only use -1 if I think there is an error that I'm not being told about. I shall not go into the subject of scope and include files. I also, and many here would class it as a a :WTF:, create a "wrapper" function to pass a value onto error_reporting thereby giving me a single point of access for tinkering. This also means that I can customise the level of error reporting for any given scope.
-
Actually the chance of new constants being introduced that aren't in
E_ALL
is lower than ever.I can see there is some value in using -1 for brevity/quickness if you're in a hurry and just trying to get errors and you're not 100% sure which version of PHP is involved (where
E_ALL
may or may not necessarily embrace everything but those are cases people shouldn't have to deal with any more because fuck PHP 5.3)Personally at home (yes I do PHP for fun), I'm an
E_ALL
kind of guy. At work, I'm anE_ALL ^ E_DEPRECATED
kind of guy and everyone else iserror_reporting(0);
-
Also I just thought... are people trying to out-pendant me on PHP?
Surely that is TR
-
Who? Me? Consider any action on my part as strengthening your contribution / position / reputation
-
Dude... duuuuuuude. I use PHP... I have no position!
-
error_reporting(E_ALL | E_YES_I_MEAN_EVERYTHING_TYVM)
You forgot
E_REAL_MYSQLI_KITCHEN_SINK
-
This is why I prefer strongly typed languages...
Or at least linting.
I like javascript in the same way your family likes the grumpy great-uncle who keeps having operations to replace organs.
-
@Jarry said:
error_reporting(E_ALL | E_YES_I_MEAN_EVERYTHING_TYVM)
You forgot
E_REAL_MYSQLI_KITCHEN_SINK
I want to say you two are just fucking about, but since this is about PHP, I'm not so sure.
-
1. "param pam pam, param pam pam" (not sure if it makes sense in english, but in my language it's basically how you'd write a person rytmically humming to themselves in a way)
In English, "param pam pam" is the sound that the little drummer boy's drum made.
Or was it "parum pum pum"...
-
In English, "param pam pam" is the sound that the little drummer boy's drum made.
What about
T_PAAMAYIM_NEKUDOTAYIM
?...
-
that's why sensible php coders use
error_reporting(E_ALL | E_YES_I_MEAN_EVERYTHING_TYVM) ```</blockquote> That's not even a php-specific problem.
gcc -Wall -Wextra -Wpointer-arith -Wcast-align (more warnings)...
-
They don't say it in the error message now.
-
That aspect of the gcc frontend has always driven me crazy. If you don't want commonly annoying warnings in with your group of most warnings, fine, but don't call it "all". I wish they would use
-Wmost
instead.
-
It'd be nice to reliably have
-Wall-except-in-system-headers
…
-
System headers should have warnings completely disabled by default, don't they? That's always been my experience. You can even have library headers be treated as system headers for this purpose.
-
Most warnings, probably not all of them. Library headers get the same treatment if you use
-isystem
instead of-I
.
-
System headers should have warnings completely disabled by default, don't they?
Doesn't stop them invoking stupid warnings elsewhere however:
[sanity:root@centos zones]# cat test.c #include <stdio.h> #include <string.h> int main(void){ int index; for (index=0; index < 10; ++index) printf("%d\n", index); return 0; } [sanity:root@centos zones]# make -B test i686-pc-linux-gnu-gcc -Os -fomit-frame-pointer -march=pentium4 -pipe -I../include -O3 -I../include -O3 -Wall -Wstrict-prototypes -Wmissing-include-dirs -Wextra -pedantic -Wall -Wswitch-default -Wfloat-equal -Wshadow -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wno-multichar -Wredundant-decls -Wdisabled-optimization -Wno-unused -g -std=gnu99 -Wno-unused-function -Wno-variadic-macros -fno-strict-aliasing -ffunction-sections -fdata-sections -I/root/src/embedded/ccu4/branches/CCU4_V4_END_SANITY/os/net-snmp/include -Wall -L../lib -lnomad -lusb -lrt -lm -lnetsnmp -lndroute -lssl -lcrypto test.c -o test test.c: In function 'main': test.c:5: warning: declaration of 'index' shadows a global declaration /clfs_mod/usr/include/string.h:304: warning: shadowed declaration is here
(Though to be fair, having a function called
index
is probably more WTF here...)
-
That aspect of the gcc frontend has always driven me crazy. If you don't want commonly annoying warnings in with your group of most warnings, fine, but don't call it "all". I wish they would use -Wmost instead.
There was a time when-Wall
indeed meant all warnings. Then they added more warnings.