AMD64 and malloc()

I'm having lots of trouble finding info on the web about how memory will be allocated on a 64 bit processor in c++.  So far all I've found is compiler-specific this and compiler-specific that.  Can anyone tell me how to be prepared to manage 64 bit memory in a cross-platform manner?  will malloc crash if I try to malloc more than 0x7fffffff bytes on an AMD64?  Is there going to be a commandline-switch for different compilers?  hope this question is not dumb :)


PS I am presently using VC++ 6.0 command line.
Who is Participating?
guntherothkConnect With a Mentor Commented:
Your chief cross-platform problem will be that a void* is not necessarily the same size as an int or a long on a 64 bit architecture. A lot of programs blithely cast between void* and types like int.

malloc() ought to work on a 64 bit architecture. The argument of malloc() should be of type size_t, which is unsigned long on 32 bit architectures, but will be something like unsigned long long on 64 bit architectures.

Yes, this is compiler-specific. You need a compiler that understands you are coding for a 64 bit architecture. The whole point of architectures like the AMD is that they understand and correctly run old 32 bit applications compiled by compilers which don't understand 64 bit issues. MSVC 7 has a whole suite of warning messages specifically designed to report potential 64 bit incompatibilities in 32 bit code.

There are switches in MSVC 7 to compile for 64 bit architectures, and there will have to be 64 bit specific versions of library functions like malloc(). For most applications, it's still appropriate to compile for a 32 bit model.
Just guessing, but it would probably work out okay if malloc() remained as-is for a while, accepting a 32-bit parameter.  All existing programs and 98% of mallocs() in the next 10 years will still be serviceable by malloc();

 For really big allocs, there could be an malloc64() that would accept and return a 48 or 64-bit pointer and length.

madhtrrAuthor Commented:
k, thanx :)

Man.  I feel like I'm getting pushed to the shore of an island of running out of practical cross-platform development environments.  whenever I get rich and have lots of time, I guess I'll have to spend all of it in assembly, hehe :)
Children these days don't know how hard we had it. You've grown up your whole lives with a family of computers all having 32 bit addresses and data words that were 8, 16, or 32 bits wide. You don't remember the bad old days of 18 bit addresses and 36 bit data words (or worse). Six bit bytes, octal, 1's complement arithmetic with two zeros! Ha. You probably don't even remember long and short (and compact, and...) pointers and memory models.

Seriously, we've been pretty lucky for the last 20 years in the common assumptions we could make about hardware architectures. Innovation in processor design is good, but it will sharpen your coding skills.
madhtrrAuthor Commented:
yep, I just got into this about 10 years ago. started with foxpro and various dbase stuff.  I remembered when I was in high school and I had to write my own program for anything I wanted to do on my 386 when there was no GUI (admittedly, on basica:).  I kinda began to feel like I was getting dumbed down, which is why I began on c++, which actually taught me something about my machine.  I am presently reading a textbook on assembly for intel processors, and learning all kinds of fascinating stuff.  (some of the crazy things you mentioned are discussed in that book, and man, I DO have it easy comapred to all that!) This board and you guys are my prime source of hard to find information and insight that will get me to my ultimate goal which is becoming one with the metal, instead of just memorizing a bunch of proprietary syntax ...  do not dispair, There is hope for us!

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.