Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
McGlockenshire
Dec 16, 2005

GOLLOCKS!
code:
// Cache the result.  Be aware that this is only feasible if the cache
// is flushed in its entirety for any edit, since we don't yet have the
// ability to track individual changes to text, for things like item
// name changes, etc.
    $Cache->store('TextMarkup_'.$type.'_'.$id.'_'.$tag, array($this->format, $this->source, $this->html) );
This code, on its own, is not a horror. Even with the comment, it's not quite a horror. You have to see the big picture to understand the horror.

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

Adbot
ADBOT LOVES YOU

McGlockenshire
Dec 16, 2005

GOLLOCKS!

UberJumper posted:

:smithicide:

The name of that function is a

Part of me wants to see what b() and c() are.

That code almost looks like it came out of a bytecode "decompiler."

McGlockenshire
Dec 16, 2005

GOLLOCKS!
code:
(int)60D
What?

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?

McGlockenshire
Dec 16, 2005

GOLLOCKS!

TRex EaterofCars posted:

xxxxD forces the number xxxx to a double. Can do the same with xxxxF for float.
But... if it's being created as a double, why is he immediately casting it to an int? And since when have primitive non-decimal numbers been anything but ints? This assumes that the coder thought of this. This code makes my head hurt.

McGlockenshire
Dec 16, 2005

GOLLOCKS!

UberJumper posted:

code:
/*
	I MADE 9 WRAPPERS ENDING WITH LETTERS, SINCE JAVA cant make classes right. THEY ARE ALL THE SMAE!!!!!!
	WHY IS THIS SO HARD??!@?! If i want 50 clases i need to be able to do it better. 
*/
:psyboom: does not even begin to describe the sheer concentration of WTF in this comment.

McGlockenshire
Dec 16, 2005

GOLLOCKS!

Otto Skorzeny posted:

Behead those who say K&R is a violent religion

Durka durka One True Brace Style jihad! :jihad:

McGlockenshire
Dec 16, 2005

GOLLOCKS!
It can be further reduced to this. Yes, it should work. I think. Erk, been too long.
code:
if(isset($attribs['__select_keyword']))
    $query = "SELECT {$attribs['__select_keyword']} * FROM {$db_name}";

McGlockenshire
Dec 16, 2005

GOLLOCKS!

geetee posted:

The best trolls are the ones that aren't obvious. gently caress your brace stripping ways :mad:

It's the closest I can get to Perl's "expression if/unless expression" syntax. PHP! :bahgawd:

McGlockenshire
Dec 16, 2005

GOLLOCKS!

quote:

Forgive my naivety, but what would this achieve?

Well, let's find out!

code:
#!perl
use strict;
use warnings;
use Data::Dumper;
my @list = qw! -1 0 1 2 3 4 5 !;
my @sorted_list = sort { my $x = $a += $b; print "$x\n"; $x; } @list;
print Dumper \@sorted_list;
results in...

code:
$VAR1 = [
          5,
          9,
          7,
          23,
          3,
          4,
          0
        ];
Oh yegods, it actually did what I was afraid that it was going to do. :psyduck:

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? :psypop:

For shits and giggles, I modified the sort line:
code:
my @sorted_list = sort { my $olda = $a; my $x = $a += $b; print "$olda + $b -> $x ($a)\n"; $x; } @list;
The resulting output?
code:
-1 + 0 -> -1 (-1)
1 + 2 -> 3 (3)
3 + 4 -> 7 (7)
-1 + 2 -> 1 (1)
1 + 3 -> 4 (4)
4 + 5 -> 9 (9)
2 + 5 -> 7 (7)
7 + 9 -> 16 (16)
16 + 7 -> 23 (23)
Yup, it's returning the added value. :psyboom:

I love Perl!

McGlockenshire fucked around with this message at 10:41 on Jun 16, 2009

McGlockenshire
Dec 16, 2005

GOLLOCKS!
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;
    }?>
Mind you, this method isn't in the database adapter. Oh, no, it's in the "global" class. And it doesn't even do what he thinks it does, it just makes a horrible backslashy mess.

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

McGlockenshire
Dec 16, 2005

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

McGlockenshire
Dec 16, 2005

GOLLOCKS!

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.

McGlockenshire
Dec 16, 2005

GOLLOCKS!
Oh my gods, it's practically INTERCAL.

McGlockenshire
Dec 16, 2005

GOLLOCKS!

Jonnty posted:

Does that imply that there are programs that somehow rely on the buggy behaviour of that escape function, then?
Not the buggy behavior, but the fact that it exists and "works."

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.
Then your application is broken. Turn error reporting all the way up, I'll bet you have three pages full of undefined variable and missing array key notices before any real output. isset and array_key_exists are your friends. Your best friends ever.

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

McGlockenshire
Dec 16, 2005

GOLLOCKS!

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

McGlockenshire
Dec 16, 2005

GOLLOCKS!

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.

McGlockenshire
Dec 16, 2005

GOLLOCKS!

NotShadowStar posted:

Erm, no. That's not at all how non-batshit languages work.
I stand corrected.

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.

McGlockenshire
Dec 16, 2005

GOLLOCKS!

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.

McGlockenshire
Dec 16, 2005

GOLLOCKS!

Shavnir posted:

Weren't you the one that said "Garbage in, garbage out"?
In PHP and Perl, "100 but not one hundred" can be turned into 100.

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

Valid input?

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

McGlockenshire
Dec 16, 2005

GOLLOCKS!

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.

Your data: "9638410 year treasury"

Do I need to point out the problem?
Nope.

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

McGlockenshire
Dec 16, 2005

GOLLOCKS!
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

McGlockenshire
Dec 16, 2005

GOLLOCKS!

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

McGlockenshire
Dec 16, 2005

GOLLOCKS!

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.

If IE9 ends up actually being on par with Chrome, Firefox, or Safari then PHP might be all we have left.
IE9 is indeed a relatively standards compliant, relatively decent, relatively fast browser. I still wouldn't use it for my daily browsing, but it's not going to be the shithole that previous versions were. The IE team seems to be taking things seriously now, and Browser Wars 2.0 is likely to be a win for everybody.

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.

McGlockenshire
Dec 16, 2005

GOLLOCKS!

NotShadowStar posted:

Holy balls I noticed that 0 == "" and 0 == null in PHP. Also "string" == 0 in PHP.

This is literally the worst thing created. At least Perl has some hosed up logic behind it's typeless crazytown. img-php.png indeed.
code:
[mcg@mcg-workstation ~]$ php --interactive
Interactive shell

php > var_export( "string" == 0 ); // Strings are numeric zero.
true
php > var_export( (bool)"string" ); // Strings are boolean true.
true
php > var_export( true == 0 ); // Boolean true is not zreo.
false
php > echo PHP_VERSION;
5.3.3
I hate PHP so, so much.

McGlockenshire
Dec 16, 2005

GOLLOCKS!

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.
You seem to be under the impression that companies aren't still using banking or airline software written in the 70s.

McGlockenshire
Dec 16, 2005

GOLLOCKS!
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'];

This is what happens when your "lead" developer doesn't know what $_REQUEST is and writes new code without warnings and notices turned on.

McGlockenshire
Dec 16, 2005

GOLLOCKS!

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.
Oh yes, this is true. You should always be explicit when you know you want the data to come from the query string or from posted data, not caring is the #1 cause of CSRF... but when you don't care where the data comes from? Yeah, screw that copying bullshit.

McGlockenshire
Dec 16, 2005

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

McGlockenshire
Dec 16, 2005

GOLLOCKS!

pwd posted:

I saw this today in actual use. Even if you're familiar with perl, it is probably somewhat confusing.

code:
use File::Spec;
# ...
It just lists files matching "*.txt" in the current directory.

The same thing (in all the cases we care about) can also be accomplished in one line:
code:
my @files = glob("*.txt");

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.

McGlockenshire
Dec 16, 2005

GOLLOCKS!

Scaevolus posted:

That's not how aes_encrypt works, though. It expects to get a (random) 128-bit string.

It should probably be noted in the documentation, but I don't see how this is a horror.

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.

McGlockenshire
Dec 16, 2005

GOLLOCKS!
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''$brokenMCRYPT_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.

Even without the horror of possibly destroying or misinterpreting the encryption key, the data padding means that MySQL's AES is not the same thing as everyone else's AES. That's a coding horror if there ever was one.

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$keyurldecode('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==

So, PHP does something, but at least warns you about it.

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:
php > $mc = mcrypt_module_open(MCRYPT_RIJNDAEL_128, '', MCRYPT_MODE_ECB, '');
php > echo $mc;
Resource id #1
php > var_export( mcrypt_enc_get_supported_key_sizes($mc) );
array (
  0 => 16,
  1 => 24,
  2 => 32,
)
php > var_export( mcrypt_enc_get_key_size($mc) );
32
php > $random_shit = openssl_random_pseudo_bytes(32);
php > mcrypt_generic_init($mc, $random_shit, str_repeat("\0", 16)); // It wants an IV, even though ECB doesn't use one
php > echo base64_encode(mcrypt_generic($mc, 'hello'));
eN+lZyoWWMcj+YndwQn7gw==
php > $random_shit .= '1';
php > mcrypt_generic_init($mc, $random_shit, str_repeat("\0", 16));
PHP Warning:  mcrypt_generic_init(): Key size too large; supplied length: 33, max: 32 in php shell code on line 1
php > echo base64_encode(mcrypt_generic($mc, 'hello'));
eN+lZyoWWMcj+YndwQn7gw==
php > 

McGlockenshire fucked around with this message at 01:27 on Feb 25, 2011

McGlockenshire
Dec 16, 2005

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

McGlockenshire
Dec 16, 2005

GOLLOCKS!

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

McGlockenshire
Dec 16, 2005

GOLLOCKS!
I'll just leave this here.
code:
SELECT GROUP_CONCAT(array_row SEPARATOR '~')
FROM (SELECT CONCAT(sumtime,':',title,':',url) A.array_row
FROM (SELECT SUM(time_spent) AS sumtime, title,url
FROM library WHERE delete_status = 0
GROUP BY url_id ORDER BY sumtime DESC) A) AA;
Best guess on what it's doing gets a free :psyboom: for their troubles.

McGlockenshire
Dec 16, 2005

GOLLOCKS!

Jabor posted:

Is the first thing that gets done to the result of that query a split on `~'?
Why yes, that's exactly it. And can you guess what happens next?

McGlockenshire
Dec 16, 2005

GOLLOCKS!

wwb posted:

Oh, and who the gently caress submitted that xjson poo poo to reddit.

Karma is a hell of a drug.

McGlockenshire
Dec 16, 2005

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

McGlockenshire
Dec 16, 2005

GOLLOCKS!
This is your brain on design patterns.

Any questions?

McGlockenshire
Dec 16, 2005

GOLLOCKS!

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.

Adbot
ADBOT LOVES YOU

McGlockenshire
Dec 16, 2005

GOLLOCKS!

poemdexter posted:

What the hell software needs to go from nanometers to parsecs?

Han Solo. :colbert:

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply