What does void do?

w00t · 08-18-2002, 09:09 AM

I haven't seen what void does, or found any information on it. I now it is similar to int, but if someone could tell me why I should use void and what it does, that'd be greaaat....

redhead · 08-18-2002, 11:50 AM

Void is void.. It's nothing, a void type function, is telling the compiler not to expect the function to return with anything.
Newer compilers are made, to change a void type function, to be of type int, and then add a return 0; at the end.

But from a compiler point of view void is nothing, or can be anything.

sdeming · 08-18-2002, 12:21 PM

The quick and dirty... Void tells the compiler that it shouldn't make any assumptions. There is a real long explination of it's purpose in the ANSI document, but it's hard to follow, so bare with me while I try and put it into realistic terms by use of example:

Code:

int intFun() { return 4; }

The compiler knows that this function returns an int, most likely 32 bits of data. This can be turned into the following assembly:

Code:

intFun:
mov eax, 0x00000004
push eax
ret

Now with void:

Code:

void voidFun() { // blah }

Evaluates to:

Code:

voidFun:
nop
ret

Now void pointers are another story altogether, and this is where compiler writers have to be careful, at least with ANSI C. C++ is another story and void *'s really aren't even useful any longer. So, let's see this in C:

Code:

char *cp;
int *ip;
void *vp;
int ival;

ival = 4;
ip = &ival;
cp = ip; /* this should be a compiler error, but is generally just a warning. */
cp = (char*)ip; /* okay, but bad style.  No warning, the compiler presumes that since you casted it you know what you're doing. */
vp = ip; /* perfectly okay. */
vp = cp; /* perfectly okay. */
cp = vp; /* also okay. */
ip = vp; /* again, okay. */

So basically, the compiler is instructed to morph void pointers to whatever they are representing. In almost every case the void pointers, char pointers, and int pointers are exactly the same size (based on the architecture, 32 bits for Intel and generally 64 bit for modern Sparc). The authors of the standard however did take into consideration that some older platforms (I think VMS??) did not operate in the same way and actually had pointers of different size. The compiler HAD to be aware of this and HAD to function with it.

All that said, compiler writers have generally disregarded these rules.

In C++ you have meta programming so void* is worthless. Templates make life grand!

w00t · 08-18-2002, 10:12 PM

So basically, it's worthless?

sde · 08-18-2002, 10:41 PM

no, it's not worthelss.. just use void when you have functions that aren't going to return anything.

for example, a setName() function just takes a variable to set the name of an object, but doesn't really need to return anything.

w00t · 08-18-2002, 10:53 PM

So void is alloting a slot for a variable to be passed in later?

abc123 · 08-18-2002, 11:17 PM

well i dont know what redhead is talking about eliminating the void altogether but basically, as everyone has said, void is for functions that don't return anything

Code:

void setup()
{
  //load things
  name = "bob";
  age = 10;
}

that doesn't need to return anything, so its void, but...

Code:

int getAge()
{
   return age;
}

that implies that something will be returned, hence it is.

void = "i wont return anything";

sdeming · 08-19-2002, 05:42 AM

void * is used all over the place.

Look at memcpy(), memset(), and many of the other string.h functions. Also look at libdl and the dlsym() functions that rely on void *'s.

When used to define the return value of a function, "void" simply means what everyone has said: "I will not be returning anything." The use of void as a return value is only one small part of why it exists though.

kenshi · 08-20-2002, 05:59 AM

Getting down to the assembler level, ANSI declares that functions will return their values through the eax, ax, or al register, depending on the size of the data. But obviously some functions don't return data. The keywords before the function name tell it how much it will be returning. Void means it's not returning anything, and the contents of eax will be unpredictable. (Though someone earlier said some compilers make void functions return 0, hence eax would contain 0.)

sdeming · 08-20-2002, 08:32 AM

I'm not sure how the ANSI C standard relates to the compiler forcing a function to return a value, even if declared as void but I am failry certain that in C++ this would break the rules. Due to the name mangling that takes place, falsly returning an int may cause some confusion when linking to third party libraries. This may not be the case on return values however since I'm not positive these are part of the functions signature.

Regarding the registers used, it's all dependent on the compiler. If you are compiling using 32-bit alignment, then you will always see eax used, and in many cases it will be used simply for optimization.

The CPU cycles to do the following:

Code:

mov al, 0x04
push al
ret

Are exactly the same as:

Code:

mov eax, 0x00000004
push eax
ret

Naturally, this is only true for x86 architectures. PowerPC, Sparc, and other various systems use a totally different scheme during code generation as they don't even have an eax, ax, or al[ah] register.

kenshi · 08-22-2002, 04:23 AM

Just one point, a function would never use a push instruction before returning. Not only is that against ANSI/C standards, but it would be chaotic at the assembler level. When a function is called (using the call instruction), the processor (behind the scenes) pushes the contents of the IP register to the stack so it'll know where to return to later. When it returns, it goes to the last address on the stack. When you push eax just before returning, it'll try to go to the address pointed to in eax, written in Intel syntax as [eax]. In protected mode, since it most likely points outside the program's code range, you'll probably get a segfault. Even if it's within the code range, it probably won't land exactly at the beginning of an instruction (since most instructions are more than 1 byte) and will likely get an illegal instruction error. If you happen to be running in real-mode, then God have mercy on your computer. In case you want proof, write a simple assembler function that puts 0 in eax, pushes it, and returns and call that function from another C/C++ function. It'll segfault every time it gets to that point.

sdeming · 08-22-2002, 07:26 AM

I think you are right about pushing on return. I get my code generation guides confused at times. Generally you push the function parameters before calling a function and just set the return value in eax, no point in needlessly clogging the stack.