Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

qntm posted:

You mean myqsl_real_escape_string(), of course.

Why do you say this? mysql_escape_string() and mysql_real_escape_string() are different things. In particular, mysql_escape_string() is worse from the point of view of security because it does not respect the connection character set. (Neither should be used, because the mysql_ functions are all obsolete.)

# ? Jan 18, 2012 12:42

Adbot: ADBOT LOVES YOU

# ? May 27, 2024 16:56

The Gripper: Sep 14, 2004; i am winner

Hammerite posted:

Why do you say this? mysql_escape_string() and mysql_real_escape_string() are different things. In particular, mysql_escape_string() is worse from the point of view of security because it does not respect the connection character set. (Neither should be used, because the mysql_ functions are all obsolete.)

What has obsoleted them? I haven't used PHP at all for years, but don't the mysql_* functions call the MySQL built-ins? Unless you mean using named parameters, though they've only made mysql_real_escape_string() obsolete for people that aren't writing raw SQL anymore.

# ? Jan 18, 2012 13:17

Malloc Voidstar: May 7, 2007; Fuck the cowboys. Unf. Fuck em hard.

No, mysql_escape_string is the broken and worthless one, mysql_real_escape_string is the safe one.

Edit: Oh hey, there's a new page here.

# ? Jan 18, 2012 13:38

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

LOOK I AM A TURTLE posted:

Vaguely on the subject of "input" in Python: One time a coworker of mine wrote code that essentially did this:
code:
def awesome_function():
    if something():
        input = do_a_thing()

    ...

    if input:
        <code that always gets executed because input never evaluates to false>

What are you talking about? Assuming that something() can return True and do_a_thing() can return False,

code:

In [1]: def something():
   ...:     return True
   ...: 

In [2]: def do_a_thing():
   ...:     return False
   ...: 

In [3]: def awesome_function():
   ...:     if something():
   ...:         input = do_a_thing()
   ...:     if input:
   ...:         print('input was True here')
   ...:         

In [4]: awesome_function()

In [5]:

It's almost certainly unintended (and a bug) that input defaults to true, but you seem to be wrong that the if input: code always executes.

EDIT: unless my assumptions are wrong and I just made an rear end out of myself, of course. That seems pretty likely in retrospect. It seemed like you were saying that input is always true because it's a built-in function, but you might have also meant that something() and do_a_thing() return values such that the code always executes. Either way, overwriting built-in names is often a surprise to people coming from other languages.

Lysidas fucked around with this message at 16:58 on Jan 18, 2012

# ? Jan 18, 2012 14:25

LOOK I AM A TURTLE: May 22, 2003; "I'm actually a tortoise."; Grimey Drawer

Lysidas posted:

What are you talking about?

That wasn't very clear, sorry. Yes, I'm referring to the fact that input always exists because it's a built-in, and do_a_thing() should've been called function_that_never_returns_false().

# ? Jan 18, 2012 14:46

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

The Gripper posted:

What has obsoleted them? I haven't used PHP at all for years, but don't the mysql_* functions call the MySQL built-ins? Unless you mean using named parameters, though they've only made mysql_real_escape_string() obsolete for people that aren't writing raw SQL anymore.

The mysql_ functions have been superseded by the mysqli_ functions. Many people would argue that the mysqli_ functions are themselves superseded by PDO, but at any rate, there is no reason whatsoever to use the mysql_ functions in new code. Depending on your point of view, they are either 1. obsolete or 2. doubly obsolete, because the thing that made them obsolete has itself been made obsolete.

Of course, every lovely web tutorial out there still teaches to use the mysql_ functions and so lots of new code is written using them. But those tutorials are wrong. Ideally, PHP would deprecate the mysql_ functions, but on the other hand, PHP.

# ? Jan 18, 2012 16:53

The Gripper: Sep 14, 2004; i am winner

Hammerite posted:

The mysql_ functions have been superseded by the mysqli_ functions. Many people would argue that the mysqli_ functions are themselves superseded by PDO, but at any rate, there is no reason whatsoever to use the mysql_ functions in new code. Depending on your point of view, they are either 1. obsolete or 2. doubly obsolete, because the thing that made them obsolete has itself been made obsolete.

Of course, every lovely web tutorial out there still teaches to use the mysql_ functions and so lots of new code is written using them. But those tutorials are wrong. Ideally, PHP would deprecate the mysql_ functions, but on the other hand, PHP.

Ah, just looked at mysqli_real_escape_string() in the source tree and it looks like it just wraps the original mysql_real_escape_string(). I thought there might have been some implementation difference that made the superseding mysqli_* safer.

# ? Jan 18, 2012 18:30

geonetix: Mar 6, 2011

PDO is fun, though. Because if for some reason your database connection fails, the PDO constructor sees no reason to not print its parameters along with the error. So when you create a quick script for something, you might end up with usernames and passwords in an error log. Or worse, on the screen of the user, Depending on how dirty you code or configure your webserver.

Yes, I know there are ways to properly deal with errors like that, but why in hell would you put parameters in the error-string?

# ? Jan 18, 2012 19:35

Nippashish: Nov 2, 2005; Let me see you dance!

geonetix posted:

Yes, I know there are ways to properly deal with errors like that, but why in hell would you put parameters in the error-string?

How else are you going to debug it? :v:

# ? Jan 18, 2012 20:02

ToxicFrog: Apr 26, 2008

xf86enodev posted:

Yup, there's lovely books out there but that's no coding horror. [...] Whatever the reasoning, a look into the documentation (and I'm not talking about stackoverflow some or guy's blog) and this would be a none-issue.

The fact that input() exists at all is a horror; the fact that so many books and tutorials recommend its use compounds that horror.

It is the mysql_escape_string of Python.

quote:

This is a coding horror. I mean, why would you do that? Are strings raw and ints are not?

It's obvious if you look at the documentation. :smug:

If you're using input(), and the user enters 100, it will eval("100") and get the int 100 back.

If the user enters Bob, it will eval("Bob") and get the value of the global variable Bob rather than the string "Bob" (and if there's no such global, it'll raise a NameError).

And if the user enters Bob Jones, it will raise a SyntaxError immediately.

# ? Jan 18, 2012 20:27

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Toady posted:

Has there ever been a published book of coding horrors and related mistakes of technology? Like a Darwin Awards of programming?

I am actually impressed with this thread for not responding for things like "any PHP programming book" or similar, because I immediately just scrolled past and was waiting for it.

I suppose in a general scheme if you look up "antipatterns" you'll see horrors in a more abstracted kind of way.

# ? Jan 18, 2012 20:31

Eliza: Feb 20, 2011

It should be noted that input() in its current form is abolished in Python 3.x though. While the name of the function still remains, what's behind it is essentially 2.x's raw_input(). Unless I am mistaken, that one always returns a string and will be recognised as such, so this particular horror is something belonging to an ending pathway.

# ? Jan 18, 2012 21:36

Malloc Voidstar: May 7, 2007; Fuck the cowboys. Unf. Fuck em hard.

Eliza posted:

It should be noted that input() in its current form is abolished in Python 3.x though. While the name of the function still remains, what's behind it is essentially 2.x's raw_input(). Unless I am mistaken, that one always returns a string and will be recognised as such, so this particular horror is something belonging to an ending pathway.

Python 3 will never replace Python 2

# ? Jan 18, 2012 22:13

Strong Sauce: Jul 2, 2003; You know I am not really your father.

Eliza posted:

It should be noted that input() in its current form is abolished in Python 3.x though. While the name of the function still remains, what's behind it is essentially 2.x's raw_input(). Unless I am mistaken, that one always returns a string and will be recognised as such, so this particular horror is something belonging to an ending pathway.

This whole discussion was started because of this difference... :psyduck:

# ? Jan 18, 2012 22:24

tef: May 30, 2004; -> some l-system crap ->

Aleksei Vasiliev posted:

Python 3 will never replace Python 2

I dunno. Once the big libraries are across (NumPy, Django) and stable I can see python 3 replacing 2 a little more. Old versions of programming languages never go away, they just curl up and fester in machines for years to come. Language migrations do not happen quickly.

From a library maintainer perspective - switching from 2 to 3 can involve forking the library (having to support 2.5 can make it a bit problematic). There is also some fun about CPython changes.

From an end user perspective, switching from python 2 to 3 is a little bit like switching from python to ruby - the semantics and libraries have changed and the advantages don't make up for the effort it takes to switch.

I think python 3 may find its way if it is as easy to write forwards compatible code using from __future__. It would be a lot easier if there wasn't two runtimes as well :smith:

Either way python 3 has gotten a lot further than perl 6 has, so we're getting better at managing this poo poo. :unsmith:

# ? Jan 18, 2012 22:47

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

tef posted:

I dunno. Once the big libraries are across (NumPy, Django) and stable I can see python 3 replacing 2 a little more.

NumPy already works flawlessly with Python 3, as does IPython, SciPy, NetworkX, BioPython, CVXOPT, etc. etc. etc. I use Python 3 exclusively in my research. It's really coming along. Hell, the development version of matplotlib even seems to work. (I tried a released version a few weeks ago, maybe 1.1.0, and setup.py build crashed and burned. Looks like it's actually building successfully now!)

I'd guess that Django will support Python 3 within a year, two at most. It also looks like (hopefully) Ubuntu 14.04 LTS will only install Python 3 by default, with 2.7 as optional and semi-deprecated. Arch already does this; if you install Python you get Python 3. RHEL will probably be on 2.6/2.7 for the next 20 years though.

# ? Jan 18, 2012 22:59

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

The big problem with Python 3, for me at least, is that its handling of bytes is really, really terrible. Read this bug report, for instance. The incorrect responses from the Python maintainers are embarrassing.

# ? Jan 19, 2012 00:00

tef: May 30, 2004; -> some l-system crap ->

Lysidas posted:

NumPy already works flawlessly with Python 3, as does IPython, SciPy, NetworkX, BioPython, CVXOPT, etc. etc. etc. I use Python 3 exclusively in my research. It's really coming along. Hell, the development version of matplotlib even seems to work. (I tried a released version a few weeks ago, maybe 1.1.0, and setup.py build crashed and burned. Looks like it's actually building successfully now!)

I'll admit I haven't been following this closely enough but yours is the first success story I have seen :toot:

I might have been mixing it up in my head with PyPy support for NumPy.

Lysidas posted:

I'd guess that Django will support Python 3 within a year, two at most. It also looks like (hopefully) Ubuntu 14.04 LTS will only install Python 3 by default, with 2.7 as optional and semi-deprecated. Arch already does this; if you install Python you get Python 3. RHEL will probably be on 2.6/2.7 for the next 20 years though.

If I can get reliable qt bindings for python 3 I would jump too :sigh:

# ? Jan 19, 2012 05:00

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

http://codepad.org/mQ1GHYeS

php:

<?php

if (true) { function foo() { echo "php"; } }
else { function foo() { echo " sucks"; } }

foo();

if (true) {
    function bar() { echo "php"; }
} else {
    function bar() { echo " sucks"; }
}

bar();

Output:
php sucks

Apparently it's fixed in 5.3.

# ? Jan 19, 2012 05:34

Opinion Haver: Apr 9, 2007

Plorkyeran posted:

http://codepad.org/mQ1GHYeS

php:

<?php

if (true) { function foo() { echo "php"; } }
else { function foo() { echo " sucks"; } }

foo();

if (true) {
    function bar() { echo "php"; }
} else {
    function bar() { echo " sucks"; }
}

bar();

Output:
php sucks

Apparently it's fixed in 5.3.

How does that even happen?

# ? Jan 19, 2012 05:50

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

You're really going to have to explain that one. Is the parser busted somehow?

# ? Jan 19, 2012 05:56

Look Around You: Jan 19, 2009

Plorkyeran posted:

http://codepad.org/mQ1GHYeS

php:

<?php

if (true) { function foo() { echo "php"; } }
else { function foo() { echo " sucks"; } }

foo();

if (true) {
    function bar() { echo "php"; }
} else {
    function bar() { echo " sucks"; }
}

bar();

Output:
php sucks

Apparently it's fixed in 5.3.

This is amazing.

# ? Jan 19, 2012 06:04

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Even better: http://codepad.org/8BAzFDfi

php:

<?php

if (true) { function foo() { echo "php"; } }
else { function foo() { echo " sucks"; } }

foo();

if (true) { function bar() { echo "php"; } }
  else { function bar() { echo " sucks"; } }

bar();

Output:
php sucks

It's dependent on the whitespace at the beginning of the line, too.

# ? Jan 19, 2012 06:16

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Internet Janitor posted:

You're really going to have to explain that one. Is the parser busted somehow?

I have no loving clue. Here's a slightly simpler case:

http://codepad.org/Qmb0p9Kr

php:

<?php
if (true) { function bar() { echo "true"; } }
else {
function bar() { echo "false"; } }
bar();

Output: false

http://codepad.org/E9R12nK0

php:

<?php
if (true) { function bar() { echo "true"; } }
else { function bar() { echo "false"; } }
bar();

Output: true

I sort of suspect it's a codepad bug because even php isn't this :psyduck:

# ? Jan 19, 2012 06:18

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

Works as expected on ideone (php 5.2.11), so I think you're probably right in calling this a codepad bug.

# ? Jan 19, 2012 06:48

Soup in a Bag: Dec 4, 2009

I just tried Plorkyeran's first example in 5.1.2 and it did print 'php sucks'.

# ? Jan 19, 2012 06:53

Sinestro: Oct 31, 2010; The perfect day needs the perfect set of wheels.

Plorkyeran posted:

http://codepad.org/mQ1GHYeS

php:

<?php

if (true) { function foo() { echo "php"; } }
else { function foo() { echo " sucks"; } }

foo();

if (true) {
    function bar() { echo "php"; }
} else {
    function bar() { echo " sucks"; }
}

bar();

Output:
php sucks

Apparently it's fixed in 5.3.

The Something Awful Forums > Discussion > Serious Hardware / Software Crap > The Cavern of COBOL > Coding horrors: show me where on this anatomically correct doll where PHP touched you

# ? Jan 19, 2012 07:29

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Soup in a Bag posted:

I just tried Plorkyeran's first example in 5.1.2 and it did print 'php sucks'.

code:

jstpierre@jstpierre-lappy ~/Source/php/php-5.1.2 $ cat ~/dumb.php
<?php

if (true) { function foo() { echo "php"; } }
else { function foo() { echo " sucks"; } }

foo();

if (true) {
    function bar() { echo "php"; }
} else {
    function bar() { echo " sucks"; }
}

bar();
jstpierre@jstpierre-lappy ~/Source/php/php-5.1.2 $ ./sapi/cli/php ~/dumb.php 
phpphp

Nope. Not sure if it's related to config or my compile-time settings, in which case it would be extremely strange. Seems to be a codepad bug.

# ? Jan 19, 2012 07:36

McGlockenshire: Dec 16, 2005; GOLLOCKS!

code:

[mcg@old-dev ~]$ php -v
PHP 5.0.4 (cli) (built: Nov  8 2005 08:27:12)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.4-dev, Copyright (c) 1998-2004 Zend Technologies
[mcg@old-dev ~]$ php -a
Interactive mode enabled

<?php

if (true) { function foo() { echo "php"; } }
else { function foo() { echo " sucks"; } }

foo();

if (true) {
    function bar() { echo "php"; }
} else {
    function bar() { echo " sucks"; }
}

bar();Segmentation fault

Goddamnit, PHP.

# ? Jan 19, 2012 07:50

Sebbe: Feb 29, 2004

http://codepad.org/6zcbrr6c

php:

<?php

$choices = "";

if (true) { function foo() { echo "php"; }; $choices .= "a"; }
else { function foo() { echo " sucks"; }; $choices .= "b"; }

foo();

if (true) { function bar() { echo "php"; } $choices .= "c"; }
 else { function bar() { echo " sucks"; } $choices .= "d"; }

bar();

echo "\n$choices";

Output:

code:

php sucks
ac

How does that even... :psyduck:

# ? Jan 19, 2012 09:27

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Actually, that's sort of reasonable - it suggests that it's not the if (true) that's broken, but rather function definitions in if statements. If it's hitting an uninitialized variable or something then inconsistent results based on things that shouldn't matter and McGlockenshire's segfault make perfect sense.

# ? Jan 19, 2012 15:12

Soup in a Bag: Dec 4, 2009

Okay, I don't know what the gently caress. My dumb.php is the same as Suspicious Dish's and PHP's behavior differs among "php dumb.php", "php -a", and "php". Though I avoid PHP whenever possible, so maybe I did it wrong.

code:

user@server ~ $ php -v
PHP 5.1.2-pl1-gentoo with Hardening-Patch 0.4.8 (cli) (built: Jul 18 2006 12:19:10)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies

user@server ~ $ php dumb.php 
phpphpuser@server ~ $ 

user@server ~ $ php -a
Interactive mode enabled

php > if (true) { function foo() { echo "php"; } }
php > else { function foo() { echo " sucks"; } }

Parse error: syntax error, unexpected T_ELSE in php shell code on line 1
php > 
php > foo();
php
php > 
php > if (true) {
php {     function bar() { echo "php"; }
php { } else {
php {     function bar() { echo " sucks"; }
php { }
php > 
php > bar();
php
php > 
user@server ~ $ php
<?php

if (true) { function foo() { echo "php"; } }
else { function foo() { echo " sucks"; } }

foo();

if (true) {
    function bar() { echo "php"; }
} else {
    function bar() { echo " sucks"; }
}

bar();
php sucks

vvv Don't get me started. If I wasn't afraid of being found out, my job could sustain this thread...indefinitely, I'd guess.

Soup in a Bag fucked around with this message at 17:57 on Jan 19, 2012

# ? Jan 19, 2012 17:38

Impotence: Nov 8, 2010; Lipstick Apathy

I think the real horror there is running a version of PHP vulnerable to so many fun, hilarious things and ..that old

# ? Jan 19, 2012 17:50

tef: May 30, 2004; -> some l-system crap ->

python

code:

>>> 2 > 1 is True
False

hmmmmmmmm

code:

>>> 2 > (1 is True)
True
>>> (2 > 1) is True
True

is can be chained along with in :q:

# ? Jan 19, 2012 18:18

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Biowarfare posted:

I think the real horror there is running a version of PHP vulnerable to so many fun, hilarious things and ..that old

it's okay it's hardened-php i'm sure it has no critical vulnerabilities

# ? Jan 19, 2012 18:32

LOOK I AM A TURTLE: May 22, 2003; "I'm actually a tortoise."; Grimey Drawer

tef posted:

python

is can be chained along with in

Python operators are kind of weird in general (I think they changed this behavior for Python 3):

code:

>>> None < False == 0 < True == 1 < {} < [] < '' < '0' < ()
True

Why is the empty tuple so big?

# ? Jan 19, 2012 19:43

The Gripper: Sep 14, 2004; i am winner

tef posted:

python
code:
>>> 2 > 1 is True
False
hmmmmmmmm
code:
>>> 2 > (1 is True)
True
>>> (2 > 1) is True
True
is can be chained along with in

Why is this? It's almost like the parenthesis changes it from a value of True to a reference to True. Similar weirdness with:

code:

>>> 55555 is 55555
True
>>> 55554+1 is 55555
False
>>> 1+1 is 2
True

(I know this is a misuse of 'is', but I expected the same behavior in the 55554+1 line as with the 1+1.)

# ? Jan 19, 2012 19:50

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

The Gripper posted:

Why is this? It's almost like the parenthesis changes it from a value of True to a reference to True. Similar weirdness with:
code:
>>> 55555 is 55555
True
>>> 55554+1 is 55555
False
>>> 1+1 is 2
True
(I know this is a misuse of 'is', but I expected the same behavior in the 55554+1 line as with the 1+1.)

-10? through 256 are created when you start the interactive interpreter. 555555 isn't. There's also some implementation dependent weirdness that can happen:

code:

'A' is 'A'

Is always False in IronPython and True in CPython, for example, presumably because there are more objectivists working on CPython, but who knows

Munkeymon fucked around with this message at 20:00 on Jan 19, 2012

# ? Jan 19, 2012 19:57

LOOK I AM A TURTLE: May 22, 2003; "I'm actually a tortoise."; Grimey Drawer

The Gripper posted:

Why is this? It's almost like the parenthesis changes it from a value of True to a reference to True. Similar weirdness with:
code:
>>> 55555 is 55555
True
>>> 55554+1 is 55555
False
>>> 1+1 is 2
True
(I know this is a misuse of 'is', but I expected the same behavior in the 55554+1 line as with the 1+1.)

code:

>>> 255+1 is 256
True

>>> 256+1 is 257
False

...that's interesting.

# ? Jan 19, 2012 19:58

Adbot: ADBOT LOVES YOU

# ? May 27, 2024 16:56

leterip: Aug 25, 2004

The Gripper posted:

Why is this?

Python Reference posted:

Formally, if a, b, c, ..., y, z are expressions and op1, op2, ..., opN are comparison operators, then a op1 b op2 c ... y opN z is equivalent to a op1 b and b op2 c and ... y opN z, except that each expression is evaluated at most once.

So (2 > 1 is True) evaluates to (2 > 1 and 1 is True) which is False. The parenthesis stop the expansion. (This one took me a while to figure out.)

# ? Jan 19, 2012 20:13

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »