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!

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

HappyHippo posted:

I can't tell if youre joking or not, but 32 on/off options leads to 2^32 possible combinations of options, and you can't encode that in less than 2^32 numbers without losing some possible combinations.

Unless you compress the result

We're through the looking glass here folks

# ¿ Apr 25, 2008 08:57

Adbot: ADBOT LOVES YOU

# ¿ Apr 26, 2024 12:24

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

Just out of curiosity, can anyone name a CPU in significant use today that doesn't use 8 bits per byte and/or twos complement to represent signed integers?

Edit: well blow me down, maybe there are a few network appliances out there that handle one's complement arithmetic because:

quote:

The IPv4 header checksum uses ones' complement arithmetic.

minato fucked around with this message at 02:10 on Jan 6, 2009

# ¿ Jan 6, 2009 02:01

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

Why do you consider &1 to be silly? Is it code clarity, performance, portability, or something else?

Code clarity I could understand, and same goes for performance unless we're talking about some highly-optimized graphics rendering loop, but I can't imagine anyone seriously citing portability.

# ¿ Jan 6, 2009 05:29

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

code:

float InvSqrt (float x){
    float xhalf = 0.5f*x;
    int i = *(int*)&x;
    i = 0x5f3759df - (i>>1);
    x = *(float*)&i;
    x = x*(1.5f - xhalf*x*x);
    return x;
}

gently caress yoooooooooouuuuuu.

# ¿ Jan 7, 2009 17:19

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

By "properly-used" I guess you mean that they're used comprehensively, in which case there is no difference - but that's not what I think Ryouga Inverse was getting at. If you always use escape_string() then there's a risk you might forget to, and that risk isn't possible with prepared statements. However that's beside the point, because I think Ryouga Inverse was referring to mysql_escape_string() vs mysql_real_escape_string(), not escape_string() vs prepared statements.

# ¿ Jan 8, 2009 01:22

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

What is the argument then? Is it mysql_escape_string() vs mysql_real_escape_string(), which is what zergstain was asking about? To reiterate what Ryouga Inverse said, a flaw was found with mes() whereas none has been found with mres(), so use mres(). Just because zergstain couldn't find any exploit code that used mes() isn't a good excuse to keep using it.

If the argument is prepared vs thorough use of mres(), then I don't think the choice is so clear cut. Prepared statements are free of injection risks and may be processed faster since the app doesn't have to plod through a potentially large string to copy and escape it, and the DB server doesn't have to spend time parsing the string to unescape it.

But the downside is that prepared statements can be a little harder to read (since it's necessary to read 2 areas of code simultaneously to ensure that each replacement token is correctly matched up with the variable that will be replacing it), and can they can be difficult to use in some dynamic SQL situations. Use of mres() can be easier and more legible in these situations, but runs the risk of the coder forgetting to use it.

# ¿ Jan 8, 2009 02:21

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

zergstain posted:

and I'm fairly sure everything is latin 1 anyway.

If you're using mes() or mres() then you're probably escaping user input. How can you be sure all user input is Latin 1?

# ¿ Jan 8, 2009 02:53

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

Well, you're asking whether you should get your bosses to approve moving from mes() to mres(). And you're right that mres() does respect the connection's character set. But mes() doesn't:

The PHP manual for mes() posted:

This function is identical to mysql_real_escape_string() except that mysql_real_escape_string() takes a connection handler and escapes the string according to the current character set. mysql_escape_string() does not take a connection argument and does not respect the current charset setting.

so that sounds to me like using mes() may be introducing at least some fragility into your code. Hey, your mes() code may be 100% safe, but rather than ponder the risks I'd rule them out altogether and use mres().

# ¿ Jan 8, 2009 03:38

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

The mes()/mres() decision shouldn't really be a issue anyway - most well-designed apps would use some form of DB abstraction layer.

zergstain posted:

AFAIK, they want to be able to see passwords anyway.

If that's true, then your bosses are idiots and you're hosed.

# ¿ Jan 8, 2009 08:17

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

Janin posted:

Please post more details about insane Japanese software, because this post right here is incredible.

I was asked to migrate a Japanese webapp from Sun to Linux. The webapp supported authentication, downloads, forums, and a support tracking system. They gave me access to the directory where all the code was kept, and I thought there was a mistake because there was only one file in it, a large Perl file. But there was no mistake. That single gigantic Perl file did everything. There were no other Perl files, HTML pages or templates. Every URL in the site would load that file and query parameters would tell it what to render.

:downsgun:

# ¿ Dec 18, 2009 22:36

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

MEAT TREAT posted:

How big was the file?

I don't remember exactly, but it was huge, over 1MB.

Another Japanese coding horror. A long while ago there was a 3D file format designed for games. Each component of the file had a type (3D mesh, texture, animation data, etc) and each type had various bitfields that described attributes of that component ("flat/gouraud/textured shading", "anti-aliased", "has normal", etc) and these were meant to be used to indicate which "driver method" to use to handle that component.

But the way the libraries were set up, each combination of bit fields had to have its own driver method. So if you had a 3D mesh that was anti-aliased and another that wasn't, you couldn't just use a single driver method for both where you'd check the bitfield and flip the anti-aliasing on. You had to write two separate drivers. Multiply this by the many different bitfields and it meant that potentially it would be necessary to write 2^32 drivers.

So dumb.

# ¿ Dec 19, 2009 04:24

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

suction posted:

has this been posted? Found it on Reddit from 4chan

code:

#!/bin/bash
function f() {
    sleep "$1"
    echo "$1"
}
while [ -n "$1" ]
do
    f "$1" &
    shift
done
wait

example usage:
./sleepsort.bash 5 3 6 3 6 3 1 4 7

This is beautiful.

# ¿ Jun 16, 2011 00:53

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

My god, the advice he gives is awful. He enables debugging to the screen on production and his first piece of advice is "Avoid working late at night" instead of "Don't debug on loving production".

# ¿ Jul 7, 2011 18:50

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

Do you put commas at the end of the line or the beginning?

code:

SELECT foo
     , bar
     , baz
FROM ...

This initially looks horrible, but it has a couple of advantages:
- Because the commas all line up, you can easily see missing commas
- It's common to add extra elements at the end, so it's easier to use vim's "yyp" to duplicate the last line and tweak it to what you want, instead of also having to go to the 2nd to last line and add a comma.
--- Corollary: when looking at a diff where someone's added a new line, the old last line is not affected so doesn't get added to the diff, so the diff is simpler to read (better fore code reviews). e.g diffs for adding a new column "wiz"

Commas at beginning:

code:

  SELECT foo
       , bar
       , baz
+      , wiz
  FROM ...

vs

Commas at end:

code:

  SELECT foo,
         bar,
-        baz
+        baz,
+        wiz
  FROM ...

# ¿ Jul 31, 2011 17:53

Adbot: ADBOT LOVES YOU

# ¿ Apr 26, 2024 12:24

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

Well, at least this code doesn't use any gotos: :haw:

code:

send(to, from, count)
register short *to, *from;
register count;
{
        register n=(count+7)/8;
        switch(count%8){
        case 0:      do{      *to = *from++;
        case 7:              *to = *from++;
        case 6:              *to = *from++;
        case 5:              *to = *from++;
        case 4:              *to = *from++;
        case 3:              *to = *from++;
        case 2:              *to = *from++;
        case 1:              *to = *from++;
                }while(--n>0);
        }
}

Not-very-fun fact: when I was learning to program on my ZX81, BASIC used the word "GOTO" as opposed to "GO TO" and it didn't click with me that it was two separate words, so for years I pronounced it "gotto" (rhymes with motto).

# ¿ Sep 8, 2011 18:59

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!