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 »

6174: Dec 4, 2004

zergstain posted:

Edit: Oh wait, a referrer check could stop that saving it to disk and editing it method. Probably wouldn't do anything for the use a Firefox extension and edit it in RAM method though.

Referrer checking in general belongs in this thread. It is easy to modify, Firefox extension or not, and many ad-blocking/virus scanning type programs strip the referrer. Putting any trust into it at all is a bad idea.

# ? Jan 10, 2009 20:18

Adbot: ADBOT LOVES YOU

# ? May 13, 2024 22:09

geetee: Feb 2, 2004; >;[

zergstain posted:

I have some web developer extension at work, and it looked like I could edit the html in RAM with it. But actually, I'm not sure what's stopping the hacker from saving the relevant stuff to disk since I believe when you submit the form and the browser requests the action url, the cookies for that domain would be sent. As long as the form wasn't reloaded from the server, the key would still be valid.

Edit: Oh wait, a referrer check could stop that saving it to disk and editing it method. Probably wouldn't do anything for the use a Firefox extension and edit it in RAM method though.

Read this: http://forums.devnetwork.net/viewtopic.php?f=28&t=38810

# ? Jan 10, 2009 20:54

zergstain: Dec 15, 2005

I'm going to gently caress around with that poo poo, since I'm not seeing the issue as long as the edit is done within the time window. I'll post again if/when I figure out I'm just a retard.

Edit: I uploaded the example from that tutorial and set up the database and all that. I then pretended I had somehow stolen the password hash, but wasn't able to make edits on the server, so I saved the index.php as the browser sees it, as well as the sha256.js file to the desktop. I then made the following edit:

code:

<!--
  function doChallengeResponse() {
    str = document.login_form.username.value.toLowerCase() + ":" +
    document.login_form.userpass.value + ":" +
    document.login_form.challenge.value;
    document.login_form.userpass.value = "";
    document.login_form.challenge.value = "";
    document.login_form.response.value = sha256_digest(str);
    return false;
  }
// -->

See the link posted right above this post for the original code.

Then I replaced the form action with the full url, since it was a relative path.

If I need to login again, I can reload the page from the server, then copy and paste the new challenge value in the proper place in my saved page.

Finally I pasted "5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8" in the password field, and it told me "You have been authenticated through the Challenge/Response process. Congratulations!"

Edit redux: I understand the effectiveness of this against network sniffers, but as far as stopping someone who has stolen the database (which is why we shouldn't store passwords as plain text, isn't it?), it seems pretty worthless. Maybe it could store the password as 2 rounds of sha256, and the browser could compute the hash once and just send everything separately, then the server hashes it again, and compares it with the database.

zergstain fucked around with this message at 04:47 on Jan 11, 2009

# ? Jan 11, 2009 00:12

ohgodwhat: Aug 6, 2005

zergstain posted:

I have some web developer extension at work, and it looked like I could edit the html in RAM with it. But actually, I'm not sure what's stopping the hacker from saving the relevant stuff to disk since I believe when you submit the form and the browser requests the action url, the cookies for that domain would be sent. As long as the form wasn't reloaded from the server, the key would still be valid.

Edit: Oh wait, a referrer check could stop that saving it to disk and editing it method. Probably wouldn't do anything for the use a Firefox extension and edit it in RAM method though.

It doesn't matter how much they edit it, the $key is only good for one request, so if they have the password hashed with that key, they can't use it again.

quote:

If I need to login again, I can reload the page from the server, then copy and paste the new challenge value in the proper place in my saved page.

Do you type in the password again too?

ohgodwhat fucked around with this message at 05:25 on Jan 11, 2009

# ? Jan 11, 2009 05:22

Dessert Rose: May 17, 2004; awoken in control of a lucid deep dream...

zergstain posted:

I understand the effectiveness of this against network sniffers, but as far as stopping someone who has stolen the database (which is why we shouldn't store passwords as plain text, isn't it?), it seems pretty worthless. Maybe it could store the password as 2 rounds of sha256, and the browser could compute the hash once and just send everything separately, then the server hashes it again, and compares it with the database.

There is literally no, I repeat, no way that you can defend against someone who has stolen your db. If someone has hosed your poo poo that thoroughly you can't stop them from logging in as anyone.

The reason we don't store passwords as plaintext is because if I steal your db, you don't want to have to email all your users and go "Whoops, we hosed up, please change your password everywhere else you use the one you used for this site." You can just say "Hey, you'll need to reset your pw next time you log in", or somesuch.

The reason for challenge/response is so that if I (as evil hacker) am on unsecure wifi at, say, Starbucks, and you are there too, and you log in to the site over unsecure HTTP, I can't use anything I just saw (assuming I've seen your entire handshake with the site) to log in as you (except, perhaps, the cookie that you got sent back as your session token)

ed: The reason you can't defend against someone who knows everything you know is because a password is also known as a "shared secret". All the methods that we use to authenticate a user basically revolve around the idea that we're verifying that the client and the server both know some bit of data that's unique to that account. Since I've stolen the database, I've stolen all those bits of data - no matter how it's stored, somewhere all we're doing is verifying that one of us knows the same thing as the other one - and so I do know the shared secret. There's no way you can have the server know and yet not know what it's using to auth a user.

This is the same reason why DRM can only fail, as a sidebar; the client and server are the same person.

Dessert Rose fucked around with this message at 06:05 on Jan 11, 2009

# ? Jan 11, 2009 06:00

ShoulderDaemon: Oct 9, 2003; support goon fund; Taco Defender

Ryouga Inverse posted:

There is literally no, I repeat, no way that you can defend against someone who has stolen your db. If someone has hosed your poo poo that thoroughly you can't stop them from logging in as anyone.

Uh, this is blatantly not true. There are ways to verify that a party holds a piece of information that you do not have. Trivial passwords, for example: A server stores a hash of the password, the client sends the password, the server verifies that it has the expected hash. If an attacker has the hash, he needs to solve a cryptographically hard problem before he can generate a token that will authenticate him to the server.

# ? Jan 11, 2009 06:08

Dessert Rose: May 17, 2004; awoken in control of a lucid deep dream...

Well, except then you can't fight network sniffing.

But yeah, I'm an idiot and I have no idea what I was thinking when I wrote that :suicide:

# ? Jan 11, 2009 06:13

hexadecimal: Nov 23, 2008; by Fragmaster

ShoulderDaemon posted:

Uh, this is blatantly not true. There are ways to verify that a party holds a piece of information that you do not have. Trivial passwords, for example: A server stores a hash of the password, the client sends the password, the server verifies that it has the expected hash. If an attacker has the hash, he needs to solve a cryptographically hard problem before he can generate a token that will authenticate him to the server.

Can you talk about the md5 exploit? Given an md5 hash, how hard is it to generate a string with a certain size limit that will generate same md5 hash? If that is no longer a hard problem, then if one stole your DB including md5 hashes, you are pretty much hosed right?

# ? Jan 11, 2009 06:15

ShoulderDaemon: Oct 9, 2003; support goon fund; Taco Defender

hexadecimal posted:

Can you talk about the md5 exploit? Given an md5 hash, how hard is it to generate a string with a certain size limit that will generate same md5 hash? If that is no longer a hard problem, then if one stole your DB including md5 hashes, you are pretty much hosed right?

With the current public state of the art, given an MD5 hash, it is computationally infeasible to generate a preimage. However, it is strongly believed that this will change within the next few years, and there may be parties with nonpublic information (such as large governments) who can already form preimages with tractable complexity.

Edit: And yes, once preimages become tractable, MD5 hashes of passphrases are no longer secure. Salting, length-limiting, and character-set-limiting all help a little here, but not enough to be realistic deterrents.

# ? Jan 11, 2009 06:18

Dessert Rose: May 17, 2004; awoken in control of a lucid deep dream...

hexadecimal posted:

Can you talk about the md5 exploit? Given an md5 hash, how hard is it to generate a string with a certain size limit that will generate same md5 hash? If that is no longer a hard problem, then if one stole your DB including md5 hashes, you are pretty much hosed right?

There has been no exploit in this department. The MD5 exploit has to do with me being able to generate colliding documents given that I control all the original documents.

So if I somehow got you to give it a password that I generated for you, I could then know another password that generated that same hash.

The MD5 exploit is much more useful in terms of certificate signing. If I want an SSL cert for, say, verisign.com, obviously verisign isn't going to give me one.

But if I generate two SSL certs - one for verisign.com, and one for dog&ponyshow.biz, and they both hash to the same MD5, then if I can get Verisign to sign my dog&ponyshow.biz cert, I can use their signature for my verisign.com cert and be a MITM without a security warning box popping up.

# ? Jan 11, 2009 06:19

hexadecimal: Nov 23, 2008; by Fragmaster

What is, in your opinion, the best hash algorithm right now that is not likely to be broken in the future?

# ? Jan 11, 2009 06:20

ShoulderDaemon: Oct 9, 2003; support goon fund; Taco Defender

hexadecimal posted:

What is, in your opinion, the best hash algorithm right now that is not likely to be broken in the future?

Currently I would design to a SHA-2 family hash, planning to migrate to SHA-3 when it is standardized. But I'm a traditionalist, and tend to avoid the lesser-used hash functions simply because they have seen much less cryptanalysis, not because I have any reasonable doubts of their security.

# ? Jan 11, 2009 06:21

ShoulderDaemon: Oct 9, 2003; support goon fund; Taco Defender

Sorry for responding out of order; I missed this post somehow.

Ryouga Inverse posted:

Well, except then you can't fight network sniffing.

Trivial password authentication is vulnerable to sniffing, yes. If you can perform computations on the client you can get around this several ways: Either wrap the conversation in SSL or a similar transport security mechanism, or execute a protocol such as A-EKE to perform a zero-knowledge password proof. It's a reasonably well-understood problem in the field to authenticate using a passphrase such that the verifier does not know the passphrase, the conversation cannot be usefully intercepted or proxied, and authentication to a false verifier does not compromise the secret.

# ? Jan 11, 2009 06:32

zergstain: Dec 15, 2005

ryanmfw posted:

It doesn't matter how much they edit it, the $key is only good for one request, so if they have the password hashed with that key, they can't use it again.

I know. But this was assuming that the hashed password as stored in the database was somehow obtained, not just the password combined with that $key.

ryanmfw posted:

Do you type in the password again too?

Well yeah, but technically I could've put the username and stolen hash of my victim in the value attributes so they'd be right there. Since it's saved locally, it doesn't send another request to the server, except for the POST request to submit the login information, and for obvious reasons, the $key can't be invalidated at that point (except after the response has been verified, in which case doing so is a good idea).

I was going to say that in systems where the browser sends the password as plaintext, and login.php computes the hash, if the DB has been stolen, logging in to the site would be nigh impossible, unless the perp was able to replace login.php. I don't know much about the common ways DBs are stolen, but I imagine if you can steal the DB, replacing files isn't a huge stretch.

If only there was some way for the browser to compute a different hash, and then have the server do some operation with what's in the database to get something that equals the submitted value.

schnarf posted:

No. Then the password is the encrypted password. You can just "pass the hash." Usually you want to use SSL instead of trying to design your own encryption scheme because that's almost universally a bad idea.

This whole time, you were talking about obtaining the hash by sniffing the network, not stealing it from the DB, weren't you? This whole challenge/response stuff would be pretty effective against sniffing, as I've already said. Though not as good as SSL.

Edit:

ShoulderDaemon posted:

Trivial password authentication is vulnerable to sniffing, yes. If you can perform computations on the client you can get around this several ways: Either wrap the conversation in SSL or a similar transport security mechanism, or execute a protocol such as A-EKE to perform a zero-knowledge password proof. It's a reasonably well-understood problem in the field to authenticate using a passphrase such that the verifier does not know the passphrase, the conversation cannot be usefully intercepted or proxied, and authentication to a false verifier does not compromise the secret.

I found a paper on A-EKE, and if it was implemented over HTTP, I'm still not sure how it wouldn't be vulnerable to the same kind of attack, unless it was digitally signed or something, and how do you do that kind of stuff without using HTTPS? I tried to find a web-based implementation of this so I could gently caress around and see where I'm wrong, and I have to be, as this poo poo was written by people way the gently caress smarter than I am.

zergstain fucked around with this message at 07:46 on Jan 11, 2009

# ? Jan 11, 2009 07:00

ShoulderDaemon: Oct 9, 2003; support goon fund; Taco Defender

zergstain posted:

I found a paper on A-EKE, and if it was implemented over HTTP, I'm still not sure how it wouldn't be vulnerable to the same kind of attack, unless it was digitally signed or something, and how do you do that kind of stuff without using HTTPS? I tried to find a web-based implementation of this so I could gently caress around and see where I'm wrong, and I have to be, as this poo poo was written by people way the gently caress smarter than I am.

I don't understand why you think HTTP is relevant. I mean, it's not like it's magically different from every other communication channel.

EKE and A-EKE are essentially digital signature algorithms, designed to operate on key material rather than static data. They are used in key-setup systems like SSL; by analogy, they operate by mutually establishing identity by way of a shared secret as is done at the start of an encrypted connection, proving to both parties that the session was established correctly, then discarding the generated session key and returning to unencrypted communication.

# ? Jan 11, 2009 08:49

Smackbilly: Jan 3, 2001; What kind of a name is Pizza Organ! anyway?

Came across this while debugging someone else's code at work this week:

code:

int FromOctString(char *octnumber)
{
        char chdigit[1]; int iret; char octnum[3];
        strcpy(octnum, octnumber);
        sprintf(chdigit, "%c", octnum[0]);
        iret = atoi(chdigit) * 64;
        sprintf(chdigit, "%c", octnum[1]);
        iret += atoi(chdigit) * 8;
        sprintf(chdigit, "%c", octnum[2]);
        iret += atoi(chdigit);
        return iret;
}

How is this wrong? oh let me count the ways...

1. Even ignoring the other bugs, it only "works" for octal numbers that are 2 or 3 digits long (and 2 only by accident). If you pass it a 1 or 4+ digit number, the results are non-deterministic. In context, this function is not going to receive any 4+ digit numbers, but a 1-digit number is completely possible.

2. The author apparently forgot that C strings are null-terminated, leading to:

2a. The strcpy call will write past the storage of octnum if octnumber is 3 or more digits.

2b. Every call to sprintf will write past the storage of chdigit

3. There's no const-correctness on the parameter

4. The entire goddamned function can be replaced by a single call to strtol.

I replaced it with strtol.

Smackbilly fucked around with this message at 13:52 on Jan 11, 2009

# ? Jan 11, 2009 13:50

zergstain: Dec 15, 2005

ShoulderDaemon posted:

I don't understand why you think HTTP is relevant. I mean, it's not like it's magically different from every other communication channel.

EKE and A-EKE are essentially digital signature algorithms, designed to operate on key material rather than static data. They are used in key-setup systems like SSL; by analogy, they operate by mutually establishing identity by way of a shared secret as is done at the start of an encrypted connection, proving to both parties that the session was established correctly, then discarding the generated session key and returning to unencrypted communication.

By HTTP, I meant in a browser via html/javascript.

The paper didn't explain the implementation of the predicate T(H(P),F(P,K),K) where H and F are one-way hash functions and K is a session key, and why F(H(P),K) won't work. How does the server verify F(P,K) without knowledge of P?

# ? Jan 11, 2009 17:47

ShoulderDaemon: Oct 9, 2003; support goon fund; Taco Defender

zergstain posted:

By HTTP, I meant in a browser via html/javascript.

You'd have to use AJAX or something to handle multiple-exchange authentication techniques, but other than that there's nothing particularly interesting.

zergstain posted:

The paper didn't explain the implementation of the predicate T(H(P),F(P,K),K) where H and F are one-way hash functions and K is a session key, and why F(H(P),K) won't work. How does the server verify F(P,K) without knowledge of P?

The three-way predicate doesn't work with traditional hashing functions. The idea is that given that the server only stores H(P) and is sent F(P,K) from the client, it should be able to combine them somehow to arrive at some G(K) which it can then verify, confirming that the F(P,K) it was sent could only have been made with full knowledge of P and K simultaneously. If the server was only sent F(H(P),K), then the client could have a precomputed H(P) (for example, by gaining readonly access to the server's database).

The most common way I've seen it implemented is with factor-based public keys derived from the passphrase instead of from a random generator; when the account is created, the server memorizes the public component of the generated key and uses that to verify the augmentation signature, while the client regenerates the private component of the key every time the user logs in, by repeating the calculation to derive it from the passphrase. There are alternatives, such as composable hash functions (which are really incredibly hard to make secure). Or passphrase partitioning methods, which require a longer passphrase but can provide similar protections. The augmented SPEKE algorithm family provides a similar solution to A-EKE, but using different primitives you may find easier to understand.

# ? Jan 11, 2009 18:14

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Smackbilly posted:

The best part of reinventing the wheel: you can make it a triangle!

# ? Jan 11, 2009 18:32

RoadCrewWorker: Nov 19, 2007; camels aren't so great

Otto Skorzeny posted:

The best part of reinventing the wheel: you can make it a triangle!

"But, our ground is made from half-spheres with exactly the right radius!" :downs:

# ? Jan 11, 2009 19:52

zergstain: Dec 15, 2005

ShoulderDaemon posted:

You'd have to use AJAX or something to handle multiple-exchange authentication techniques, but other than that there's nothing particularly interesting.

The three-way predicate doesn't work with traditional hashing functions. The idea is that given that the server only stores H(P) and is sent F(P,K) from the client, it should be able to combine them somehow to arrive at some G(K) which it can then verify, confirming that the F(P,K) it was sent could only have been made with full knowledge of P and K simultaneously. If the server was only sent F(H(P),K), then the client could have a precomputed H(P) (for example, by gaining readonly access to the server's database).

The most common way I've seen it implemented is with factor-based public keys derived from the passphrase instead of from a random generator; when the account is created, the server memorizes the public component of the generated key and uses that to verify the augmentation signature, while the client regenerates the private component of the key every time the user logs in, by repeating the calculation to derive it from the passphrase. There are alternatives, such as composable hash functions (which are really incredibly hard to make secure). Or passphrase partitioning methods, which require a longer passphrase but can provide similar protections. The augmented SPEKE algorithm family provides a similar solution to A-EKE, but using different primitives you may find easier to understand.

If it had worked based on my understanding, it would've been trivial to compute F(H(P),K) on the server-side and fail if the client sent a match, but completely worthless against preventing an attacker from sending F(_random,K). The private key is derived just from the passphrase, not the passphrase and the session key, correct? Can neither H nor F be tradition hash functions?

This all sounds like it would be really slow if it were done over javascript. I'd hate to wait 5 minutes to login to some site because of a combination of waiting for next part to come back from the server, and the computations being done over slow-rear end javascript.

# ? Jan 11, 2009 22:24

ShoulderDaemon: Oct 9, 2003; support goon fund; Taco Defender

zergstain posted:

The private key is derived just from the passphrase, not the passphrase and the session key, correct?

The purpose of the three-way predicate is to make the final authentication step depend on both the passphrase and the session key. If this isn't done, there's a MITM attack on the second phase of the authentication.

zergstain posted:

Can neither H nor F be tradition hash functions?

As far as I know, there isn't a system with the right algebraic structure that has either of those traditional, but I've never really thought about it.

zergstain posted:

This all sounds like it would be really slow if it were done over javascript. I'd hate to wait 5 minutes to login to some site because of a combination of waiting for next part to come back from the server, and the computations being done over slow-rear end javascript.

In C implementations the same number of network trips are required, and typically EKE protocols finish in under a few hundred milliseconds. Even full-on S-DH which has to have blinding delays added in for a secure implementation will take less than a second from start to finish. Javascript may be slow, and HTTP may impose a lot of per-message overhead, but it's seriously not going to take that long.

Edit: A far more significant problem would be that you'd be implementing a crypto protocol by hand, which Javascript or no is hand-down one of the single dumbest things you could ever do when programming and there is pretty much never, ever a good excuse for.

ShoulderDaemon fucked around with this message at 22:40 on Jan 11, 2009

# ? Jan 11, 2009 22:38

crazypenguin: Mar 9, 2005; nothing witty here, move along

Without SSL you have no assurances you're talking to who you think you're talking to. An attacker just goes from sniffing to injecting a different .js file that "accidentally" broadcasts your password in plaintext. It prevents passive attacks, but not active ones.

Of course, just about every website in existence puts their login prompts on unsecure pages and just submits to secure ones, which completely destroys the point, and you might as well be using javascript based encryption. (facebook :argh:

)

# ? Jan 12, 2009 00:53

ShoulderDaemon: Oct 9, 2003; support goon fund; Taco Defender

crazypenguin posted:

Without SSL you have no assurances you're talking to who you think you're talking to. An attacker just goes from sniffing to injecting a different .js file that "accidentally" broadcasts your password in plaintext. It prevents passive attacks, but not active ones.

Of course, just about every website in existence puts their login prompts on unsecure pages and just submits to secure ones, which completely destroys the point, and you might as well be using javascript based encryption. (facebook )

Yeah, that is true; most of the protocols are only secure if you assume that the client is not actively trying to compromise itself, which HTTP is remarkably bad at.

# ? Jan 12, 2009 01:01

zergstain: Dec 15, 2005

ShoulderDaemon posted:

The purpose of the three-way predicate is to make the final authentication step depend on both the passphrase and the session key. If this isn't done, there's a MITM attack on the second phase of the authentication.

I thought it would be kinda hard to make the private key match up with the public key if the public was made at registration with just the password (or the password and some random key) and stored on the server, and the private key is made with the password combined with a (different) random key.

# ? Jan 12, 2009 04:31

Zombywuf: Mar 29, 2008

http://gitweb.compiz-fusion.org/?p=...3f547f5d0a4ab1f

The worst thing is that it doesn't even change it++ to ++it.

# ? Jan 17, 2009 00:27

spiritual bypass: Feb 19, 2008; Grimey Drawer

Zombywuf posted:

http://gitweb.compiz-fusion.org/?p=...3f547f5d0a4ab1f

The worst thing is that it doesn't even change it++ to ++it.

Let me make sure I understand the horror here: they replaced a perfectly good iterator with a loop? Please fill me in. I need to understand history to avoid repeating it.

# ? Jan 17, 2009 00:30

floWenoL: Oct 23, 2002

Zombywuf posted:

http://gitweb.compiz-fusion.org/?p=...3f547f5d0a4ab1f

The worst thing is that it doesn't even change it++ to ++it.

What's wrong with this?

# ? Jan 17, 2009 02:36

Zombywuf: Mar 29, 2008

floWenoL posted:

What's wrong with this?

That either the idiomatic usage of an iterator was changed to one that is less clear, or window.erase(x) where x is an iterator, invalidates x. The other alternative is that the dev who made the change has a very wrong understanding of iterators.

# ? Jan 17, 2009 02:46

Zakalwe

May 12, 2002

Wanted For:

Terrorism
Kidnapping
Poor Taste
Unlawful Carnal Gopher Knowledge

Wait isn't that a correct fix for erasing based on an iterator so you don't invalidate the iterator itself? forgive me if I'm wrong here as it's nearly 2am

# ? Jan 17, 2009 02:48

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

Zakalwe posted:

Wait isn't that a correct fix for erasing based on an iterator so you don't invalidate the iterator itself? forgive me if I'm wrong here as it's nearly 2am

The code is unnecessarily complicated and shows that the developer doesn't understand how the return value of erase can be used in a situation like this.

The correct idiom is (with some syntax liberties because gently caress I'm lazy):

code:

list someList;
list::iterator it = someList.begin();

while(it != someList.end())
{
    if(should remove element *it)
        it = someList.erase(it);
    else
        ++it;
}

erase returns a valid iterator to the element after the one being erased, or end if it was the last element. There's no reason to drag temporary variables into this to preserve the iterator position.

Pitfalls like this are why STL algorithms like remove_if exist and hopefully the improved lambda syntax in C++0x will encourage people to start using them more instead of writing their own flawed loops.

# ? Jan 17, 2009 03:05

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Zakalwe posted:

Did you ever get your drat Anschuetz working

# ? Jan 17, 2009 03:09

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Flobbster posted:

This is all well and good, did anyone submit a bug

I mean, the Compiz dev is a senior in high school iirc, he could use all the help he can get :kiddo:

# ? Jan 17, 2009 03:10

floWenoL: Oct 23, 2002

Flobbster posted:

The code is unnecessarily complicated and shows that the developer doesn't understand how the return value of erase can be used in a situation like this.

The correct idiom is (with some syntax liberties because gently caress I'm lazy):

erase returns a valid iterator to the element after the one being erased, or end if it was the last element. There's no reason to drag temporary variables into this to preserve the iterator position.

Eh, that's true, but it's not terribly bad. I didn't think it qualified to be a coding horror.

# ? Jan 17, 2009 03:13

awesmoe: Nov 30, 2005; Pillbug

Flobbster posted:

The code is unnecessarily complicated and shows that the developer doesn't understand how the return value of erase can be used in a situation like this.

The correct idiom is (with some syntax liberties because gently caress I'm lazy):

erase returns a valid iterator to the element after the one being erased, or end if it was the last element. There's no reason to drag temporary variables into this to preserve the iterator position.

Pitfalls like this are why STL algorithms like remove_if exist and hopefully the improved lambda syntax in C++0x will encourage people to start using them more instead of writing their own flawed loops.

Doesn't calling erase on a container invalidate all iterators into that container? (I'm asking, here - I'm not certain). If so, the change made doesn't fix the problem anyway.

# ? Jan 17, 2009 03:18

Smackbilly: Jan 3, 2001; What kind of a name is Pizza Organ! anyway?

awesmoe posted:

Doesn't calling erase on a container invalidate all iterators into that container? (I'm asking, here - I'm not certain). If so, the change made doesn't fix the problem anyway.

For some containers it does, for others it does not. For example: map does not invalidate all iterators on erasure, but deque does.

# ? Jan 17, 2009 03:21

awesmoe: Nov 30, 2005; Pillbug

Smackbilly posted:

For some containers it does, for others it does not. For example: map does not invalidate all iterators on erasure, but deque does.

Hm. Thanks.

# ? Jan 17, 2009 03:27

Zakalwe

May 12, 2002

Wanted For:

Terrorism
Kidnapping
Poor Taste
Unlawful Carnal Gopher Knowledge

Otto Skorzeny posted:

Did you ever get your drat Anschuetz working

Yeah the last 200 rounds I ran through her popped out nicely

I was going to go down to the range tonight and put a box or two of Eley Sport through her, but I got stuck late fixing some code for a paper.

on topic: from a colleague's code earlier on today

//This should not be an odd number!
const int static num_photons = 53;

# ? Jan 17, 2009 04:30

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Decipher with blame logs.

# ? Jan 17, 2009 04:49

Adbot: ADBOT LOVES YOU

# ? May 13, 2024 22:09

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

awesmoe posted:

Hm. Thanks.

Smackbilly is correct, but at the same time erase is still guaranteed to return a valid iterator to the element after the one being erased, regardless of whether the container's semantics invalidate other iterators on erasure.

So if you try to do a trick like the guy in the code fragment posted above where you create a temp, increment it past the element you want to delete, and then delete, that temp iterator might be undefined.

STL algorithms. Use 'em, motherfuckers :colbert:

# ? Jan 17, 2009 14:04

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 »