Trigger question (PHP warning)

gleemonk

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.

Maciejasjmj

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"];
'

gleemonk

@Maciejasjmj said:

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

LB_

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...

gleemonk

@LB_ said:

that typo is pretty obvious

When you know it's there.

@LB_ said:

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.

LB_

@gleemonk said:

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.

TimeBandit

@gleemonk said:

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.

hifi

TRWTF is always PHP when it comes to automatic type ~~conversions~~fuckups as they always go down to integer for some reason.

loopback0

@hifi said:

TRWTF is always PHP ~~when it comes to automatic type conversionsfuckups as they always go down to integer for some reason.~~

Yes.

Dragnslcr

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.

fwd

@Dragnslcr said:

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

PJH

@fwd said:

or you know, maybe don't treat a string literal as a numeric indexer

Question 6.11

I came across some ``joke'' code containing the ``expression'' 5["abcdef"] . How can this be legal C?

loose

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.

Dragnslcr

@loose said:

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.

PleegWat

I usually prefer &p[n] over p + n.

LB_

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)

Arantor

@Dragnslcr said:

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)

antiquarian

@loose said:

Like every other programming language RTFM.

inb4 blakeyrant about having to read documentation

tar

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...

Jarry

that's why sensible php coders use

error_reporting(E_ALL | E_YES_I_MEAN_EVERYTHING_TYVM)

hifi

@loose said:

Like every other programming language RTFM.

With the exception you go :WTF: while reading it.

Tsaukpaetra

@hifi said:

excepectation

FTFY
<a

sh_code

"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)

@gleemonk said:

I keep doing mistakes like this one, getting weird results:

php -r '

yeah, that's a pretty big and silly mistake

tar

@Jarry said:

sensible php coders

E_INTERSECTION_NOT_FOUND

PleegWat

@tar said:

@Jarry said:
sensible php coders

E_INTERSECTION_NOT_FOUND

Not even our very own @arantor?

Arantor

The 'PHP' part excludes the 'sensible' part.

There's a reason my title is 'PHP enthusiast-masochist'

swayde

@Arantor said:

masochist

50 shades of

TwelveBaud

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]

ben_lubar

Why not just error_reporting(-1); if you want all errors ever?

Arantor

because the manual tells you that that is

loose

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.

Arantor

PHP: error_reporting - Manual

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. Whereas E_ALL will work correctly.

(inb4 rest of PHP won't work correctly on a 1's complement architecture )

loose

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.

Arantor

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 an E_ALL ^ E_DEPRECATED kind of guy and everyone else is error_reporting(0);

Arantor

Also I just thought... are people trying to out-pendant me on PHP?

Surely that is TR

loose

Who? Me? Consider any action on my part as strengthening your contribution / position / reputation

Arantor

Dude... duuuuuuude. I use PHP... I have no position!

PJH

@Jarry said:

error_reporting(E_ALL | E_YES_I_MEAN_EVERYTHING_TYVM)

You forgot E_REAL_MYSQLI_KITCHEN_SINK

Shoreline

@LB_ said:

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.

Steve_The_Cynic

@PJH said:

@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.

anotherusername

@sh_code said:

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"...

PJH

@anotherusername said:

In English, "param pam pam" is the sound that the little drummer boy's drum made.

What about T_PAAMAYIM_NEKUDOTAYIM?...

PleegWat

@Jarry said:

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)...

Arantor

They don't say it in the error message now.

LB_

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.

dkf

It'd be nice to reliably have -Wall-except-in-system-headers…

LB_

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.

PleegWat

Most warnings, probably not all of them. Library headers get the same treatment if you use -isystem instead of -I.

PJH

@LB_ said:

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...)

Gąska

@LB_ said:

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.