|
Real life horror: http://www.theregister.co.uk/2016/07/03/mri_software_bugs_could_upend_years_of_research/?mt=1467666616578 We're gonna run out of helium to cool the MRIs before this shitstorm is fixed.
|
#
?
Jul 5, 2016 06:01
|
|
|
|
| # ? Jun 8, 2024 11:53 |
|
|
Carbon dioxide posted:We're gonna run out of helium to cool the MRIs before this shitstorm is fixed. Good news!
|
|
#
?
Jul 5, 2016 06:07
|
|
|
I'm sure pumping the world's supply of helium out into space in the form of party novelties will never come back to bite us.
|
|
#
?
Jul 5, 2016 06:23
|
|
|
quote:The researchers used published fMRI results, and along the way they swipe the fMRI community for their “lamentable archiving and data-sharing practices” that prevent most of the discipline's body of work being re-analysed. Isn't that a description of every research discipline ever?
|
|
#
?
Jul 5, 2016 10:25
|
|
|
Not even 10AM and I've already encountered controller-level view rendering and magic number case clauses in loving Ruby.  It's going to be a long day.
|
|
#
?
Jul 5, 2016 14:59
|
|
|
Look on the bright side: You can start drinking at 10AM. 
|
|
#
?
Jul 5, 2016 15:12
|
|
|
Pollyanna posted:Not even 10AM and I've already encountered controller-level view rendering and magic number case clauses in loving Ruby. Meh, that's basic hacking.
|
|
#
?
Jul 5, 2016 17:59
|
|
|
Something that amused me on reddit: https://www.reddit.com/r/wow/comments/4rhrxu/some_weird_crazy_stuff_going_on_with_a_scam_that/ Someone spots a scammer trying to get people to run commands in their WoW client, later starts seeing friends send private messages containing the same commands. People dig into what's going on and it turns out to be an exploit that overwrites a function that gets called every time a chat message is received, allowing the attacker to run their own code instead. It's then used to silently and remotely take over the victim's client. The basic mantra of "don't run poo poo random people tell you to run" still applies here but it amuses me that this has existed in the game since day one.
|
|
#
?
Jul 6, 2016 18:03
|
|
|
Pollyanna posted:Not even 10AM and I've already encountered controller-level view rendering and magic number case clauses in loving Ruby. 
|
|
#
?
Jul 7, 2016 16:07
|
|
|
Sagacity posted:It's probably best to stop assuming that all code you encounter is completely perfect and refactored to perfection It would be nice to see the occasional example of basic competence, though.
|
|
#
?
Jul 7, 2016 16:20
|
|
|
It's likely not possible to snippet the code, but our front-end datagrid now has click event bindings on all 5k+ *rows* rather than the main grid viewport. I didn't want that JS performance anyway.
|
|
#
?
Jul 7, 2016 23:46
|
|
Cuntpunch posted:It's likely not possible to snippet the code, but our front-end datagrid now has click event bindings on all 5k+ *rows* rather than the main grid viewport. We're doing this where I work, too. We have jQuery DataGrids that can be very large, and they all have at least one "click to expand" event. Some pages have more. I found and fixed a wonderful bug that I cannot believe went unnoticed as long as it did. We had an event function that was binding itself to the event. Every time you performed the action that triggered the function, it would fire x times, and each of those would bind another copy of the function to the event. The first time a page loaded, it fired once, and all was well, except that it rebound itself to the event that triggered it. The second time, it fired twice, and also bound itself twice more. Then four, then eight, then sixteen. After a few clicks, the system would be ground to a halt. It probably doesn't say anything good that none of the users thought this was unusual enough to be worth mentioning. "Oh. Another page that is unusably slow. How quaint."
|
|
|
#
?
Jul 10, 2016 12:18
|
|
|
Centripetal Horse posted:We're doing this where I work, too. We have jQuery DataGrids that can be very large, and they all have at least one "click to expand" event. Some pages have more. I found and fixed a wonderful bug that I cannot believe went unnoticed as long as it did. We had an event function that was binding itself to the event. Every time you performed the action that triggered the function, it would fire x times, and each of those would bind another copy of the function to the event. The first time a page loaded, it fired once, and all was well, except that it rebound itself to the event that triggered it. The second time, it fired twice, and also bound itself twice more. Then four, then eight, then sixteen. After a few clicks, the system would be ground to a halt. It probably doesn't say anything good that none of the users thought this was unusual enough to be worth mentioning. "Oh. Another page that is unusably slow. How quaint." See I could at least understand it if it was something like expandable rows. But the use case itself(capture when the user has clicked on the visible area of the grid) just doesn't demand that sort of supposed solution. Most of the devs I work with use shotgun solutions like this. The amount of * selectors in our styles is...concerning to me.
|
|
#
?
Jul 10, 2016 15:40
|
|
|
"Hi Spatial, you've really excelled here with the CoolProduct 2000 and we'd like you to work on our next big project. It's a life critical application so we have to follow the strictest standards..." I open the project. What do I see? Buffer overflow vulnerabilities built into every function in the core API for absolutely no reason. Parameters passed to functions via void* and cast to the right type at the point of use. Duplicate types and enums with different values in different files. C files with header guards in them. A fundamentally single threaded design in a multi-core embedded system becase "we can move code to the other core later". Bonus prize: unlike the previous project, the full source code will be visible to the customer.
|
|
#
?
Jul 11, 2016 15:08
|
|
|
What it seems like they posted:"Hi Spatial, you've really excelled here with the CoolProduct 2000 and we'd like you to work on our next big project. It's a life critical application so we have to follow the strictest standards..." What they really posted:"Hi Spatial, we're hosed hard and need your help to make this not lovely before our customer demo early next week. BTW you won't get compensated for this. Thanks!"
|
|
#
?
Jul 11, 2016 15:39
|
|
|
Found a couple of fun things while trying to figure out why an image codec does not compile with Java 8. Turns out older compilers allowed access to an uninitialised final field if it's this-qualified.Java code:
|
|
#
?
Jul 11, 2016 16:23
|
|
|
Java's class and instance initialization logic only extremely rarely affect anything, but, boy, when they do, it's amazing.  (In this case, I bet the old compilers were figuring the values had already been initialized because some implicit constructor had already run or something.)
|
|
#
?
Jul 11, 2016 16:49
|
|
|
Some Java:code:Nope! This actually parses into a date: "Sun Aug 16 00:00:00 CST 7" (This date is BC) You can turn this rollover behavior off by doing dateFormat.setLenient(false), but the documentation for that is not very good, and nowhere does it mention the possibility of month/day rollover.
|
|
#
?
Jul 11, 2016 21:10
|
|
|
So wait, it turns -7 into 8 BC, then rolls that over into 7 BC? Awesome.
|
|
#
?
Jul 11, 2016 23:35
|
|
|
I used to be confused why a webservice was giving me dates like "09-07-10007" until I realised they were storing records with no end date as "99999999" and the webservice was just adding 99 months and 99 days to Jan 1 9999.
|
|
#
?
Jul 12, 2016 01:35
|
|
|
Contra Duck posted:I used to be confused why a webservice was giving me dates like "09-07-10007" until I realised they were storing records with no end date as "99999999" and the webservice was just adding 99 months and 99 days to Jan 1 9999. Was this epic? Cuz that sounds like something I could explain if it was .
|
|
#
?
Jul 12, 2016 05:18
|
|
|
Same lenient formatting but they used 00000000 to indicate that they didn't have a date. Year 0 AD wraps around to 1 BC. Month 0 becomes month 12 of the previous year so December 2 BC, and then day 0 becomes the last day of the previous month resulting in November 30, 2 BC.
|
|
#
?
Jul 12, 2016 09:11
|
|
|
LeftistMuslimObama posted:Was this epic? Cuz that sounds like something I could explain if it was Nah on the other end was some monolithic banking mainframe where 'null' wasn't an option so they used a bunch of bizarre workarounds instead.
|
|
#
?
Jul 13, 2016 01:28
|
|
|
Hey guys we need a consistent style for this new project.C++ code:
|
|
#
?
Jul 13, 2016 16:57
|
|
|
Digital hardware designers are the god kings of bad programming. Their unbeatable mastery of being terrible is beyond the ken of the mortal realm. God help me, please.
|
|
#
?
Jul 13, 2016 17:15
|
|
|
Spatial posted:Digital hardware designers are the god kings of bad programming. Their unbeatable mastery of being terrible is beyond the ken of the mortal realm. I feel like I've already mentioned the piece of code that had a huge empty loop, which I had first assumed had to do with timing for the hardware, until I found out that what was really creating the necessary delays was a judicious use of reads from the printer port.
|
|
#
?
Jul 13, 2016 17:21
|
|
|
Absurd Alhazred posted:I feel like I've already mentioned the piece of code that had a huge empty loop, which I had first assumed had to do with timing for the hardware, until I found out that what was really creating the necessary delays was a judicious use of reads from the printer port. yep, no way that could ever lead to a vulnerability, no sir.
|
|
#
?
Jul 13, 2016 19:17
|
|
|
Kilson posted:Some Java: Oh god, that's an old java.util.Date isn't it? That's the old crappy implementation you never ever want to touch anymore. Use java.time.LocalDate (and the java.time.format.DateTimeFormatter for formatting Strings) if you can use Java 8. Otherwise, import and use the Joda Time library, which is the same thing, it just got internalized as java.time in Java 8.
|
|
#
?
Jul 13, 2016 19:20
|
|
|
LeftistMuslimObama posted:yep, no way that could ever lead to a vulnerability, no sir. If someone had hardware access to that machine during initialization then using that somehow would be the least of their worries. Anyway, it doesn't do anything with the data from that read.
|
|
#
?
Jul 13, 2016 19:25
|
|
|
Absurd Alhazred posted:If someone had hardware access to that machine during initialization then using that somehow would be the least of their worries. Anyway, it doesn't do anything with the data from that read. This statement assumes there are no other defects in the code that would enable the attacker to use this to get data into memory and use other vulnerabilities to do stuff with it. Not saying it's super likely, but why feel safe behind a locked door when you left the window open, ya know?
|
|
#
?
Jul 13, 2016 19:27
|
|
|
LeftistMuslimObama posted:This statement assumes there are no other defects in the code that would enable the attacker to use this to get data into memory and use other vulnerabilities to do stuff with it. Not saying it's super likely, but why feel safe behind a locked door when you left the window open, ya know? If you even got to a point where you were running this program, you had the type of access where you wouldn't need to use any buffer overflow vulnerabilities I probably left there to inject code that would then somehow read additional data from the port (and even then, why do that when you could just do it inside the buffer overflow anyway?). It would be more like locking an internal window, not an outside-facing one. The more I think about the architecture I built there, the more I'm glad that I didn't work there very long, because this would have come back to bite me.
|
|
#
?
Jul 13, 2016 19:44
|
|
|
Absurd Alhazred posted:The more I think about the architecture I built there, the more I'm glad that I didn't work there very long, because this would have come back to bite me. Everyone has at least one job like this.
|
|
#
?
Jul 13, 2016 20:08
|
|
|
code:
|
|
#
?
Jul 13, 2016 20:19
|
|
|
Carbon dioxide posted:Oh god, that's an old java.util.Date isn't it? That's the old crappy implementation you never ever want to touch anymore. Use java.time.LocalDate (and the java.time.format.DateTimeFormatter for formatting Strings) if you can use Java 8. Otherwise, import and use the Joda Time library, which is the same thing, it just got internalized as java.time in Java 8. Oh, definitely. Some of that handling code was written several years ago before Java8, and apparently nobody knew about Joda. Actually, 90% of our time/date handling just uses java.util.Date though. 
|
|
#
?
Jul 13, 2016 20:27
|
|
|
Spatial posted:Digital hardware designers are the god kings of bad programming. Their unbeatable mastery of being terrible is beyond the ken of the mortal realm. Dehumanize yourself and face towards embedded.
|
|
#
?
Jul 13, 2016 23:46
|
|
|
php:<?
function is_equal($val1, $val2) {
if ($val1 == $val2) {
return true;
} else {
return false;
}
}
?>php:<? (is_equal($selected, $selected) ? "selected" : "") ?> bobthecheese fucked around with this message at 02:59 on Jul 15, 2016 |
|
#
?
Jul 15, 2016 02:48
|
|
|
I think I see the problem: you're using PHP.
|
|
#
?
Jul 15, 2016 02:58
|
|
|
bobthecheese posted:
After reading this thread for a years, I can't tell if this is bad because it's just dumb code or if it's actually needed because php equality testing is that broken
|
|
#
?
Jul 15, 2016 03:04
|
|
|
Contra Duck posted:After reading this thread for a years, I can't tell if this is bad because it's just dumb code or if it's actually needed because php equality testing is that broken Its dumb code. If it used "===" it might've been excusable, but not with "==".
|
|
#
?
Jul 15, 2016 09:00
|
|
|
|
| # ? Jun 8, 2024 11:53 |
|
|
I mostly use ====, or ===== when I need to be absolutely sure things are identical
|
|
#
?
Jul 15, 2016 09:07
|
|