Supporting future meanings of "pointer"

[garden]

I found this function inside of a project for an undergraduate Operating Systems Labs course (the project consists of writing the lower layers of a simple microkernel):

[I translated comment and function name from the original, which is in Italian.]

/* Return the address of s */
int address(int *s){
         return(s);
}

I hope this is just a (failed) attempt to get rid of the type conversion warning that could be solved with a simple cast, and not a reworking of something like "int address(int s) { return &s; }".

[tgape]

@garden said:

/* Return the address of s */
int address(int *s){
         return(s);
}

I hope this is just a (failed) attempt to get rid of the type conversion warning that could be solved with a simple cast, and not a reworking of something like "int address(int s) { return &s; }".

On the bright side, that code is much more legible and maintainable than if the author actually implemented that which was desired.

(Sample code showing call by reference withheld to protect the misguided.  It sounds like a neat idea, but since the calls to the function look like they're not changing the value, people are going to forget that it changes the value.)

[Rootbeer]

As a former undergraduate programmer myself, I'm pretty sure this is an example of the "I don't really understand pointers, so I'll just add and remove *'s and &'s until I think it works" pattern.

[obediah]

 @Rootbeer said:

As a former undergraduate programmer myself, I'm pretty sure this is an example of the "I don't really understand pointers, so I'll just add and remove *'s and &'s until I think it works" pattern.

 fixed it!

/* Return the address of s */

int address(int &s){

         return(s);
}