Thread: Help with complicated and strange magic

I was going through and commenting c++ source code to gain a better understanding of it, when I came across this range checking code. I would like to know what the maximum call to LargeAllocate would be and how or why range checking might be done in this way. Also if you see errors in my comments please let me know.

Thanks in advance

dword declaration:

Code:

typedef unsigned int			dword;

code (it stretches 160 lengthwise so you may want to copy it into you favorite text editor first)

Code:

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
//
//  MEMBER FUNCTION: idHeap::Allocate
//
//  Allocate memory based off of the bytes needed. There is some funky magic here with checking ranges and I am not sure of the speed increase over
//  the loss in readability
//
//  ~~ GLOBAL VARIABLE: c_heapAllocRunningCount
//     Gets incremented to keep the count of heap allocations current.
//
//  ~~ MACRO: USE_LIBC_MALLOC
//     Forces use of standard C allocation functions for debugging and preformance testing.
//
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

void* idHeap::Allocate(const dword bytes){

  //Checks to see if bytes is a zero, if it is then there isn't anything to allocate
  if(!bytes){ //FIX. COULD WE NOT JUST CHECK TO SEE IF IT WAS LESS THAN 1 HERE AND AVOID THE MAGIC LATER? if(bytes < 1){
    return NULL;
  }
  
  //Increment the count of heap allocations
  c_heapAllocRunningCount++;
  
  //Allocate memory via our custom functions or standard C functions
  #if USE_LIBC_MALLOC
    return malloc(bytes);
  #else
  
    //Check if bytes is within the range 0 to 255 (it was checked earlier in the function to be non-zero so the desired range is actually 1 to 255). This is 
    //done by "not-ing" the value 255 (denoted by the ~) which is represented by the compiler as two's compliment -- meaning 255 in binary looks like 01111111.
    //Not-ing it would give the value 10000000 (-256). So if you preform a bitwise "and" on the number 'bytes' then only values within the range 0 to 255
    //would return 0. Also, 255 is the signed one byte integer maximum.
    if(!(bytes & ~255)){
      return SmallAllocate(bytes);
    }
    
    //Same as the previous check except that the desired range is 1 to the maximum value of a signed 2 byte integer.
    if(!(bytes & ~32767)){
      return MediumAllocate(bytes);
    }
    
    //This basically means that the unsigned 4 byte integer 'bytes' is greater than the range 1 to 32,767 (or over 15 bit in length). In turn that means bytes'
    //is in the range 32,768 (short int maximum) to 4,294,967,295 (unsigned int maximum) or 4gb. However, apparently c++ has it so you cant have constant decimal
    //numbers over 2,147,483,647 or 2gb in a function call or variable assignment -- so as of this revision I don't know what the maximum call to this
    //would be (2gb or 4gb).
    return LargeAllocate(bytes);
  #endif
}

Edit: I think I made a mistake in my comments. Is it true that the constants (255 and 32767) are up-converted for comparison to the length of dword, and if so would it be unsigned or signed?

> code (it stretches 160 lengthwise so you may want to copy it into you favorite text editor first)
Or wrap it yourself into the 80 to 100 columns range.
If you make it hard for people to read, it won't get read.

First, the dword value is an unsigned type, so forget all about signed values.

> Not-ing it would give the value 10000000 (-256)
0x000000FF (255)

~ of that gives you
0xFFFFFF00

Any value >= 256 will have at least 1 bit in common with the set bits in the mask, and the expression bytes & ~255 will be true (and !(e) will therefore be false).

Originally Posted by 127.0.0.1

Also, would you be able to shed any light on my question about the call to LargeAllocate?

You can't really believe this???

apparently c++ has it so you cant have constant decimal numbers over 2,147,483,647 or 2gb in a function call or variable assignment -- so as of this revision I don't know what the maximum call to this would be (2gb or 4gb).

Code:

#include <iostream>

using namespace std;

#define MAXUINT 4294967295

void out (unsigned int x) {
	if (x == MAXUINT) cout << x << endl;
}

int main(void) {
	unsigned int n = MAXUINT;
	out(n);

	return 0;
}

Int values are limited by the number of bits, that's all. There is nothing arbitrary about it.

You can't really believe this???

Well, I got warnings with code I wrote to test it and with the code you posted.

Line 8: warning: this decimal constant is unsigned only in ISO C90
Line 12: warning: this decimal constant is unsigned only in ISO C90

And I had read a post I found on a google search big decimal integer constant warning - C / C++. So I was unsure :/

I see why though I was wrong now and I understand fully how the I posted code works. Thanks again to everyone for the help.

Sorry for the undescriptive thread title (I should have put something up about bitmasks or the correct notation for using an unsigned constant -- "ul" / "u")

Originally Posted by 127.0.0.1

Well, I got warnings with code I wrote to test it and with the code you posted.
And I had read a post I found on a google search big decimal integer constant warning - C / C++. So I was unsure :/

Hmmm, well, fair enough. I have not seen this before; the only compiler I use is gcc and it gives no such warning*, I usually only consult the C99 standard, and I haven't read most of it anyway.

However,

1) I didn't check, but generally C++ standards are more akin to C99 than C90. How are you compiling, or what did you compile to get that warning?

2) Regardless, it does not mean that you cannot have decimal values over 2,147,483,647. It means that by C90 standards, anything over than can only be assigned to an unsigned type. Which you are. In theory, perhaps there is some remote possibility that because you didn't use UL, some theoretical compiler could convert this to an int, which would make it wrap around to negative, and then assign that value to -- wait, an unsigned int?? That won't work, it would still end up as the same positive value. And it's not the way numbers are treated anyway. They're bits, just some bits represent something different when treated as signed.

So this could be a sort of very obscure and irrelevant "undefined behavior", hopefully someone will settle that for us, but I very much doubt it. You'd have to write a compiler that intentionally exploited the standard in a negative way to make it meaningful. If this is "undefined behavior", I bet $$ there's tons of code out there that does it anyway, and I would call it a mistake in the standard itself. Which I otherwise have not done...

* so is the person in that thread, but a very old one (3.4.4). Even with "gcc -ansi -pedantic -Wall -Wextra" I don't get it, v. 4.4.5 (ie, on a C90 source, but I don't get it with g++ either).

Actually I get this warning using g++ (C++), however after replacing the cout with printf I do not get these warnings with gcc, when compiling for C99.

Edit: Here are the compile flags I normally use for C++:

-Wshadow
-Winit-self
-Wredundant-decls
-Wcast-align
-Wundef
-Wfloat-equal
-Winline
-Wunreachable-code
-Wmissing-declarations
-Wmissing-include-dirs
-Wswitch-enum
-Wswitch-default
-Weffc++
-Wmain
-pedantic-errors
-pedantic
-std=c++0x
-Wextra
-Wall
-pg
-g

Jim