Inconsistent API naming

[Rot127]

Not all API structs and functions have the cs_ prefix. This leads to issues like these: https://github.com/capstone-engine/capstone/issues/2316 and https://github.com/capstone-engine/capstone/issues/2810

The question is now, should this be addressed before the v6 Beta? Or before v6 Gold?

Or is API stability more important for everyone and we just keep it as is?

Currently the naming was kinda arbitrary. Sometimes only the arch_ prefix, sometimes cs_arch_.

I think though it is important to make a decision once and then stick with it. And with the many improvements and changes v6 brings, it is most suitable time to do it. So the annoyance is kept to one time only.

NOTE: This would only affect v6 and future versions. v5 would stay as is.

• API means here: Everything in include/capstone/. Internally we have more funny stuff going on, but this is out of scope.

[jiegec]

Or is API stability more important for everyone and we just keep it as is?

How about type alias e.g. typedef or define?

[Rot127]

You mean renaming it to cs_... and adding a compatibility header which does:

#define bpf_insn cs_bpf_insn

This is what we did for the ARM64 AArch64 thing already. Seems to work fine.

[aquynh]

Agreed, but we also want to keep backward compatibility. So better to still keep the old names, dont remove them.

Thanks, Quynh

On Fri, 31 Oct 2025, 18:34 Rot127, @.***> wrote:

Rot127 created an issue (capstone-engine/capstone#2811) https://github.com/capstone-engine/capstone/issues/2811 Discussed in #2637 https://github.com/capstone-engine/capstone/discussions/2637

Originally posted by Rot127 February 26, 2025 Ensure cs_ prefix for all API structs, ids and function names?

Not all API structs and functions have the cs_ prefix. This leads to issues like these: #2316 https://github.com/capstone-engine/capstone/issues/2316

The question is now, should this be addressed before the v6 Beta? Or before v6 Gold?

Or is API stability more important for everyone and we just keep it as is?

Currently the naming was kinda arbitrary. Sometimes only the arch_ prefix, sometimes cs_arch_.

I think though it is important to make a decision once and then stick with it. And with the many improvements and changes v6 brings, it is most suitable time to do it. So the annoyance is kept to one time only.

NOTE: This would only affect v6 and future versions. v5 would stay as is.

• API means here: Everything in include/capstone/. Internally we have more funny stuff going on, but this is out of scope.

— Reply to this email directly, view it on GitHub https://github.com/capstone-engine/capstone/issues/2811, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNQNYAGP4ECEHRTNHHMBKL32M3MPAVCNFSM6AAAAACKYKSG5SVHI2DSMVQWIX3LMV43ASLTON2WKOZTGU3TIMZXGA3TSOA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Rot127]

keep the old names, dont remove them.

Yeah, agree. The old names have to stay. Be it via compatibility header or not. But people shouldn't be forced to do sed -i s/bpf/cs_bpf/g on their code.