|
code:
TextMarkup entries live in their own table. __construct takes the $id and $type arguments, which act as a compound primary key in the table. __construct is also what is responsible for checking and writing to the cache. The object has a set of methods that convert text based on the selected markup type, such as BBCode, Wiki markup, HTML sanitization, etc. It needs a little cleaning up, but it's not bad. Oh, except it can't save itself. No, saving is done by the thing referencing the TextMarkup. By extracting the properties directly from the object and calling a static method to produce the original text. The external code then performs the SQL required to update the table, and conveniently does not clear the cached entry. But that isn't the horror. The horror is that this code has been in production for probably three or four years now, as-is. And somehow the bug (the fact that the cache is never updated) has been entirely invisible. In fact, I can't replicate it on the development environment at all, even though I'm the only one on the team that actually has the audacity to have memcache enabled in my environment. I ended up finding it when I bounced memcached on live, thinking to myself "na, this can't be it." Sigh. The only change needed to uncover this bug is that the live application is now looking at a different database server. I changed this in the one and only place it needed to be changed (in loving /etc/hosts). I don't understand how making this one change could possibly uncover a bug that has existed since the beginning of time when there is no common code involved at all. I hate this codebase. McGlockenshire fucked around with this message at 02:07 on Jan 24, 2009 |
# ¿ Jan 24, 2009 02:04 |
|
|
# ¿ Apr 26, 2024 14:22 |
|
UberJumper posted:
Part of me wants to see what b() and c() are. That code almost looks like it came out of a bytecode "decompiler."
|
# ¿ Feb 22, 2009 21:00 |
|
code:
No, really, my Java is rusty, and I have no idea what in the flying hell this means or is doing. He's casting "60D" to an int. But what the hell is 60D? A constant? I didn't think any sane programming language let you start constants with numbers, though that would also explain the "22D"... and that scares me. Did this guy learn to code in BASICA, and just never got over insane variables?
|
# ¿ Feb 23, 2009 03:28 |
|
TRex EaterofCars posted:xxxxD forces the number xxxx to a double. Can do the same with xxxxF for float.
|
# ¿ Feb 23, 2009 07:40 |
|
UberJumper posted:
|
# ¿ Feb 24, 2009 05:05 |
|
Otto Skorzeny posted:Behead those who say K&R is a violent religion Durka durka One True Brace Style jihad!
|
# ¿ Feb 27, 2009 02:32 |
|
It can be further reduced to this. Yes, it should work. I think. Erk, been too long.code:
|
# ¿ Jun 11, 2009 08:42 |
|
geetee posted:The best trolls are the ones that aren't obvious. gently caress your brace stripping ways It's the closest I can get to Perl's "expression if/unless expression" syntax. PHP!
|
# ¿ Jun 11, 2009 20:29 |
|
quote:Forgive my naivety, but what would this achieve? Well, let's find out! code:
code:
Okay, quick Perl tutorial. $a and $b in the sort routine are the "left" and "right" values to compare. The routine returns -1, 0, or 1 to indicate the sorting order of the values. Now, assuming that the assign returns some value (either the previous or new value of $a), given the list I provided, we'd get one negative, one zero, and lots of positives. Let's also assume that values greater than 1 are considered a 1. Much to our collective horror, the values are modifiable within the sort. I have no idea who thought this was a good idea, but I'm going to give him or her a piece of my mind should we ever meet. So, during the sort, the left value is always being modified. I'm not sure what method Perl uses internally to perform the sort, the results are the same every time on Perl 5.10.0. Why would anyone do this? For shits and giggles, I modified the sort line: code:
code:
I love Perl! McGlockenshire fucked around with this message at 10:41 on Jun 16, 2009 |
# ¿ Jun 16, 2009 10:38 |
|
We have a code test that we make candidates take before we consider giving them an interview. We ask them to build a little song database, give it at least three specific views of the data, and to switch between views using a modern JS library. Nobody, not one person, has ever passed the test. Not even me. This gem came in today, in part of the submitter's home-grown application code, including a class that wraps PHP's mysql_* functions: php:<? class songs_global { // ... public function fixString($Instring=NULL){ //Use this on any text you pass into the database. //Queries will fail if any variable contains a single quote. //First replaces addslashes /' with just a single quote, //then replaces single quotes with two single quotes. //ie bee/'s knees or bee's knees becomes bee''s knees, //then uses the first quote to escape the second //so INSERT 'bee''s knees' is interpreted as //INSERT 'bee's knees' if($Instring == NULL){ return NULL; } $OutString = str_replace("'", "''", str_replace("\'", "'", $Instring)); return $OutString; }?> The entire "global" class is a horrible, horrible thing that makes me want to shoot him. Thankfully I don't have a gun, I'll just get to ask him what the gently caress he's thinking if the boss decides he's worth interviewing. McGlockenshire fucked around with this message at 23:50 on Aug 18, 2009 |
# ¿ Aug 18, 2009 23:41 |
|
On his own demo for his own code, submitting: "Testy'test"test" transforms into \"Testy\'test\"test\" I have no idea what's even going on. I think he might have magic_quotes_gpc enabled. (Non-PHP people: magic_quotes_gpc is a misfeature that automatically tries to escape quotes in all input.)
|
# ¿ Aug 19, 2009 00:48 |
|
Factor Mystic posted:It's indicative of 1:1 mental modelling to code, and shows that to him the code only makes sense if it explicit returns "true" somewhere and "false" somewhere else. There's no jump to the higher order of thinking where the return value of the call can be returned, or once you've achieved that, possibly scrapping the helper function altogether because you realize the inner call does everything you need. Another possible explanation is that at some point, the code actually did more work itself. Later, the manual code was replaced with a call to the other method, and the rest was left alone.
|
# ¿ Nov 16, 2009 00:11 |
|
Oh my gods, it's practically INTERCAL.
|
# ¿ Jan 8, 2010 01:30 |
|
Jonnty posted:Does that imply that there are programs that somehow rely on the buggy behaviour of that escape function, then? mysql_real_escape_string requires an active connection to MySQL. The potentially broken non-real one does not. This is a problem to some programs that were designed by newbies/idiots/idiot newbies. Again, though, real programmers use prepared statements / parameterized queries. This of course explains why everyone learning PHP does so from a ten year old guide that treats 5.0 as scary and new and uses mysql_ by default. Also, quote:If there's no sales tax then sweet! none will be added. However now our application is relying on undefined variables being permitted. Worse, your application may well be designed for PHP4 and register_globals. McGlockenshire fucked around with this message at 05:57 on Jun 11, 2010 |
# ¿ Jun 11, 2010 05:53 |
|
NotShadowStar posted:Perl does exactly the same thing. This is the weird poo poo that happens when you don't discern integers and strings. Or you don't know the conversio rules...
|
# ¿ Sep 25, 2010 21:15 |
|
NotShadowStar posted:I shouldn't have to because "100buttsfart" == 100 makes no intuitive logical sense. Ever. Except that is how pretty much every language that can convert a string to an integer acts. You are basically writing (int)"100lolbutts" == 100. Write the same construct in Java or C#, you'll probably get the same result. Garbage in, garbage out. If you want different behavior, ask for it expressly.
|
# ¿ Sep 25, 2010 23:18 |
|
NotShadowStar posted:Erm, no. That's not at all how non-batshit languages work. But how do other languages parse strings that should be numbers, but might not be, while still making a best effort? There's still a 100 there, how do I get to it? Other than pulling out a regex and doing it manually, I mean. Maybe it's years of abuse at the horrible hands of PHP, but I really don't see the nature of the offense here.
|
# ¿ Sep 27, 2010 05:34 |
|
baquerd posted:You're dropping data with no warning or logging. ToxicFrog posted:Coercion is the real horror. These are very good points. But... if my language of choice raised an exception when I passed it contaminated data rather than make a best effort to clean it up, I don't think I'd prefer that language for much longer. Sometimes it's easiest to just say "gently caress you, you're an int" to a string and ignore the fallout, even if there is potentially a loss of data. I mean, hell, I force expected integer data to an int as input validation. If you put garbage into a field, you get a zero. If that field doesn't accept a zero, you get an error. I hate what PHP has done to me. This feels ... unclean now.
|
# ¿ Sep 27, 2010 06:10 |
|
Shavnir posted:Weren't you the one that said "Garbage in, garbage out"? In PHP and Perl "Your face is on fire" has no sane numeric interpretation, you get nothing if you take it in numeric context. It seems other languages would prefer that both of these are errors. I was operating under the assumption that when asked expressly to cast the string as an integer, they'd make the same best effort that PHP and Perl do. That assumption was wrong. I would consider the string "100 but not one hundred" to be garbage, but I'd rather get the 100 out of it, or even a zero, than an exception. e: baquerd posted:Enter a donation amount: 100iamacat It depends on how strictly I deal with the field, and whether or not there's any client-side validation first. Let's assume there is, but the client is malicious and is also a cat, so "100iamacat" gets passed in. If I'm only allowing whole dollar amounts (no cents), I'm very likely to not bother with a regex and just cast it after trimming. Because I work with PHP and Perl, I'd get integer 100 out of that under these specific conditions, with no errors and a warning if it's Perl. If I wasn't dealing with whole numbers, there'd probably be a regex there to either validate the format or remove anything other than [\d\.], which would also yield 100 in this scenario regardless of what language was used. Now that I think about it, this is a bad example. If this was a public page instead of an internal page (where I can speak to my users face to face), I'd probably also end up with the nuke-everything-but-the-numbers regex. Public users tend to be stupid, I can easily see a "how much would you like to donate?" box getting dollar signs entered in it. Therefore, this specific case mandates a regex for any sort of sanity. A simple quantity field might make a better example. Do you really want to order "100iamacat" items? Sure, I'll give you 100 of them and not complain about it. I guess it all depends on how idiotic I expect the users to be and how smart I want to make the correction of their inevitable errors. McGlockenshire fucked around with this message at 06:37 on Sep 27, 2010 |
# ¿ Sep 27, 2010 06:24 |
|
baquerd posted:Let's pretend instead of a user entering this data, you're parsing from a file detailing financial transactions. Today there's a fun error in the supplied file, merging a numeric field and a string field accidentally. In fact, a similar situation happened to us two weeks ago. One of our vendors gave us a malformed data feed for a few days, and the nightly import log was 70 megs of Perl complaining about doing addition on a string (converting it to a number by adding zero). The difference was the number was now preceded by one letter and a tab. Under Perl's coercion rules, "X 1234" is zero. That import code was sloppy, and ended up "silently" zeroing their apparent sale price on 600k components because it blindly assumed the contents in that column would be correct and well-formed. This would have been a major problem for our purchasing folks, if we ever used this particular vendor. (Related: Mister hardware vendor, xBase is neither a suitable nor sane data export format. This is one of many reasons we never buy anything from you.) Look, all I'm saying is that sometimes, being "sloppy" can be acceptable if the result of the sloppyness isn't harmful in the worst case. If all I need is an int, and I don't care what the user typed after it, I'm gonna cast it and spend my time fixing other problems instead. I'd rather not have my programming language make that decision for me. McGlockenshire fucked around with this message at 07:11 on Sep 27, 2010 |
# ¿ Sep 27, 2010 07:08 |
|
php-internals is Kim Jung-il. PHP is North Korea. e: also, qntm posted:Well, by all means explain it. As I understand it, "use Foo::Bar;" will make Perl look through all of the directories in @INC for a file named "Foo/Bar.pm", NOT for a file containing "package Foo::Bar;". That is, it is a command to import a specific file, and "::" is being made into a directory separator. Meanwhile, Foo/Bar.pm could start off with "package Something::Else;", so that when, later in the script, you start calling Something::Else::function(), (1) the "::" suddenly has a completely different meaning and (2) the reader has no idea where this function has mysteriously appeared from. Any Perl developer that places two unrelated packages in a single .pm file deserves to get shot in the face, and then only under extremely extreme circumstances. If you see this on CPAN, name and shame. I'll bring the pitchforks. McGlockenshire fucked around with this message at 00:49 on Oct 1, 2010 |
# ¿ Oct 1, 2010 00:47 |
|
tef posted:if only he hadn't spent the last 10 years working on the second system perl To be fair, he lost his job and had a tumor yanked out of his stomach, two things which would kind of put a hold on anybody's plans. Then there's the little problem of not having the 1.0 VM until last freaking year. I want to use Perl 6. Maybe I'll get the chance in the next decade...
|
# ¿ Oct 15, 2010 18:07 |
|
ErIog posted:Do we know yet if that behavior is different in IE9? Microsoft seems like they understand that the old versions of IE were abominations with the decisions they've been making with IE9. The problem is going to be what IE9 supports: Vista and 7. They aren't going to do a version for XP because it would involve backporting a lot of system libraries and technologies. This means that the latest version of IE available for XP is going to remain IE8. As long as XP exists in the wild, we are going to need to support IE8. And 7, and 6. Microsoft will be patching XP through the spring of 2014. An unfortunate number of corporate users are going to be using XP even past that point, and who knows how long home users will stick with it. We're probably going to be dealing with the fallout for the next five years, if not longer. That is the coding horror.
|
# ¿ Dec 8, 2010 18:15 |
|
NotShadowStar posted:Holy balls I noticed that 0 == "" and 0 == null in PHP. Also "string" == 0 in PHP. code:
|
# ¿ Dec 9, 2010 21:21 |
|
YeOldeButchere posted:Who still uses EBCDIC? I'm genuinely curious, I thought it was terrible in every way and the only use I can think of is compatibility with things like banking or airline software written in the 70s.
|
# ¿ Dec 14, 2010 21:16 |
|
Oh yes, I know that pain. We have delightful nuggets like this one spread throughout our code.php:<?php $_GET['cat'] or $_GET['cat'] = $_POST['cat']; $_GET['cat'] or $_GET['cat'] = $_GET['id']; $_GET['cat'] or $_GET['cat'] = $_POST['id'];
|
# ¿ Dec 23, 2010 18:54 |
|
MononcQc posted:to be fair, $_REQUEST also looks up in $_COOKIE and cookies are checked after $_POST. In certain cases it might be better to be explicit.
|
# ¿ Dec 23, 2010 21:06 |
|
Apparently this was needed because you couldn't directly invoke new Array objects in Javascript 1.0. Javascript 1.1 was introduced in Netscape 3, released in 1996. This is the problem with tutorial code. Inevitably, your code becomes obsolete and laughable and teaches people the now-wrong way to do things.
|
# ¿ Dec 26, 2010 18:23 |
|
pwd posted:I saw this today in actual use. Even if you're familiar with perl, it is probably somewhat confusing. I vaguely recall glob not being implemented correctly on non-Unix platforms a while ago. They fixed this along with a lot of other cross-platform behavior way back in 5.6. File::Spec is expressly designed for cross-platform operations. It's not the best code, but there's probably a clear method to the madness.
|
# ¿ Feb 2, 2011 04:59 |
|
Scaevolus posted:That's not how aes_encrypt works, though. It expects to get a (random) 128-bit string. The thing is that AES is a freaking standard defined by NIST. You don't take liberties with encryption, and you most certainly don't take liberties with standards. Unless the wacky things that MySQL's implementation is doing comply with the standard, they're doing it wrong and have created an AES that suddenly isn't the same thing as everyone else's AES.
|
# ¿ Feb 25, 2011 00:21 |
|
Sorry for the back to back posting, but this is a demonstration of the utter broken-ness:php:<?php // We already know that the password gets xored into nothingness, so // we'll encrypt using the password, then decrypt using the empty string. $broken = $db->query_one("SELECT AES_ENCRYPT('hello', 'arbitrarypasswrdarbitrarypasswrd')"); $result = mcrypt_decrypt(MCRYPT_RIJNDAEL_128, '', $broken, MCRYPT_MODE_ECB); echo urlencode($result); // => "hello%0B%0B%0B%0B%0B%0B%0B%0B%0B%0B%0B" // 0x0b is chr 11, the vertical tab. This is the padding that their manual warns about. echo base64_encode($broken); // => mDTtUYy8j76a88bst164wA== // This is the thing we'll expect to see when we've replicated the broken implementation. // Let's try encrypting the same string using the same key and the same encryption mode (ECB, which is also considered scary/bad now). $crypted = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, 'arbitrarypasswrdarbitrarypasswrd', 'hello', MCRYPT_MODE_ECB); echo base64_encode($crypted); // => 6NfWHAVuIFL9pwFbmNuDEw== // Well that's not right. // Let's add the padding. $wrong = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, 'arbitrarypasswrdarbitrarypasswrd', urldecode('hello%0B%0B%0B%0B%0B%0B%0B%0B%0B%0B%0B'), MCRYPT_MODE_ECB); echo base64_encode($wrong); // => +sU43m6oTdmX+oPg2bU88g== // Nope, way different. Let's blank the key. $fuckmysql = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, '', urldecode('hello%0B%0B%0B%0B%0B%0B%0B%0B%0B%0B%0B'), MCRYPT_MODE_ECB); echo base64_encode($fuckmysql); // => mDTtUYy8j76a88bst164wA== // There, we managed to replicate how broken MySQL is. e: According to this closed-as-not-a-bug, the padding character is actually the number of characters padded, as recommended in the documentation for PKCS#7 amongst other things. This, of course, despite the fact that not everyone else does it that way. That scares the crap out of me. e2: I was curious about what mcrypt does when it's given a key that's too long. php:<?php $key = 'a somewhat long passphrase that does not intentionally munch crap'; $crypted = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key, urldecode('hello%0B%0B%0B%0B%0B%0B%0B%0B%0B%0B%0B'), MCRYPT_MODE_ECB); // mcrypt_encrypt(): Size of key is too large for this algorithm in php shell code on line 1 echo base64_encode($crypted) // => tAM4mX6g69XWmODZ71b00w== // MySQL gives the following for the same passphrase and un-padded string of 'hello': // => Y2e2bJXEDf+5qsgb+I4Y8w== MySQL does a wrong thing and doesn't complain at all. Not even a warning. e3: Last edit, I promise. If done correctly, PHP will even warn you about maximum lengths. The behavior seems to be truncation of over-long keys, but that isn't actually indicated by the error message. code:
McGlockenshire fucked around with this message at 01:27 on Feb 25, 2011 |
# ¿ Feb 25, 2011 00:56 |
|
I dunno, the convenience of INSERT / UPDATE ... RETURNING makes up for the lack of REPLACE / INSERT INTO ... ON DUPLICATE KEY UPDATE and friends. Different things, I know, but it's immensely useful to just return the pkey right from the insert rather than having to poke at the sequence. 9.1 includes the groundwork for making a real upsert a reality. Then there's also working CHECK clauses, nifty data types (like inet and cidr, which can hold and process both IPv4 and IPv6 addresses and networks), straightforward stored procedures, and other goodies. Related to the most recent horror, the pgcrypto contrib module also happens to include 128-bit AES, and even lets you pick the padding and block modes.
|
# ¿ Feb 25, 2011 20:44 |
|
tef posted:the language is inconsistent - some things work, some things don't (ahem foo(1,2,3)[1]) FWIW, this is possible in PHP trunk (5.4?)
|
# ¿ Mar 4, 2011 05:24 |
|
I'll just leave this here.code:
|
# ¿ Mar 11, 2011 22:49 |
|
Jabor posted:Is the first thing that gets done to the result of that query a split on `~'?
|
# ¿ Mar 11, 2011 23:06 |
|
wwb posted:Oh, and who the gently caress submitted that xjson poo poo to reddit. Karma is a hell of a drug.
|
# ¿ Apr 30, 2011 01:25 |
|
It might be based on this 2008 article. Older IEs seem to perform better using join(). Given the radical changes to how modern Javascript engines work, it's likely that the results might be different now.
|
# ¿ May 12, 2011 17:08 |
|
This is your brain on design patterns. Any questions?
|
# ¿ May 20, 2011 23:10 |
|
Otto Skorzeny posted:the question then becomes, why the hell is the default binding in a dynamic language such a thin wrapper around the C api that this sort of horseshit is exposed? Hilariously, php-internals uses the thin-wrapper-over-a-library thing as an example of an outstanding design.
|
# ¿ May 30, 2011 08:24 |
|
|
# ¿ Apr 26, 2024 14:22 |
|
poemdexter posted:What the hell software needs to go from nanometers to parsecs? Han Solo.
|
# ¿ Aug 9, 2011 04:55 |