Merge #929 with some changes to get things compile

[vit9696]

This implements the changes made in #929 along with two small header fixes to get things compile for OS X kernel.

While these two changes are exactly necessary, there are (at least) two more changes for next branch to be used in the kernel:

1. qsort — there is no public KPI for it
2. Vulnerability fix Fix oob in X86_insn_reg_intel #725 (comment), this remains present in next branch.

Could you fix both of these on your own? They clearly are not part of this PR.
There are multiple qsort implementations with permissive licenses: example 1, example 2, example 3.
And the vulnerability issue is properly explained in the comment.

Thanks

[aquynh]

do you actually mean "ifndef" here?

[vit9696]

Why? It should be like it is. Kernel.framework provides stdint.h but does not provide inttypes.h.

[aquynh]

ah i misread it with including stdlib.h

[vit9696]

Also, while merging the changes I discovered the following line: https://github.com/aquynh/capstone/blob/next/arch/X86/X86IntelInstPrinter.c#L732
It sounded worrying, so I started to wonder why is that even here. Soon I discovered pretty much the only place that could make the use of it: https://github.com/aquynh/capstone/blob/next/arch/X86/X86Disassembler.c#L958

Both of these places look like ugly code duplication to my eyes, ud0 string mnemonic exists in a different place, and there is no reason for a strncpy with a hardcoded mnemonic to happen here, this should be done later by instruction printer.

And I also think that the extra if in X86_Intel_printInst is nothing but obscure. Would you like me to remove those in this pull request?

[aquynh]

this code is indeed ugly: i wanted to add UD0 instruction, without syncing with LLVM yet. this is a stop gap solution, and will be removed in the next major update. leave it there for now, unless you find a bug there.

[aquynh]

can you submit a pull req for #725, and another pull req to add qsort for OSX kernel?

[vit9696]

Well, as for qsort, I created a branch for it:
https://github.com/vit9696/capstone/commit/742edec9beeb48804b5b1c2e10f692be1e92e143
You could merge it as is, once this PR is merged.

As for #725, the proposed solution is pretty much valid, I don't see a reason to create another PR by myself.

this code is indeed ugly: i wanted to add UD0 instruction, without syncing with LLVM yet. this is a stop gap solution, and will be removed in the next major update. leave it there for now, unless you find a bug there.

Well, ok, better to remove it completely I guess. As for bugs… I could imagine some appearing in the future, since the assembly bypasses walking through filling cs_detail stuff. But as for now there should be none. Please remove them all, once you get a minute.

[aquynh]

#725 needs a better fix. Will do that soon.

[aquynh]

merged, thanks!