madshi.net

Is there a reason why excludedPIDs not const ?
Can it be changed to PCULONG pExcludePIDs ?

I suppose I could change that. But what would be the big benefit of that change?

Like all constants.
It just makes Code less buggy.
I define list of constant integers in order to prevent accidental code that changes them.

But it wouldn't have any effect on *your* code, would it? I mean you'd still have to allocate memory for the PIDs (or use the stack) and initialize it, so since you have to write to the array to initialize it, it's not really "constant", right? I suppose making the parameter const might have an effect on my code, but likely not on yours, or am I wrong?

Sure.
It just says that your code doesn’t change the content of array.

As well in SendIpcMessage, the parameter PVOID pMessageBuf could be PCVOID to allow putting constant messages.
I hope you don't change the data in this function

Actually in SendIpcMessage it is a little bit annoying.
For instance std::string::data() returns const char* , and I need to write ugly cast

A much better alternative to Const is Microsoft's SAL (Source-Code Annotation Language). Not only can the prefixes be descriptive about other params that are used, you get the basic _in_, _out_ _in_out_ style for knowing whether a parameter is only read, only written or potentially both. Const is not supported by all c/c++ standards, compilers etc. and personally it has its purpose however IFDEFs need to be littered around headers that support tons of compilers, and that's more trouble than it's worth essentially. Also, keep in mind, Const doesn't protect a parameter's pointee (value) state, only reassignment. In other words, you can still change the value of say a referenced pointer anywhere within the function's body without issue. The variable's value isn't free from manipulation whatsoever so it's therefore considered mutable, not immutable based on Const alone. If a value is mutable (capable of being changed) how does a design-time syntactical restriction such as Const do anything more than catch the caller, not the one who actually implemented the functionality? If Madshi were to change an IPC message (data content) he'd likely document this, which is absurd to me considering it's the CALLER's data, not his own, so it would never even remotely make any logical sense to anyone. If he needed to dress your data he'd allocate a new private memory block and work from that without altering the passed-in parameter reference. I believe that CONSTitutes common sense though.

See this URL for SAL - https://msdn.microsoft.com/en-us/library/ms235402.aspx

--Iconic

SAL is not alternative, it is an addition.

Const is not supported by all c/c++ standards, compilers etc.

Are you serious ?
C89 supports 'const' since 1989 and C++ supported const from the beginning.

const was then adopted in C as part of standardization, and appears in C89 (and subsequent versions) along with the other type qualifier, volatile

https://en.wikipedia.org/wiki/Const_(co ... ogramming)

Are you saying an addition can't be an alternative? Doesn't seem like sound logic to me.
I recently worked on a legacy project for a company and it used K&R c, const keyword is not available at all.
Perhaps you can research this more and is like I said not supported in all situations. Const is optional and therefore its use
is optional and subjective.

--Iconic

I say that SAL is not replacement for const and vice versa.
It is better to have both.

const is understood by all compilers since long time ago.
We are talking about compilers consuming MadCHook API , which means mostly compilers for Windows and they all support 'const' keyword.

Read this for better understanding, most of which echoes my earlier points concerning the "const" keyword and a false sense of security (it's merely an oxymoronic word offering no guarantee/contract)

http://jmdavisprog.com/articles/why-const-sucks.html

What constitutes "correctness" when using const? That's a serious question for you. The keyword name alone is an oxymoron because what's "considered" constant can be mutated/changed. Well, whatever helps you sleep at night I guess. You've many outlets to vent to such as Const Correctness topics online, this forum isn't one of them however, especially not when you should possess enough common sense to be able to discern in and out parameters when calling an MCH API. There's nothing in the official documentation that suggests your input buffer would ever be used for output (i.e> SendIpcMessage)

*SMH*

--Iconic

Thank you.
I am working enough time with C++ to know what const does and what it doesn't.
The main issue that const solves here is code smell cast.

string s("ABC");
SendIpcMessage("IPC", const_cast<char*>(s.c_str()), s.size());

Whenever there is const_cast which removes const, there is a question why it is done.
Is it intentional or just function could receive pointer to const and make usage cleaner.