|
Drastic Actions posted:That was the issue. The QA tester had zero clue what that was. i thought it was a crude attempt at a cat.... these are the ones that tend to confuse people i know o/ \o \o/ o7
|
#
?
Jun 11, 2015 06:35
|
|
.
|
|
| # ? May 26, 2024 23:38 |
|
|
Factor Mystic posted:http://blog.parse.com/learn/how-we-moved-our-api-from-ruby-to-go-and-saved-our-sanity/ So they're leaving one creeping horror for another.
|
|
#
?
Jun 11, 2015 08:20
|
|
only
|
Here's a security patch being applied to openssl in 2011.pre: if (!BN_GF2m_mod(u, a, p)) goto err;
if (BN_is_zero(u)) goto err;
if (!BN_copy(v, p)) goto err;
#if 0
if (!BN_one(b)) goto err;
while (1)
{
while (!BN_is_odd(u))
{
+ if (BN_is_zero(u)) goto err;
if (!BN_rshift1(u, u)) goto err;
if (BN_is_odd(b))
{
if (!BN_GF2m_add(b, b, p)) goto err;
}
if (!BN_rshift1(b, b)) goto err;
}
if (BN_abs_is_word(u, 1)) break;
if (BN_num_bits(u) < BN_num_bits(v))
{
tmp = u; u = v; v = tmp;
tmp = b; b = c; c = tmp;
}
if (!BN_GF2m_add(u, u, v)) goto err;
if (!BN_GF2m_add(b, b, c)) goto err;
}
#else
{
int i, ubits = BN_num_bits(u),
|
|
#
?
Jun 11, 2015 19:30
|
|
|
ctz posted:Here's a security patch being applied to openssl in 2011. The openssl codebase is loving awful. I'm the #if 0 block.
|
|
#
?
Jun 11, 2015 19:44
|
|
|
apseudonym posted:The openssl codebase is loving awful. Isn't that just a convoluted way to comment out a block of code?
|
|
#
?
Jun 11, 2015 20:13
|
|
|
Amberskin posted:Isn't that just a convoluted way to comment out a block of code? Not convoluted, its the only way to block comment out a huge chunk of code that may include block comments(short of adding // to every line). Now, should that be in actual released code? no, #if 0 probably shouldn't. Also lol at the idea of openssl having comments anyways.
|
|
#
?
Jun 11, 2015 20:20
|
|
|
apseudonym posted:Not convoluted, its the only way to block comment out a huge chunk of code that may include block comments(short of adding // to every line). if statements are compile time anyways, so not a huge problem.
|
|
#
?
Jun 11, 2015 20:26
|
|
|
ratbert90 posted:if statements are compile time anyways, so not a huge problem. The problem with #if 0 in your code is unrelated to performance or binary size.
|
|
#
?
Jun 11, 2015 20:31
|
|
|
apseudonym posted:The problem with #if 0 in your code is unrelated to performance or binary size. Still not seeing a huge problem. Most IDE's will grey out the area and it's pretty clear it's a comment block. 
|
|
#
?
Jun 11, 2015 20:32
|
|
|
ratbert90 posted:Still not seeing a huge problem. Most IDE's will grey out the area and it's pretty clear it's a comment block. If your code base has blocks of commented out code that would be a horror.
|
|
#
?
Jun 11, 2015 20:34
|
|
|
Yeah, commented out code blocks shouldn't make it into the repository. If you have something from an old version you want to preserve, use your version control system.
|
|
#
?
Jun 11, 2015 20:37
|
|
|
Oh well yeah, I was talking about development. Wait, that's not just a one off thing for the openssl code? It's literally sitting in production like that? 
|
|
#
?
Jun 11, 2015 20:39
|
|
|
ratbert90 posted:Oh well yeah, I was talking about development. Well, it's being diffed right there, so I assume so.
|
|
#
?
Jun 11, 2015 20:50
|
|
|
fleshweasel posted:Yeah, commented out code blocks shouldn't make it into the repository. If you have something from an old version you want to preserve, use your version control system. In the past, our server code couldn't be placed into version control because MUMPS code is stored inside the MUMPS database. Instead, we commented out code for X number of versions and then deleted it if we didn't end up needing it. Now we have a jerry-rigged thing that exports code from the database and puts it in SVN when we mark the code as being done, but reverting involves having to do a messy import of whatever version of the code you need back and then recompiling everything that references.
|
|
#
?
Jun 11, 2015 21:10
|
|
|
ratbert90 posted:Oh well yeah, I was talking about development. The openssl code base is full of #if 0's, #ifdefs that wouldn't build if anyone ever set that flag, and just awful to read code. Basically what I'm saying is gently caress openssl, I just wish all the other SSL libraries weren't worse 
|
|
#
?
Jun 11, 2015 21:26
|
|
|
Some days it feels like we've built this terrible house of cards with OpenSSL and all the other foundational internet technologies and it's going to collapse. Am I just crazy?
|
|
#
?
Jun 11, 2015 21:28
|
|
|
Thermopyle posted:Some days it feels like we've built this terrible house of cards with OpenSSL and all the other foundational internet technologies and it's going to collapse. Yes, OpenSSL is going to collapse. Any day now somebody is going to discover some security vulnerability that could theoretically leak the entire memory contents of a server including private keys. This vulnerability might even have been in the wild for years and it'd be impossible to know who, if anybody, has been exploiting it. My heart really bleeds for those people potentially affected by it.
|
|
#
?
Jun 11, 2015 21:40
|
|
|
Thermopyle posted:Some days it feels like we've built this terrible house of cards with OpenSSL and all the other foundational internet technologies and it's going to collapse. I mean Heartbleed kind of shows you aren't e: oh I guess I had this tab open for a while first welp
|
|
#
?
Jun 11, 2015 21:47
|
|
|
No Safe Word posted:I mean Heartbleed kind of shows you aren't gonadic io posted:Yes, OpenSSL is going to collapse. Any day now somebody is going to discover some security vulnerability that could theoretically leak the entire memory contents of a server including private keys. This vulnerability might even have been in the wild for years and it'd be impossible to know who, if anybody, has been exploiting it. My heart really bleeds for those people potentially affected by it. Yeah, but...nothing really collapsed did it? People freaked out and addressed the issue and we're out here posting poo poo on the internet still. It felt like the internet barely skipped a beat. I guess I am crazy, because I suppose the people-freaking-out-and-then-fixing-the-problem will always happen...
|
|
#
?
Jun 11, 2015 21:50
|
|
|
Thermopyle posted:Yeah, but...nothing really collapsed did it? People freaked out and addressed the issue and we're out here posting poo poo on the internet still. It felt like the internet barely skipped a beat. And then this happened and all of the crawling horrors started getting pulled to the surface.
|
|
#
?
Jun 11, 2015 21:53
|
|
|
In 1995 or so, everyone freaked out about this crazy problem where a bunch of idiots decided to save space by storing the year in two digits instead of four, and the world was going to end in 2000. 2000 rolled around and nothing happened. Because people realized there was a problem and worked hard to fix it.
|
|
#
?
Jun 11, 2015 21:56
|
|
|
fleshweasel posted:Yeah, commented out code blocks shouldn't make it into the repository. If you have something from an old version you want to preserve, use your version control system. This seems to be conventional wisdom, but does it hold up? Of course anything that's ever been committed is in the version control system, but someone looking at a file isn't going to be aware if there is some useful code that was excised from the file and is sitting in the version control system. If you were around when the old version was in place and you know that it's there then great, but people leave and new people come in and the newer people won't know that something else was once there, aside from a general awareness that the code of course has a version history. Commented-out code is bad but I don't think "it's in the version history" is adequate as reasoning for why not to do it.
|
|
#
?
Jun 11, 2015 21:57
|
|
|
Dessert Rose posted:In 1995 or so, everyone freaked out about this crazy problem where a bunch of idiots decided to save space by storing the year in two digits instead of four, and the world was going to end in 2000. Never fear, 2038 is just around the corner, we can still gently caress it up!
|
|
#
?
Jun 11, 2015 22:02
|
|
|
Hammerite posted:This seems to be conventional wisdom, but does it hold up? Of course anything that's ever been committed is in the version control system, but someone looking at a file isn't going to be aware if there is some useful code that was excised from the file and is sitting in the version control system. If you were around when the old version was in place and you know that it's there then great, but people leave and new people come in and the newer people won't know that something else was once there, aside from a general awareness that the code of course has a version history. I think all of this can be flipped on its head. Code isn't useful unless it's in use. Code that isn't in use can't be maintained, doesn't get maintained, undergoes attrition and becomes progressively less useful. Very quickly it becomes a misleading signpost, worse than useless. New people come in and have no idea why the code has been commented out, what purpose it served, or under what circumstances it would ever be commented back in again. It never gets resurrected and just takes up space. If there's important code which coders need to see, but which shouldn't actually be in the codebase, then the correct location for that code is in documentation. qntm fucked around with this message at 22:22 on Jun 11, 2015 |
|
#
?
Jun 11, 2015 22:17
|
|
|
xzzy posted:Never fear, 2038 is just around the corner, we can still gently caress it up! Wasn't there an issue in Oracle where large databases started to have data loss because of an integer overflow? I remember reading something about it a long time ago but can't find anything.
|
|
#
?
Jun 11, 2015 22:32
|
|
|
necrotic posted:Wasn't there an issue in Oracle where large databases started to have data loss because of an integer overflow? I remember reading something about it a long time ago but can't find anything. There were some integer overflow issues with quicksort (and others) a few years ago: http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html http://bugs.java.com/bugdatabase/view_bug.do?bug_id=5045582 tyrelhill fucked around with this message at 00:11 on Jun 12, 2015 |
|
#
?
Jun 12, 2015 00:08
|
|
|
Dessert Rose posted:In 1995 or so, everyone freaked out about this crazy problem where a bunch of idiots decided to save space by storing the year in two digits instead of four, and the world was going to end in 2000. What made me laugh was "at midnight dec 31st 1999 any plane in the air will suddenly turn off , and baby incubators and heart lung machines will stop working because they will think its 1900 and they didnt exist then so cannot continue to work" ok so the reports and such will have an incorrect date, but why would that stop a heater keeping a constant temperature or stop fuel flowing into the plane engines? Some of the claims were just stupid.. i mean what power station knows what to do just because it is a certain date.. time maybe, but date? WTF!!!
|
|
#
?
Jun 12, 2015 07:18
|
|
|
TheresaJayne posted:What made me laugh was "at midnight dec 31st 1999 any plane in the air will suddenly turn off , and baby incubators and heart lung machines will stop working because they will think its 1900 and they didnt exist then so cannot continue to work" Taking part in this thread, you're willing to make the bet that various systems weren't doing absolutely ridiculous things with date/time? Every broken thing in this thread could be summed up as, "But why would...???" The tragedy of Y2K is that it was handled too well, and so people erroneously assumed it hadn't ever been a real problem.
|
|
#
?
Jun 12, 2015 07:33
|
|
|
TheresaJayne posted:Some of the claims were just stupid.. i mean what power station knows what to do just because it is a certain date.. time maybe, but date? WTF!!! Many safety-critical systems probably have failsafes that make them shut down if some crazy consistency is noticed, like time going backwards. That said, the year 2000 problem was most prevalent in Cobol code, where numeric fields could (and often was) be defined with precision given as the number of decimal digits. Since I don't think Cobol ever had penetration outside of banks, that is where most of the issues would have appeared, and it was a real issue. However, few systems look at just the current time - especially in banking software, it is probably not uncommon to generate dates a few years into the future, which means that the year 2000-bugs were actually encountered and fixed in the years running up to the end of the millennium, not on New Years itself.
|
|
#
?
Jun 12, 2015 08:58
|
|
|
Given that banks have to deal with mortgages and other long-term loans and investments, I'd imagine the Y2K thing was discovered and fixed by the mid 80s at the latest.
|
|
#
?
Jun 12, 2015 09:46
|
|
|
xzzy posted:Never fear, 2038 is just around the corner, we can still gently caress it up! Or our laziness could be what saves us from Skynet
|
|
#
?
Jun 12, 2015 12:09
|
|
|
qntm posted:I think all of this can be flipped on its head. Code isn't useful unless it's in use. Code that isn't in use can't be maintained, doesn't get maintained, undergoes attrition and becomes progressively less useful. Very quickly it becomes a misleading signpost, worse than useless. New people come in and have no idea why the code has been commented out, what purpose it served, or under what circumstances it would ever be commented back in again. It never gets resurrected and just takes up space. I think this is the key point here. I have left commented code in a couple of times, but it was something like this: code:
|
|
#
?
Jun 12, 2015 13:15
|
|
|
Sweevo posted:Given that banks have to deal with mortgages and other long-term loans and investments, I'd imagine the Y2K thing was discovered and fixed by the mid 80s at the latest. Actually, no. The real effort begun about 1995, and its peak was about 1998-1999. The european banks had to handle the conversion to the Euro aproximately at the same time, so things became a little bit hectic. The applications which had to manage future dates were Y2K-ready from their inception. The main problem was in the applications which look at the past (checking accounts, savings accounts and so on), and in the file interfaces between different applications. As someone posted before, there was no real impact on 01/01/2000 because a lot of people put a lot of effort to fix (or patch) it. Actually, the problem was more patched than fixed: the fields that contained dates were left as they were (two digit years), and the interpretation of those dates was changed, so anything less than '50' is assumed to be 20XX, and anything over '50' is assumed to be 19XX. The break point (50) can be changed by configuration (it is a moving window, actually). As the old applications are re-engineered, downsized and/or substituted by new ones, the problem is "fixed" simply using a proper Date/Datetime datatype instead of the old DECIMAL FIXED or PIC fields. (Former banking programmer here).
|
|
#
?
Jun 12, 2015 13:35
|
|
|
NihilCredo posted:I think this is the key point here. I have left commented code in a couple of times, but it was something like this: I really hate to see commended code in production. But I agree it can have it's uses in certain situations.Specifically when there might be a technical or compatibility issue with something so we had to deviate from best practices or the most efficient methods. What I don't want is for someone to come back later to refactor something they think could be improved on, only to run into the same issue. You can try to stick a couple of lines of comments in there or put it in the documentation, but since you're communicating with other developers it doesn't hurt to just show them with a block of commended code. So while commended blocks of code is poo poo and we should try to remove them when we can, having a couple here and there for specific situations isn't always a bad thing.
|
|
#
?
Jun 12, 2015 14:10
|
|
|
NihilCredo posted:I think this is the key point here. I have left commented code in a couple of times, but it was something like this: This is basically the same as what openssl does. There are good intentions behind that comment, but inevitably six years later, it no longer has any meaning or relevance, and wouldn't work anymore even in the original circumstances. It may even confuse readers or obscure how things are supposed to work. You should write the comment, but unless there's a way to make sure the code is still compiled / tested regularly, just delete it instead of leaving it to rot.
|
|
#
?
Jun 12, 2015 14:10
|
|
|
Illusive gently caress Man posted:This is basically the same as what openssl does. There are good intentions behind that comment, but inevitably six years later, it no longer has any meaning or relevance, and wouldn't work anymore even in the original circumstances. It may even confuse readers or obscure how things are supposed to work. Disagree, that's documentation not code. It should be with the technical design documents ending with "See commit XXXXX for how the code was when it was removed." Block comments explaining the long long ago don't belong in the current code base.
|
|
#
?
Jun 12, 2015 14:23
|
|
|
Hughlander posted:Disagree, that's documentation not code. It should be with the technical design documents ending with "See commit XXXXX for how the code was when it was removed." Block comments explaining the long long ago don't belong in the current code base. I disagree about sticking it in the documentation, for much the same reason that I wouldn't just leave it to VC history: because I'm assuming that the future developer will not intentionally go looking for it, so it's safest to leave a reference where he will definitely have to look on his way to work. But I think you are entirely right that I should have written "See commit XXXXX" instead of copying the code block outright. That would have ensured the old code would be seen in context (though if a dude were to uncomment it and find out it doesn't compile anymore, I hope that then he would know to go search through the documentation / version control).
|
|
#
?
Jun 12, 2015 14:43
|
|
|
Hughlander posted:Disagree, that's documentation not code. It should be with the technical design documents ending with "See commit XXXXX for how the code was when it was removed." Block comments explaining the long long ago don't belong in the current code base. I can get behind this. I'm just used to documentation being "add it to the wiki", and nobody reads this wiki ever, and it is filled with duplicated information and is pretty fuckin useless overall, so everyone continues to not use it.
|
|
#
?
Jun 12, 2015 14:49
|
|
|
NihilCredo posted:But I think you are entirely right that I should have written "See commit XXXXX" instead of copying the code block outright. That would have ensured the old code would be seen in context (though if a dude were to uncomment it and find out it doesn't compile anymore, I hope that then he would know to go search through the documentation / version control). I think you should go a step further and remove the commented code entirely, but leave a note saying "This was changed from XXX on 06/06/06, see commit YYY for reference". All commented code is gone, but there's a trail for the developer to follow in case they need it. A datestamp lets them know how relevant it is. Bognar fucked around with this message at 15:05 on Jun 12, 2015 |
|
#
?
Jun 12, 2015 15:03
|
|
|
|
| # ? May 26, 2024 23:38 |
|
|
Hughlander posted:Disagree, that's documentation not code. It should be with the technical design documents ending with "See commit XXXXX for how the code was when it was removed." Block comments explaining the long long ago don't belong in the current code base. Agreed, that's the perfect case for a comment saying "this exists in this form because of reasons X, Y, Z." In the .NET world, Visual Studio even shows you commit history hovering right above the class/method definition so you can pull up the previous implementation in a few clicks for comparison.
|
|
#
?
Jun 12, 2015 15:16
|
|
