On Tue, 2017-06-06 at 13:58 +0200, Borislav Petkov wrote: > On Mon, Jun 05, 2017 at 11:06:58PM -0700, Ricardo Neri wrote: > > I agree that insn-eval reads somewhat funny. I did not want to go with > > insn-dec.c as insn.c, in my opinion, already decodes the instruction > > (i.e., it finds prefixes, opcodes, ModRM, SIB and displacement bytes). > > In insn-eval.c I simply take those decoded parameters and evaluate them > > to obtain the values they contain (e.g., a specific memory location). > > Perhaps, insn-resolve.c could be a better name? Or maybe isnn-operands? > > So actually I'm gravitating towards calling all that instruction > "massaging" code with a single prefix to denote this comes from the insn > decoder/handler/whatever... > > I.e., > > "insn-decoder: x86: invalid register type" > > or > > "inat: x86: invalid register type" > > or something to that effect. > > I mean, If we're going to grow our own - as we do, apparently - maybe it > all should be a separate entity with its proper name.
I see. You were more concerned about the naming of the coding artifacts (e.g., function names, error prints, etc) than the actual filenames. I think I have aligned with the function naming of insn.c in all the functions that are exposed via header by using the inns_ prefix. For static functions I don't use that prefix. Perhaps I can use the __ prefix as insn.c does. Thanks and BR, Ricardo -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
