|
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 |
|
|
# ? May 28, 2024 00:21 |
|
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.)
|
# ? Jan 18, 2012 13:17 |
|
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 |
|
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: What are you talking about? Assuming that something() can return True and do_a_thing() can return False, code:
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 |
|
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 |
|
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 |
|
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.
|
# ? Jan 18, 2012 18:30 |
|
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 |
|
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?
|
# ? Jan 18, 2012 20:02 |
|
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. 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 |
|
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 |
|
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 |
|
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.
|
# ? Jan 18, 2012 22:13 |
|
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...
|
# ? Jan 18, 2012 22:24 |
|
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 Either way python 3 has gotten a lot further than perl 6 has, so we're getting better at managing this poo poo.
|
# ? Jan 18, 2012 22:47 |
|
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 |
|
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 |
|
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 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
|
# ? Jan 19, 2012 05:00 |
|
http://codepad.org/mQ1GHYeSphp:<?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 Apparently it's fixed in 5.3.
|
# ? Jan 19, 2012 05:34 |
|
Plorkyeran posted:http://codepad.org/mQ1GHYeS How does that even happen?
|
# ? Jan 19, 2012 05:50 |
|
You're really going to have to explain that one. Is the parser busted somehow?
|
# ? Jan 19, 2012 05:56 |
|
Plorkyeran posted:http://codepad.org/mQ1GHYeS This is amazing.
|
# ? Jan 19, 2012 06:04 |
|
Even better: http://codepad.org/8BAzFDfiphp:<?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 It's dependent on the whitespace at the beginning of the line, too.
|
# ? Jan 19, 2012 06:16 |
|
Internet Janitor posted:You're really going to have to explain that one. Is the parser busted somehow? http://codepad.org/Qmb0p9Kr php:<?php if (true) { function bar() { echo "true"; } } else { function bar() { echo "false"; } } bar(); http://codepad.org/E9R12nK0 php:<?php if (true) { function bar() { echo "true"; } } else { function bar() { echo "false"; } } bar(); I sort of suspect it's a codepad bug because even php isn't this
|
# ? Jan 19, 2012 06:18 |
|
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 |
|
I just tried Plorkyeran's first example in 5.1.2 and it did print 'php sucks'.
|
# ? Jan 19, 2012 06:53 |
|
Plorkyeran posted:http://codepad.org/mQ1GHYeS 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 |
|
Soup in a Bag posted:I just tried Plorkyeran's first example in 5.1.2 and it did print 'php sucks'. code:
|
# ? Jan 19, 2012 07:36 |
|
code:
|
# ? Jan 19, 2012 07:50 |
|
http://codepad.org/6zcbrr6cphp:<?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"; code:
|
# ? Jan 19, 2012 09:27 |
|
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 |
|
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:
Soup in a Bag fucked around with this message at 17:57 on Jan 19, 2012 |
# ? Jan 19, 2012 17:38 |
|
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 |
|
pythoncode:
code:
|
# ? Jan 19, 2012 18:18 |
|
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 |
|
tef posted:python Python operators are kind of weird in general (I think they changed this behavior for Python 3): code:
|
# ? Jan 19, 2012 19:43 |
|
tef posted:python code:
|
# ? Jan 19, 2012 19:50 |
|
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: -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:
Munkeymon fucked around with this message at 20:00 on Jan 19, 2012 |
# ? Jan 19, 2012 19:57 |
|
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:
|
# ? Jan 19, 2012 19:58 |
|
|
# ? May 28, 2024 00:21 |
|
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 |