|
Janin posted:Clearly that should be: code:
|
# ? Feb 10, 2010 20:05 |
|
|
# ? Jun 6, 2024 06:11 |
|
^oh god whyJanin posted:sweet jesus
|
# ? Feb 10, 2010 20:10 |
|
Standish posted:The Coverity guys have seen more bad code than anyone code:
|
# ? Feb 10, 2010 20:21 |
|
The getuid one took me a couple minutes to see
|
# ? Feb 10, 2010 20:28 |
|
Otto Skorzeny posted:The getuid one took me a couple minutes to see Is it because of the geteuid == 0? I really know nothing about this kind of stuff...
|
# ? Feb 10, 2010 21:29 |
|
ryanmfw posted:Is it because of the geteuid == 0? http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-later/fulltext#FND
|
# ? Feb 10, 2010 21:39 |
|
ryanmfw posted:Is it because of the geteuid == 0? Yep. The bare name of a function degrades to the address of the function (given int foo(), foo and &foo are equivalent, assuming no parens in either case). The address of the function is never going to be zero, so the check is always true. e: beaten
|
# ? Feb 10, 2010 21:41 |
|
One more from from this wonderful php website.... "Hey -- this report I run, it comes back with only 100 or so results, but it takes almost five minutes. You think you might be able to make it faster?" code:
|
# ? Feb 10, 2010 22:41 |
|
Maybe joins killed the author's family?
|
# ? Feb 10, 2010 22:54 |
|
today's been an unmitigated hell of lovely codecode:
|
# ? Feb 11, 2010 01:47 |
|
Standish posted:The Coverity guys have seen more bad code than anyone That's actually a very well written piece; particularly on the commercialization of programming and the follow-on reduction of overall programmer quality. I mean... stupid bug checker... doesn't even understand arrays properly!
|
# ? Feb 11, 2010 02:08 |
|
Found by one of our contractors - Written by the office idiot who should have been fired long ago.php:<?php switch($reply['decision']) { //essentially we are processing the reply in the //controller and not here. If we decide to move //the decsion handling here, these are the cases case 'ACCEPT': case 'REJECT': return $reply; // return everything break; case 'ERROR': //this is when cybersource processed the //transaction and ERROR was return //this may be processor specific and is not //the same as the errors handled in the else return $reply; break; default: return $reply; } ?> ... And if you dont get the signifigance - He was storing the raw request, which included full CC number, expiration date, cardholder name and CVV - ALL UNENCRYPTED IN loving JSON SYNTAX IN A loving MYSQL DATABASE.
|
# ? Feb 11, 2010 03:21 |
|
Janin posted:
I read that as "true == false," and it sounded like some poo poo out of 1984.
|
# ? Feb 11, 2010 04:17 |
|
Janin posted:today's been an unmitigated hell of lovely code Ignoring the obvious shittiness, putting the variable on the right and the constant on the left of a comparison is quite the minor annoyance. Edit: oh hey, people were talking about this 2 pages back and i didnt notice Rahu fucked around with this message at 07:52 on Feb 11, 2010 |
# ? Feb 11, 2010 07:37 |
|
Something I saw today (typing from memory):code:
|
# ? Feb 11, 2010 08:34 |
|
WildFoxMedia posted:If this doesn't make you angry, lemme add to this. This is part of a checkout setup and cybersource is the name of the CC gateway. The idiot who wrote this code also thought it was a stellar idea to store the raw request and raw response to/from cybersource. Haha that's horrible. We've recently started doing some work involving a payment gateway and the very first thing that legal, engineering, product management, and accounting all got on board for was NEVER LET CREDIT CARD INFO TOUCH OUR NETWORK. The lengths we have to go to avoid that arguably spawn their own coding horrors but the wrath that can be brought down upon your company for storing CC info insecurely can literally destroy your business. Aside from the legal liabilities it exposes you to, the community of payment gateways will simply stop doing business with you if you're found out of compliance.
|
# ? Feb 11, 2010 18:24 |
|
WildFoxMedia posted:If this doesn't make you angry, lemme add to this. This is part of a checkout setup and cybersource is the name of the CC gateway. The idiot who wrote this code also thought it was a stellar idea to store the raw request and raw response to/from cybersource. I said something about storing CC#s unencrypted in the database at the place I used to work and the boss basically waved his hand and said the network was pretty secure and that we would tell the people who bought our software (that we also used internally) to secure theirs and that would be just fine. Several weeks later the network got really slow for some reason. A couple of days after that I got fed up with the slow network and looked around - the Tx light on the switch that the SQL server was plugged into was solid green not because we were using it heavily but because it had been recruited into a botnet and was sending as much spam as possible over our T1 all day and night. I'm sure installing AVG Free the next day turned out to be a perfect, permanent solution for them
|
# ? Feb 11, 2010 20:39 |
|
My bosses care, they do - They just had no idea. Neither of my bosses are developers. One is a career network/server admin, the other a marketing/sales person so they rarely involve themselves in this kind of stuff. I let my network/server admin boss know that it happened and the color instantly drained from his face. The only thing I could really do was to truncate the raw_request column for the entire table and let the contract developer know to use his brain more then than the original developer had when it came to logging transactions.
|
# ? Feb 11, 2010 23:21 |
|
Contra Duck posted:No, it was not the right date format. Not that return true is the right way to handle that by any measure - but dates are really, really annoying to deal with on a consistent basis, when every last detail (what exchange they are on, what the time zone is, when it closes, etc.) matters.
|
# ? Feb 12, 2010 01:48 |
|
Bozart posted:Not that return true is the right way to handle that by any measure - but dates are really, really annoying to deal with on a consistent basis, when every last detail (what exchange they are on, what the time zone is, when it closes, etc.) matters. By "every last detail" do you mean "what time it actually is"?
|
# ? Feb 12, 2010 11:09 |
|
Zombywuf posted:By "every last detail" do you mean "what time it actually is"? He's talking about specifics of various stock exchanges around the world related to date and time zone.
|
# ? Feb 12, 2010 16:48 |
|
And so it's okay to call all inputs valid because it's hard?
|
# ? Feb 12, 2010 17:18 |
|
ErIog posted:He's talking about specifics of various stock exchanges around the world related to date and time zone. What time it actually is. I'm going to make the assumption that you've never had to deal with your code interacting with people outside your monkeysphere.
|
# ? Feb 12, 2010 17:52 |
|
Jesus, I never loving said the code wasn't a travesty. I was simply agreeing that working on a project where core functionality of the app changes based on the date/time of many places around the world is not trivial. I don't see how that was construed into me giving my blessing to the offending code. I was responding to a side comment about a general thing that happened to come out of someone responding to the code. This obviously makes me a horrible programmer that is not fit to speak of programming with the likes of the great Zombywuf. ErIog fucked around with this message at 19:54 on Feb 12, 2010 |
# ? Feb 12, 2010 19:51 |
|
Any code that deals with dates can so quickly turn into a horror. That's why you take whatever the date is, convert it to seconds since the epoch, and don't convert back until you're showing the drat thing to a live human being. If you decide you want to delve into the black pit of time zones, leap years (with all of the exceptions), leap seconds, semivalid time values (77 minutes past the hour), missing dates, 12hour vs. 24 hours, etc... Well, all I can say is here's your handbasket, enjoy your trip. And don't forget that the C stdlib stores months from 0 to 11 (but days from 1 to 31), and years - 1900.
|
# ? Feb 12, 2010 22:06 |
|
On the subject of dates and time, I ran into an issue recently. I'm working on a website that tracks multiplayer games of Civilization IV. One of the features of the Civ IV Server (called "Pitboss") is a "Turn Timer". This can be set to a number, like 8 hours, and if a player doesn't play his turn in that window, he is skipped for that turn. It keeps the already slow-moving game moving ahead, even if someone doesn't log in for a day or so. One of the requested features for the website was to put this turn timer on the game page, so that players of a game can browse to their game on the website, and see how long until the turn ended. Not a problem. Without getting into the specifics of the application, it sits on the Pitboss server and screen-scrapes the window. I scraped the Turn Timer, which is in the format of "7:45:20". Whenever the scraper sees a change in the timer, where the new time is greater than the old one, I generate an event, and hit my webserver, letting it know the new turn timer value. A PHP script would handle the event, convert the "time string" into a PHP time modifier string, like "+7 hours 45 minutes +20 seconds". This could be used with PHP's strtotime function to add it easily enough, without me having to "worry about" manipulating seconds since the epoch. I then stored the final value, as seconds since the epoch, in the database. This value was the time at which the timer was supposed to end. A little JavaScript now showed a countdown to that time. Done. Simple enough. I soon had people complaining that the turn timer on my website was wrong. That it was "expiring" before the timer was up. I looked through my code for math errors, and found one, but it didn't seem to impact anything. I thought for a second it might have been a timezone thing, but it wasn't. I was stumped. I ended up just watching the turn timer run it's course, and set up my screen scraper to put out a lot of debugging infromation. And then I saw it. The turn timer in the application was slow. A second was closer to ~1.2 seconds, and variable. I don't even know how that's loving possible, that this clock could just be wrong like this. Over the course of hours, the turn timer would be "off" by minutes. On top of that, whenever the server application goes under stress, such as transferring data to a player logging in, or processing a turn, the timer seems to stop entirely. I ended up just saying "gently caress it" to the elegance of event handling, and just made it update the turn timer on the website every 5 minutes, so it's never more than a few seconds off.
|
# ? Feb 12, 2010 22:23 |
|
Zombywuf posted:By "every last detail" do you mean "what time it actually is"? Time and locality are very easy to mess up - and when you rely on someone else to tell you what time it is for whatever information they are giving you, in whatever (excel, probably) format they feel like using, it gets messier. How about that extra or missing hour for daylight savings? Sometimes an electric grid operator (ISO) says it doesn't exist. Sometimes they say it exists some years but not others. And there is a price at every node every 15 minutes in realtime power - and a different price every 15 minutes for day ahead power, and a different price every tick for future dates which actually constitute a range of time, so yeah, tell me exactly what time is - because it means something else to the next guy. Grid operators use different definitions for what time zone it is, so you can't ignore it. Transmission pricing could be between two different time zones. Those two different locations can be going on two different calendars for what constitutes holidays. Those 15 minute intervals means that if they are in two different time zones, some power is on peak and some power is off peak, so congratulations you need to compare different combinations of power prices in your transmission models to figure out how to trade it. Everything that happens has about 4 times associated with it - when it happens, when it is for, when you find out, and when you update it. And that isn't counting when you have to specify ranges of times because gently caress it we'll just call them different contracts and look that up somewhere else. Those are the things I had to deal with today, there are other ones dealing with when you can exercise options on those contracts (and yes, those options have plenty of times associated with them, depending on type of option), or what sort of information you need to compare something that is provided by tick against something that is provided by day (hint: you can't just use an average!), or the for one commodity. And you have to just take what you can get because some of these things are only provided by a few idiots who don't know a thing about computers but somehow became indispensable. And they'll get the numbers wrong.
|
# ? Feb 13, 2010 00:31 |
|
"Don't write XML by hand, use this library we wrote, it'll prevent typos" Oh, OK, let me just take a peek at how it works... code:
"What happens if the user enters an apostrophe in the description?" "We don't worry about stuff like that, as long as it just works. If things were rewritten just because they could fail sometimes, nothing would get done!" The answer, by the way, is that if a user enters an apostrophe it'll crash the (multi-user) server and kick everybody else off.
|
# ? Feb 13, 2010 03:49 |
|
Bozart posted:So yeah, what time it actually is at the time of the event you're interested in. I work with airline timetables for a living, simply determining the time a flight takes off or lands is the easy bit. I think you need to simplify your systems internal model a bit.
|
# ? Feb 15, 2010 13:17 |
|
Zombywuf posted:So yeah, what time it actually is at the time of the event you're interested in. That's the major complication with financial dealings. What you want it is accurate time series data with no drop-outs. But that's not what the real world provides. Sometimes the event you care about (a price usually), at the time you are interested, simply does not exist. Financial data is very, very dirty. By contrast, your planes always land, one way, or another.
|
# ? Feb 15, 2010 14:53 |
|
BigRedDot posted:That's the major complication with financial dealings. What you want it is accurate time series data with no drop-outs. But that's not what the real world provides. Sometimes the event you care about (a price usually), at the time you are interested, simply does not exist. Financial data is very, very dirty. By contrast, your planes always land, one way, or another. A price only exists because there is a bid or sell order in play at the time. If no bids or offers are outstanding there is no price. Just because a data transmission failed doesn't mean you get to whinge about how hard matching up dirty datetimes you failed to cleanup on entry to your system is. All data is dirty on point of entry to your system, I'm currently trying to do a black box diagnosis of a remote system to work out if the data they're sending us is wrong or the data we send them is. Currently it looks like garbage in is garbage out and back in again. Processed through garbage. Also, planes don't always land after they take off, some have been known to drop out of the sky as a result.
|
# ? Feb 15, 2010 17:36 |
|
Munkeymon posted:I said something about storing CC#s unencrypted in the database at the place I used to work and the boss basically waved his hand and said the network was pretty secure and that we would tell the people who bought our software (that we also used internally) to secure theirs and that would be just fine. The day they track an intersecting set of numbers back to your business is going to be an interesting one. In the UK, virtually all commercial website producers recoil from storing CC information because of the liabilities, and the US is going to head that way after the PCI compliance really starts to hit. 'pretty secure' doesn't fill me with confidence, though. You might want to drop someone an email about your concerns, then print the email and mail it to yourself.
|
# ? Feb 15, 2010 19:03 |
|
Zombywuf posted:If you think that's bad I had to work with a guy who would dismiss other peoples problems at face value because of their simplified explanation, only then to whine about his problems in a similar manner.
|
# ? Feb 15, 2010 20:27 |
|
Besides the obvious Wicker Man poo poo, this sort of thing is why programmers ought to beware of Scotland
|
# ? Feb 15, 2010 20:36 |
|
Hav posted:The day they track an intersecting set of numbers back to your business is going to be an interesting one. In the UK, virtually all commercial website producers recoil from storing CC information because of the liabilities, and the US is going to head that way after the PCI compliance really starts to hit. It's the place I used to work and if it hasn't gone under by now, I'd be a little surprised. The place I work now is PCI compliant, but only because one of our clients said they would stop dealing with us if we didn't get certified. This (current) place has always had an aversion to storing CC#s, so IIRC all we had to do was update the horribly old, insecure version of Apache some of our servers were still using and promise not to store certain information (that we already weren't touching) on our servers. Now if PayPal ever gets cracked open, I'm sure we'll have a fun week explaining in excruciating detail how it's not actually our fault that people who bought our service are suddenly buying $10,000 stereo equipment in exotic locations in Eastern Europe and China they've never been to because the average user doesn't really get that PP is a third party.
|
# ? Feb 15, 2010 21:14 |
|
Zombywuf posted:So yeah, what time it actually is at the time of the event you're interested in. No, that is just how it works. Every exchange has its own calendar of holidays, every contract has an associated exchange (or is otc and has an effective exchange but associated credit risk) and every price has an associated contract. Sometimes those contracts have some other dates associated with them as well, sure. But the things that we care about on a minute to minute basis aren't ever going through an exchange. Things like gas basis spreads might only trade a few times a day depending on their tenor, and when you are looking at market heat rates (one of the most important things in the energy industry - by dividing the power price by the gas price, you know which power plants "should" be operating, which tells you all about demand on the gas side and supply on the power side) the power price might trade a lot and the gas only a little. Maybe you use a similar delivery point, or a different tenor of contract, or who knows what. Ultimately how you connect prices is where the typical econometrics that people use breaks down into some kind of state estimation problem. So saying that "the data is dirty" simultaneously explains a lot and absolutely nothing. You're treating another system as a black box - oddly enough I work with black boxes as well. But the ones I have to use essentially create or take money from other people, and the people that execute their orders don't exactly react happily to the idea that because UK Power only traded 10 lots for the Q1 2011 contract, that they just lost half a million dollars. There is no clean way of doing any of it, and you either deal with it and pray you don't get too unlucky for too long a period of time, or you find another line of work. Or maybe you are unlucky and you find another line of work anyway.
|
# ? Feb 16, 2010 06:18 |
|
Bozart posted:I'm not quite sure you realize this yet, but Zombywuf of course knows more about the domain you're working in than you ever will. You should be thankful for his condescension.
|
# ? Feb 16, 2010 08:17 |
|
ryanmfw posted:I'm not quite sure you realize this yet, but Zombywuf of course knows more about the domain you're working in than you ever will. You should be thankful for his condescension. I just hate all you guys and all software.
|
# ? Feb 16, 2010 10:48 |
|
Bozart posted:You're treating another system as a black box - oddly enough I work with black boxes as well. But the ones I have to use essentially create or take money from other people, and the people that execute their orders don't exactly react happily to the idea that because UK Power only traded 10 lots for the Q1 2011 contract, that they just lost half a million dollars. There is no clean way of doing any of it, and you either deal with it and pray you don't get too unlucky for too long a period of time, or you find another line of work. Or maybe you are unlucky and you find another line of work anyway. Hey, guess what my black box does, only mine does it with human eyeballs not units of soulless energy. You've wandered pretty far from your original complaint through.
|
# ? Feb 16, 2010 10:50 |
|
|
# ? Jun 6, 2024 06:11 |
|
Zombywuf posted:Hey, guess what my black box does, only mine does it with human eyeballs not units of soulless energy. he claims his "creates" money, too, which is interesting
|
# ? Feb 16, 2010 11:02 |