Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Also "source code"...

This is clearly not source code.



I am baffled by the people who decided to disagree with you here. Calling this source code is incredibly dishonest. It's the equivalent of saying "we've published the source code of photoshop" when you've base64-encoded photoshop.exe.

I would love to see the actual source code of regin. What they've actually published is useless to me.


It's probably just reverse engineers being snobs.

Or journalists being journalists.

Or both.


"This is clearly not source code."

that's assembler


By saying they've released "source code" they're claiming to have somehow got hold of extra information (i.e. done some old-fashioned journalism and got hold of C code or whatever, containing comments and symbols and human information about intent). In fact they've just downloaded a publicly available binary and disassembled it.


I'd argue that it's source code at the lowest possible level...


And I'd argue that it is a disassembly of a binary compiled from source code.

Source code has the word "source" in it. Unless the original human wrote it directly in assembly without comments or macros (from his padded cell at the asylum, naturally), it is obviously not source code.


"Source code" is generally code you can put into a compiler and get out object code. The term "source" refers to the fact that it is used as input. This is why, for example, the GPL specifies that you must release the original source code in the preferred format for editing — so that people wouldn't release source code generated by disassembly or a source-to-source transformer.


I suppose it all depends on how you define "source code". For me, source code implies that it was authored by a human or automatically generated to mimic human authorship. Any automated translation step that does not result in executable "object code" or "machine language" is "intermediate code".

It may be usable in the same way as source code, but since it was produced as the output of a program that had an input closer to the source, it cannot be the source.

I imagine the compilation process like a stream. The source is the origin of the flow. All changes made there propagate downstream. Some streams are short, like those with M4-processed assembly. Others are longer, with MSIL or JVM intermediate code. Linked libraries are like tributaries; they have their own sources. The end product is a single river, which fans out into a delta for each supported processor architecture as it nears the sea of end users.


I know you are wrong. logfromblammo explains it well.

But let's hear your arguments, I'm curious.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: