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 »

Athas: Aug 6, 2007; fuck that joker

baquerd posted:

I'm very interested in how the two bolded statements work together.

Idea: run the program a few hundred times and measure the entropy of the list. If the student fails to exploit the full entropy of the underlying RNG, then that's a fail!

(Autograding a programming assignment beyond a simple test suite to help a human grader sounds like a terrible idea.)

# ? Jan 17, 2015 10:10

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 02:27

VikingofRock: Aug 24, 2008

Xenoveritas posted:

Might as well post this here: Moved ~/.local/share/steam. Ran steam. It deleted everything on system owned by user.

Turns out if Steam's launch script can't find the Steam install, it ends up eventually running rm -rf "$STEAMROOT/"*. (I'm not clear on why.)

Problem: if Steam wasn't found, $STEAMROOT is blank, and since the script doesn't check if it actually exists, you end up with it running rm -rf /*. Oops!

So what happens legally in situations like this? Is Valve liable for damages?

# ? Jan 17, 2015 23:20

omeg: Sep 3, 2012

VikingofRock posted:

So what happens legally in situations like this? Is Valve liable for damages?

Every EULA for every software ever has a clause that if it explodes your machine you're not entitled to anything.

# ? Jan 17, 2015 23:26

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

omeg posted:

Every EULA for every software ever has a clause that if it explodes your machine you're not entitled to anything.

Yeah, but will that sort of clause hold any water? Every amusement park in the world has waivers that they aren't liable for injuries even if they are the result of negligence and those don't mean poo poo in a court.

# ? Jan 17, 2015 23:55

Dicky B: Mar 23, 2004

Your honor I installed this software on my Linux gaming PC and it deleted my anime collection

# ? Jan 18, 2015 00:03

pseudorandom name: May 6, 2007

VikingofRock posted:

So what happens legally in situations like this? Is Valve liable for damages?

The root cause is probably ntfs-3g crashing at the wrong moment, so none at all.

# ? Jan 18, 2015 00:05

Athas: Aug 6, 2007; fuck that joker

VikingofRock posted:

So what happens legally in situations like this? Is Valve liable for damages?

Software is unique among engineering disciplines is that the product is sort of expected to be heavily flawed. Of course, it's complicated a bit by the fact that Steam itself is free (as in beer), and Valve probably didn't specifically claim that it would not delete every file it could get its hands on.

# ? Jan 18, 2015 00:28

Storysmith: Dec 31, 2006

pseudorandom name posted:

The root cause is probably ntfs-3g crashing at the wrong moment, so none at all.

What?

The root cause was that a variable in a shell script wasn't checked to make sure it was empty before passing it to `rm -rf "$VARIABLE/*"`, as described in the ticket and quoted in the post you responded to, ntfs has literally nothing to do with it.

# ? Jan 18, 2015 10:18

omeg: Sep 3, 2012

Blotto Skorzany posted:

Yeah, but will that sort of clause hold any water? Every amusement park in the world has waivers that they aren't liable for injuries even if they are the result of negligence and those don't mean poo poo in a court.

No idea. If some software actually killed people I assume EULA wouldn't protect its creators. Where do you draw the line? IANAL.

# ? Jan 18, 2015 11:45

Hiowf: Jun 28, 2013; We don't do .DOC in my cave.

omeg posted:

No idea. If some software actually killed people I assume EULA wouldn't protect its creators. Where do you draw the line? IANAL.

The Toyota thing just got reposted on HN.

http://betterembsw.blogspot.be/2014/09/a-case-study-of-toyota-unintended.html?m=1
http://www.safetyresearch.net/blog/articles/toyota-unintended-acceleration-and-big-bowl-%E2%80%9Cspaghetti%E2%80%9D-code

Quite appropriate for the thread and the discussion :P

# ? Jan 18, 2015 12:20

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Skuto posted:

The Toyota thing just got reposted on HN.

http://betterembsw.blogspot.be/2014/09/a-case-study-of-toyota-unintended.html?m=1
http://www.safetyresearch.net/blog/articles/toyota-unintended-acceleration-and-big-bowl-%E2%80%9Cspaghetti%E2%80%9D-code

Quite appropriate for the thread and the discussion :P

Or, even more terrifying, the Therac-25.

# ? Jan 18, 2015 16:39

pseudorandom name: May 6, 2007

Storysmith posted:

What?

The root cause was that a variable in a shell script wasn't checked to make sure it was empty before passing it to `rm -rf "$VARIABLE/*"`, as described in the ticket and quoted in the post you responded to, ntfs has literally nothing to do with it.

Well, except for the part where keyvin moved his Steam root to an NTFS filesystem.

The script in question that deleted everything is located in $STEAMROOT/steam.sh. Assuming within that script that the directory containing the currently running script exists was reasonable right up until ntfs-3g crashed and that "cd ${0/*}" caused an IO error.

# ? Jan 18, 2015 22:23

ExcessBLarg!: Sep 1, 2001

pseudorandom name posted:

Assuming within that script that the directory containing the currently running script exists was reasonable right up until ntfs-3g crashed and that "cd ${0/*}" caused an IO error.

1. That IO error should've been caught with a "set -e".

2. 'rm -rf "$foo"/*' is usually wrong. It won't remove any dot-files in $foo. It also might not remove all non-dot-files in $foo if the number of files exceeds the limit on wildcard expansion. It's safer to do 'rm -rf "$foo"; mkdir "$foo"', unless you intentionally want to leave dot-files behind and the number of files in the directory is otherwise known to be reasonable.

3. Obtaining the absolute path of the current directory, or the directory a script is in, is a difficult thing to do portably. 'readlink -f "$(dirname "$0")"' works well on systems with GNU readlink, but in particular Macs don't support that I think. The Steam script contains a five line comment to explain the non-obvious approach it uses to obtain the absolute path, so sanity checking the result is absolutely prudent.

It's crazy to blame this problem on NTFS. The subshell to obtain the absolute path could poo poo out for any number of reasons (stalled network mount, lack of permissions if ran as different user, process rlimit, etc.) and the script could've, but didn't, employ multiple techniques to mitigate such an event from becoming a bigger problem.

ExcessBLarg! fucked around with this message at 22:57 on Jan 18, 2015

# ? Jan 18, 2015 22:50

FlapYoJacks: Feb 12, 2009

Toyotas killer firmware is one of the few reasons why I will never ever buy a newer Toyota.

Feeding a goddamn watchdog with a IRQ? What in the gods hell? :psyduck:

# ? Jan 19, 2015 01:45

Storysmith: Dec 31, 2006

ratbert90 posted:

Toyotas killer firmware is one of the few reasons why I will never ever buy a newer Toyota.

Feeding a goddamn watchdog with a IRQ? What in the gods hell?

Because any other automobile manufacturer is guaranteed to be better?

It's a terrifying state of affairs and no one seems to be moving to fix it.

# ? Jan 19, 2015 07:04

Linear Zoetrope: Nov 28, 2011; A hero must cook

This is really just a newbie mistake and not a terrible horror, but it's such a basic memory bug it's kind of cute.

They're given this struct:

code:

typedef struct {
    int cap;
    TYPE *arr;
} DynArr;

Then they have to implement basic dynamic array/slice methods

code:

void _dynArrSetCapacity(DynArr *v, int newCap)
{
    assert(v != 0);
    assert(newCap > 0);
    DynArr *newV = realloc(v, newCap * sizeof(v));
    v = newV;
}

No, buddy, you're accidentally making an array of dynamic arrays and your pointer reassignment doesn't really do anything. :shobon:

# ? Jan 19, 2015 08:45

Hiowf: Jun 28, 2013; We don't do .DOC in my cave.

Jsor posted:

your pointer reassignment doesn't really do anything.

It does do something. In case of OOM you first leak memory and then return a (probably unexpected) nullptr.

# ? Jan 19, 2015 09:17

Linear Zoetrope: Nov 28, 2011; A hero must cook

Skuto posted:

It does do something. In case of OOM you first leak memory and then return a (probably unexpected) nullptr.

The function isn't returning anything, he's just locally overwriting it. He's definitely leaking memory (the old backing array), and he's invalidating his only pointer to the old dynamic array struct. But the reassignment just, at best, overwrites a value local to that function and then returns, which is effectively a no-op.

Linear Zoetrope fucked around with this message at 09:25 on Jan 19, 2015

# ? Jan 19, 2015 09:21

Hiowf: Jun 28, 2013; We don't do .DOC in my cave.

Jsor posted:

The function isn't returning anything,

Oh LOL, missed that.

# ? Jan 19, 2015 09:24

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Jsor posted:

He's definitely leaking memory (the old backing array)

No he's not? realloc frees the old array if it was moved.

# ? Jan 19, 2015 10:02

Hiowf: Jun 28, 2013; We don't do .DOC in my cave.

Suspicious Dish posted:

No he's not? realloc frees the old array if it was moved.

He doesn't get the new pointer out because the function doesn't return it (so leaking the new array), and in case of OOM the above is not true.

# ? Jan 19, 2015 10:04

Linear Zoetrope: Nov 28, 2011; A hero must cook

Suspicious Dish posted:

No he's not? realloc frees the old array if it was moved.

What Skuto said, but also, I meant the backing array of the dynamic array. Remember, this is the struct

code:

typdef struct {
    int cap;
    TYPE *arr;
} DynArr;

So it leaks the backing array at *arr, because the struct holding the pointer to it is now somewhere else (due to realloc). Of course, this being C, it may actually be valid for a while, but there's no guarantees about how long before that memory location becomes overwritten. I guess the outline sort of is:

1. Programmer has a heap-allocated DynArr struct with some capacity and a pointer pointing to a backing array *arr of that size.
2. Programmer calls _dynArrSetCapacity on said DynArr.
3. DynArr is (erroneously) moved somewhere else in heap memory (also allocates a bunch of random DynArrs)
4. Original pointer to said DynArr is now invalid, meaning you also lose any guarantees that the exact value of the arr pointer remains constant (meaning: it may eventually point to random memory and not said backing array).

Of course, it's possible that due to sheer luck the location of the dynamic array struct is in the same place, but it's not reliable.

Linear Zoetrope fucked around with this message at 10:45 on Jan 19, 2015

# ? Jan 19, 2015 10:41

qntm: Jun 17, 2009

ExcessBLarg! posted:

Obtaining the absolute path of the current directory, or the directory a script is in, is a difficult thing to do portably.

pwd isn't universal?

# ? Jan 19, 2015 14:03

ExcessBLarg!: Sep 1, 2001

qntm posted:

pwd isn't universal?

It is, but if the path to the current working directory contains a symlink, then "pwd" and "readlink -f `pwd`" will return different results. Either result may be sufficient depending on the purpose, and in the Steam case they are, but there are applications that do demand "must resolve to absolute path with no symlinks."

# ? Jan 19, 2015 19:07

Xenoveritas: May 9, 2010; Dinosaur Gum

I guess I should fire up a VM and install Steam for Linux so I can see the script, because what I really want to know is why the launcher has a code path where it attempts to delete its own data directory.

# ? Jan 19, 2015 21:15

FlapYoJacks: Feb 12, 2009

qntm posted:

pwd isn't universal?

it is, but symlinks gently caress it up.

EFB.

# ? Jan 19, 2015 21:51

Storysmith: Dec 31, 2006

Xenoveritas posted:

I guess I should fire up a VM and install Steam for Linux so I can see the script, because what I really want to know is why the launcher has a code path where it attempts to delete its own data directory.

I tried to figure that out myself and gave up.

# ? Jan 19, 2015 22:55

evensevenone: May 12, 2001; Glass is a solid.

https://www.airpair.com/python/posts/python-tips-and-traps#great-exceptations

Evolving horror. This was posted on hackernews today. Originally the suggested snippet was:

code:

try:
    # get API data
    data = db.find(id='foo') # may raise exception
except:
    # log the failure and bail out
    log.warn("Could not retrieve FOO")
    return

# manipulate the data
db.add(data)

Multiple people commented that catching all exceptions is usually a bad idea, so he changed it to

code:

except Exception:

Normally, who the gently caress would care except:

quote:

Ryan works on Openstack Heat at Red Hat and has written Python for web, orchestration, and backend applications large and small.

# ? Jan 20, 2015 00:04

pseudorandom name: May 6, 2007

Xenoveritas posted:

I guess I should fire up a VM and install Steam for Linux so I can see the script, because what I really want to know is why the launcher has a code path where it attempts to delete its own data directory.

For "steam --reset" and also when the it decides that the installation is so damaged that it might as well just reinstall. It does preserve the installed game files and user saved data, though.

# ? Jan 20, 2015 04:43

Pollyanna: Mar 5, 2005; Milk's on them.

Ithaqua posted:

That's not how it works. You write a single test. The test fails. You make that test pass. Then you repeat. The functional correctness of your code is spelled out in your tests. As you build up your test suite, the tests give you a safety net you can use to refactor. This doesn't mean you won't miss test cases or introduce bugs, but it does mean that when you identify the bugs, it's trivial to add a new test case to catch it, and you can be confident that fixing that bug hasn't introduced regressions.

It's not a panacea, but it definitely makes sense in some scenarios. The trick is to not be dogmatic about it.

What you're describing is closer to code-first testing -- you write code, write a bunch of tests for that code (by running the code, taking the output, and assuming it's correct), and then you have a test suite full of test cases that validate that your bugs are present and start failing when you fix them. That's bad.

I know this was a while back, but how do you know which tests to write? I kinda feel like writing 10 different variations of "expect "this" to equal "poop"" is not a very good way to approach it. Is there a way to think of this in terms of, for example, testing functionality rather than "everything works ever"?

# ? Jan 20, 2015 07:55

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

Pollyanna posted:

I know this was a while back, but how do you know which tests to write? I kinda feel like writing 10 different variations of "expect "this" to equal "poop"" is not a very good way to approach it. Is there a way to think of this in terms of, for example, testing functionality rather than "everything works ever"?

Think about the sane limits of your function, and think about possible bad input. If you are writing a function that trims whitespace from a string, what possible inputs should cover all of the bases?

- null, ensure that whatever is supposed to happen in my contract happens
- an empty string
- for every type of whitespace that your function specifically handles (e.g. that you don't have a built in handle, so if you manually specify spaces and tabs then those, but if you just have a built in "whitespace" character just space is fine), a string containing just that.
- " x"
- "x "
- " x "
- " x x "

That's probably sufficient. Can you think of any other cases that might have a different behavior to test? If so, ask yourself "does this boil down to a test I already wrote?" For example, " x" (two leading spaces). Is this covered by " x" (one leading space)? Good question! It might be, or it might not, since we didn't cover the case of repeating whitespace. Toss that in!

- " x"

How about " x" (three leading spaces)? Well, we tested 0, 1, and multiple spaces already, do we need it to be 0, 1, 2, multiple? Probably not, skip it.

Volmarias fucked around with this message at 12:48 on Jan 20, 2015

# ? Jan 20, 2015 12:42

TheresaJayne: Jul 1, 2011

Volmarias posted:

Think about the sane limits of your function, and think about possible bad input. If you are writing a function that trims whitespace from a string, what possible inputs should cover all of the bases?

of course another thing is that it is also supposed to help you uphold SOLID processes.
Single responsibility - The class should do one thing and one thing only.
Open close principle - The class should be open for extension closed for modification
Liskov Substitution Principle - The Parent class should be able to be replaced by the child class with no modification
Interface Segregation Principle - many client-specific interfaces are better than one general-purpose interface.
Dependency Injection - One should �Depend upon Abstractions. Do not depend upon concretions"

# ? Jan 20, 2015 13:58

Space Kablooey: May 6, 2009

TheresaJayne posted:

of course another thing is that it is also supposed to help you uphold SOLID processes.

Dependency Injection - One should �Depend upon Abstractions. Do not depend upon concretions"

Can you explain what DI is and what does this actually mean? I'm familiar (in the sense that I used it, but I don't think it clicked for me, yet) with AngularJS's interpretation of DI, if that helps.

# ? Jan 20, 2015 14:21

NovemberMike: Dec 28, 2008

TheresaJayne posted:

of course another thing is that it is also supposed to help you uphold SOLID processes.
Single responsibility - The class should do one thing and one thing only.
Open close principle - The class should be open for extension closed for modification
Liskov Substitution Principle - The Parent class should be able to be replaced by the child class with no modification
Interface Segregation Principle - many client-specific interfaces are better than one general-purpose interface.
Dependency Injection - One should �Depend upon Abstractions. Do not depend upon concretions"

To be fair though, the only one of those that is uncontroversially right is LSP, and at least the O is generally considered a bad idea these days. DI, for example, is useful but you can get a lot of the benefits without using it if the language has metaprogramming capabilities.

# ? Jan 20, 2015 14:52

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

TheresaJayne posted:

of course another thing is that it is also supposed to help you uphold SOLID processes.
Single responsibility - The class should do one thing and one thing only.
Open close principle - The class should be open for extension closed for modification
Liskov Substitution Principle - The Parent class should be able to be replaced by the child class with no modification
Interface Segregation Principle - many client-specific interfaces are better than one general-purpose interface.
Dependency Injection - One should �Depend upon Abstractions. Do not depend upon concretions"

... so what does SNAKE stand for then?

# ? Jan 20, 2015 14:54

Loezi: Dec 18, 2012; Never buy the cheap stuff

HardDisk posted:

Can you explain what DI is and what does this actually mean? I'm familiar (in the sense that I used it, but I don't think it clicked for me, yet) with AngularJS's interpretation of DI, if that helps.

You have a thing (Foo) that is dependent on another thing (Fart). That is, Foo uses Fart to do whatever. Now classically you would write something like this:

Java code:

public class Foo {
  private Fart fart;

  public Foo() {
    this.fart = new Fart();
  }

  public String butt() {
    //...
    return fart.butt();
  }
}

In dependecy injection, you instead write

Java code:

public class Foo {
  private Fart fart;

  public Foo(Fart fart) {
    this.fart = fart;
  }

  public String butt() {
    //...
    return fart.butt();
  }
}

That is you inject (== give) your dependecies (== things you need) to whatever class/method. Also valid would be injecting at the butt() method (public String butt(Fart fart) { ... })but most of the time that just increases complexity and it's just as fine to inject at class level.

Now if Fart is a complex thing (for example it does some HTTP stuff to 3rd party website) you create a fake Fart that always returns a known value for testing and just pass that in the constructor.

Without DI testing just the Foo without being dependent on the Fart is hard. You basically have two options: a) "gently caress it, we'll just pray nobody in <insert 3rd party> pours coffee on their server" or b) Just use <reflection/bytecode modification/your own variety of its-poo poo-but-you-gotta-do-what-you-gotta-do-stuff>.

Loezi fucked around with this message at 16:15 on Jan 20, 2015

# ? Jan 20, 2015 16:12

Athas: Aug 6, 2007; fuck that joker

Python puzzle of the day:

code:

>>> False == False in [False]
True
>>> (False == False) in [False]
False
>>> False == (False in [False])
False

I'm not a Python programmer, so I had to read the compiler source code to figure this one out.

# ? Jan 20, 2015 16:34

nielsm: Jun 1, 2009

Python does that weird relational comparison thing, not sure what to call it, but it translates the first expression to:

Python code:

(False == False) and (False in [False])

# ? Jan 20, 2015 16:41

The_Franz: Aug 8, 2003

Xenoveritas posted:

I guess I should fire up a VM and install Steam for Linux so I can see the script, because what I really want to know is why the launcher has a code path where it attempts to delete its own data directory.

This was fixed in the latest client update so if you want to try it you will need to find an old version.

# ? Jan 20, 2015 16:45

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 02:27

SurgicalOntologist: Jun 17, 2004

nielsm posted:

Python does that weird relational comparison thing, not sure what to call it, but it translates the first expression to:
Python code:
(False == False) and (False in [False])

Is that a generalization of

Python code:

a < b < c

becoming

Python code:

(a < b) and (b < c)

Because it makes a lot more sense for chained relational comparisons than it does for.... anything else.

# ? Jan 20, 2015 17:08

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 »