cctools @855_1: otool -L crashes on short files

[ryandesign (Ryan Carsten Schmidt)]

otool -L crashes on short files:

$ echo > /tmp/foo
$ ls -l /tmp/foo
-rw-r--r--  1 rschmidt  wheel  1 Oct 19 17:24 /tmp/foo
$ otool -L /tmp/foo
Assertion failed: (length >=4 && "Invalid magic number length"), function IdentifyFileType, file Path.cpp, line 43.
Abort trap: 6
$ port provides $(which otool)
/Volumes/Data/macports/mavericks/bin/otool is provided by: cctools
$ port installed cctools
The following ports are currently installed:
  cctools @855_1+llvm33 (active)

/usr/bin/otool doesn't have this problem:

$ /usr/bin/otool -L /tmp/foo
/tmp/foo: is not an object file

[jeremyhu (Jeremy Huddleston Sequoia)]

This was fixed in newer llvm. Are you suggesting that we cherry pick it into llvm 3.3?

[jeremyhu (Jeremy Huddleston Sequoia)]

For my future reference, I filed this as <rdar://problem/12448054> two years ago, and it was fixed at some point before 9/14/13 or llvm trunk r189956, but I don't have a reference to the exact revision or patch.

$ echo > /tmp/foo

$ otool -L /tmp/foo
/tmp/foo: is not an object file

$ which otool
/opt/local/bin/otool

$ port installed cctools
The following ports are currently installed:
  cctools @855_1+llvm35+universal (active)

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

This was fixed in newer llvm.

Thanks, cctools @855_1+llvm34 and cctools @855_1+llvm35 work fine.

Are you suggesting that we cherry pick it into llvm 3.3?

Oh no, I just didn't know the old llvm version was the cause; resolving "wontfix" and requiring users to use newer llvm is fine.

I was sure I had filed this bug before, but couldn't find it.