Messages in this thread | | | Date | Fri, 5 Sep 2003 14:57:46 +0100 | From | John Bradford <> | Subject | Re: nasm over gas? |
| |
> > > > Are there any buffer overflows or other security holes? > > > > How can you be sure about it? > > > > > > How can you be sure? Mathematical program verification applies quite badly > > > to assembler. > > > > The point is, if somebody does find a bug they will want to > > re-assemble with Gas after they've fixed it. > > > > > > If your code fails on any one of these questions, forget about it. If > > > > it survives them, post your results and have someone else verify them. > > > > > > I'm sorry, your critique is too generel to be useful. > > > > It's not, all the time the argument is not against the assembler code, > > but rather against $assembler!=Gas. > > > > John. > > All assemblers suck. However, they are exceeding useful. The > code ends up being exactly what you write. Usually one only > needs to learn one assembler per platform. It was a real shock > for me to have to learn GAS, it was "backwards", seemed to > think everything was a '68000, and basically sucked. However, > once I learned how to use it, it became a useful tool.
Not sure whether you're agreeing with me or not, quite possibly because my last comment used a double negative and was somewhat ambiguous :-).
What I meant was that if a piece of perfect code exists, (and as you point out, this can be mathematically _proven_ with assembler code, not just demonstrated), the requirement for an open source assembler other than Gas is not so much of a problem, because nobody should need to touch that code. If they do, they can translate it to Gas syntax.
If the possibility of bugs exists in the code, relying on $assembler!=Gas is a bad thing, because there will be fewer people willing to maintain it.
> The test of code that works in the 'real' world is called > regression-testing. Basically, you run the stuff. You execute > all "known" possible execution paths. If it works, it works. > If it doesn't, you fix it until it does.
I totally agree.
> You need to test procedures as "black-boxes" with > specified inputs and outputs. You also have to violate the > input specifications and show that an error, so created, doesn't > propagate. Such an error need not crash or kill the system, but > it must be detected so that invalid output doesn't occur. > > Error-checkers like Lint, that use a specific langage such as 'C', > can provide the programmer with a false sense of security. You > end up with 'perfect' code with all the unwanted return-values > cast to "void", but the logic remains wrong and will fail once > the high-bit in an integer is set. So, in some sense, writing > procedures in assembly is "safer". You know what the code will > do before you run it. If you don't, stay away from assembly.
This is part of what makes someone a 'real' programmer, in my opinion.
In my experience, 'Unreal' programmers tend to excessively re-use code from other applications they've written, and just hack it about until it works, at times leaving in code for features that are never used in the new context :-).
John. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |