Performing One's complement on Pointers

Hi, I am writing a safe pointer object by checking that the pointer is not corrupted before I dereferencing it. I am using the one's complement technique (store a one's complement copy and compare it will the pointer). How do I perform a one's complement on a pointer value? Using ~ on a pointer is invalid (compile complains). I can cast it but I don't think there is any standard on the size of a pointer (so I can't just cast it to integer).

Is there anyway to do it properly or any other ideas? Thanks.

you'll definitely want to check into this to be sure, but I think that pointers are guaranteed, by the standard, to be the same size as an unsigned long. with a cast, you can then convert a pointer to an unsigned long, and perform the ones complement upon it.

O_o

No; please, don't do whatever you are doing.

Still, the `size_t' type is your best bet.

Soma

Hi Soma, could you please explain why? Is it dangerous to do that?

I actually found that there is a intptr_t which is used to hold the reinterpret_cast result as an int.

O_o

It isn't dangerous if done with extreme care. So long as you are only storing the resulting value for comparison you'll probably be fine, but I've seen a lot of people use different variations on the theme, and others besides, and wind up trampling memory they didn't own because they wound up using the intermediate result as a pointer.

Consider using, or implementing if you want, a full featured smart pointer.

I'm pretty sure that `intptr_t' is a C99 thing meaning some C++ compilers will not have it. In theory, `size_t' isn't guaranteed to work, but in practice it is the correct "width" and extremely portable.

Soma

Thanks for your help. Could you point me to the right library for a smart pointer that perform such check? Most smart pointer I know are for memory deallocation and checking for uninitialized pointer, but there is not checking for corrupted pointer.
Yes, I am aware that the intptr_t is C99 but I think we can create a similar type using template. Also, I think it is in C++0x as well? Thanks again.

Quote:

---

Hi, I am writing a safe pointer object by checking that the pointer is not corrupted before I dereferencing it.

---

So you've got a program that is so broken that there's a chance of overwriting random memory, and you're trying to mitigate the problem? Wouldn't it be more effective to use a memory sanitizer (such as valgrind, or Clang's experimental address sanitizer) to actually find and fix those random accesses?

Thanks for pointing me to those tools CornedBee, they could be useful tools for me.
But no, it is not because the code is so broken, but it is for a safety critical device and we have to know what would happen when memory corruption DOES happen. And we also have to worry about hardware failure (e.g. RAM not working properly). Proving that things will never go wrong to the auditor is harder than showing them that the device is fail safe.

Quote:

---

Originally Posted by Elkvis

...but I think that pointers are guaranteed, by the standard, to be the same size as an unsigned long...

---

Sincerely doubt it.
long on Windows = 32 bits.
Pointer on x64 Windows = 64 bits.

Just access the pointer on a byte level. Better yet, employ a template function so that the operation can be generalized for use with any POD.

Code:

---

template <typename T>
T bit_complement_of(T t)
{
        typedef unsigned char U;
        typedef U* P;
        U m = ~0;
        P b = P(&t), e = b + sizeof(T);
        while(b != e)
                *b++ ^= m;
        return t;
}

---

AFIAK, that should be 100% portable.

Minus points for obfuscation, though. Use proper variable names and typedef names. Also get rid of the pointer typedef.
Also, conversion from T* to unsigned char* is either a compile error or a warning. You should fix that.

Quote:

---

get rid of the pointer typedef.

---

Why?

Quote:

---

conversion from T* to unsigned char* is either a compile error or a warning.

---

gcc -Wall -pedantic gives not warnings.

Code:

---

template <typename T>
T bit_complement_of(T data) {
    typedef unsigned char* PUC;
    PUC begin = PUC(&data), end = begin + sizeof(T);
    while (begin != end)
        *begin++ ^= ~0;
    return data;
}

---

Quote:

---

Originally Posted by oogabooga

Why?

---

Why do you want to use it in the first place?
It's confusing and saves you only one "*".

Quote:

---

gcc -Wall -pedantic gives not warnings.

---

It is weird that it would not. What types have you tried it with?
Obviously conversion from, say, unsigned int* to unsigned char* (like int n; unsigned char* p = &n) is going to generate warnings or errors. They are totally unrelated types.

Quote:

---

Originally Posted by Elysia

Obviously conversion from, say, unsigned int* to unsigned char* (like int n; unsigned char* p = &n) is going to generate warnings or errors. They are totally unrelated types.

---

There's a cast involved.

Ah, there is, now that you mention it... The code threw me off.

Quote:

---

Originally Posted by Elysia

Minus points for obfuscation, though. Use proper variable names and typedef names. Also get rid of the pointer typedef.
Also, conversion from T* to unsigned char* is either a compile error or a warning. You should fix that.

---

Well, I've been writing software professionally for many years now, and I can assure you that the only true measures of good coding practices are stability, portability, and reuseability. Focusing on such inconsequentials like style conventions and so forth is really just a waste of time, IMO. Developers that yield aesthetically pleasing crap are a dime a dozen; the best ones often produce the most quirkily written code imaginable, but are yet as rare as diamonds and thus worth their weight in gold! Bottom line: substance always trumps style. Full stop.

Quote:

---

Originally Posted by oogabooga

Code:

---

        *begin++ ^= ~0;

---

---

Just bear in mind that the literal ~0 is an int and so the left-hand-side gets widened to an int before the XOR, then narrowed back to unsigned char for the assignment, which may result in undefined behavior (correct me if I'm wrong). Just to be safe, you should always use explicit casts in such situations. In other words:

Code:

---

        *begin++ ^= (unsigned char)~0;

---

O_o

I don't know what mean tricks reality has pulled on you gardhr, but you need to realize now that what you've said in post 16 is moronic.

"Substance", as you call it, it extremely important, but source is written for humans. Clarity is crucial. (Anyone who says differently is an idiot or simply never had to maintain COBOL.) And the important part is, it doesn't cost anything. The changes Elysia suggested aren't going to make the code less stable, portable, or reusable; those changes only make the code more readable and the intent more obvious.

Soma

Quote:

---

the best ones often produce the most quirkily written code imaginable

---

I disagree. "Super-programmers" are an old-fashioned idea that has proven disastrous. Modern practice is to write for humans.

Quote:

---

Just bear in mind that the literal ~0 is an int and so the left-hand-side gets widened to an int before the XOR, then narrowed back to unsigned char for the assignment

---

I don't see why that would be the case. Surely it can all be handled at compile time (a disassembly shows that gcc handles this efficiently).

Quote:

---

Originally Posted by phantomotap

O_o

I don't know what mean tricks reality has pulled on you gardhr, but you need to realize now that what you've said in post 16 is moronic.

"Substance", as you call it, it extremely important, but source is written for humans. Clarity is crucial. (Anyone who says differently is an idiot or simply never had to maintain COBOL.) And the important part is, it doesn't cost anything. The changes Elysia suggested aren't going to make the code less stable, portable, or reusable; those changes only make the code more readable and the intent more obvious.

Soma

---

Sure, but at what expense do you enforce such practices? In this industry, time is invaluable; time consumed cleaning up code would have been much better spent shoring it up, so why even bother? In the company that I work for now, for example, I manage a large number of developers but enforce no style constraints whatsoever, yet we still manage to produce code that requires very little bug maintenance. Our code review team doesn't seem too concerned with having to sift through the unregulated mass of prose either, no doubt due to the fact that the quality of the code produced is so good. Simply put, ignoring trivial details allows you to focus all of your energy on what's truly important. Pleasant sounding platitudes aside, you have to learn to see the forest for the trees in this business (otherwise you might end up such incontrovertible garbage as the android operating system or what have you).

O_o

You spend so much time actually writing new code that the time you would have spent writing clear code instead signifies a real cost!?

That's unfathomable. I admit it; I have no answer for that. The "lines per minute" you produce must be insane if taking a couple extra seconds per line is going to significantly affect that number.

I'm not joking; I'm literally shocked by that claim. I, and every decent programmer I've ever worked with, spend I'd say 60%-80% of new development time reasoning about what to write next. For me, those couple of seconds per line in the cycle of new development is insignificant when compared with the vast amount of time spent reasoning about issues of "substance".

Soma

Quote:

---

In the company that I work for now, for example, I manage a large number of developers but enforce no style constraints whatsoever

---

What company do you work for?

Quote:

---

Originally Posted by phantomotap

O_o

You spend so much time actually writing new code that the time you would have spent writing clear code instead signifies a real cost!?

That's unfathomable. I admit it; I have no answer for that. The "lines per minute" you produce must be insane if taking a couple extra seconds per line is going to significantly affect that number.

I'm not joking; I'm literally shocked by that claim. I, and every decent programmer I've ever worked with, spend I'd say 60%-80% of new development time reasoning about what to write next. For me, those couple of seconds per line in the cycle of new development is insignificant when compared with the vast amount of time spent reasoning about issues of "substance".

Soma

---

Maybe I should have been clearer. I'm not implying that it's acceptable to produce obfuscated code. I'm talking about minor style issues: indentation, spacing, variable naming conventions, etc. What I'm saying is that when you insist upon arbitrary coding conventions, you are essentially depriving your developers from working at their optimum comfort level, even forcing them to spend precious time formatting code in a way that is frankly unnatural to them. That's counterproductive, is it not?

Quote:

---

Originally Posted by oogabooga

What company do you work for?

---

Why, are you looking for work? Seriously though, I can't disclose that sort of information on a message board, although I can tell you the company's been around for a very long time and holds a large market share in software for consumer devices of all sorts. I've been with the company for a little over five years now, the last two years of which I've been a senior developer.

Quote:

---

Originally Posted by gardhr

In the company that I work for now, for example, I manage a large number of developers but enforce no style constraints whatsoever, yet we still manage to produce code that requires very little bug maintenance.

---

I too find that hard to believe. If you're managing a small number of good developers, then it is certainly possible that no style constraints need to be enforced or even spelled out, because it comes naturally from their skill and experience. But the larger the number of developers, the more likely that you'll have rotten apples who write unreadable code and still managed to get hired, and for whom a coding convention is necessary, even if it is not rigidly enforced.

Quote:

---

Originally Posted by laserlight

I too find that hard to believe. If you're managing a small number of good developers, then it is certainly possible that no style constraints need to be enforced or even spelled out, because it comes naturally from their skill and experience. But the larger the number of developers, the more likely that you'll have rotten apples who write unreadable code and still managed to get hired, and for whom a coding convention is necessary, even if it is not rigidly enforced.

---

Again, there's a difference between obfuscated code and code written using one's own preferential style. You may think the line between the two to be rather subjective, but in practice it's really pretty straight-forward: the former is nearly impossible to follow and the latter is merely annoying to read, at worst! Either way, it's not an issue affected by scale so much as it is by the organization of your development process and the nature of your (corporate) culture...

O_o

There is a difference between between obfuscation and unfamiliar style! When a "personal style" imposes no reasonable layout or allows meaningless names it devolves into simple obfuscation. Demanding clear, reasonable, and maintainable source isn't the same thing at all as saying that every '{' characters must be indented 3 spaces from the previous indentation level and variable names must begin with "foo".

You don't need a rigid style guide to require naming variables after what real data they represent or functions after the task implemented. You don't need to manage a million lines and a hundred programmers to understand the benefit of "self documenting code". You don't need to have worked a decade to know that following a reasonable style isn't actually time consuming.

Drawing an imaginary line between "This is obfuscated source." and "This is source written in my personal style." will not get you anywhere if the code is an ambiguous, inconsistent, semantically meaningless, nightmare of spaghetti code.

Soma

Quote:

---

Originally Posted by gardhr

Again, there's a difference between obfuscated code and code written using one's own preferential style. You may think the line between the two to be rather subjective, but in practice it's really pretty straight-forward: the former is nearly impossible to follow and the latter is merely annoying to read, at worst!

---

Aye, and if we go back to the context, "use proper variable names and typedef names" is not the imposition of any personal preferential style. It is simply stylistic common sense that can hardly be disputed in a sensible coding standard. Getting rid of the pointer typedef makes sense: we're not dealing with an opaque pointer or a typedef for an iterator type, so hiding the fact that it is a pointer is just obfuscation.

EDIT:
Basically, I think you're picking the wrong bone here. If this was a "tabs versus spaces" issue, then certainly it is fair to criticise the style critique as inconsequential.