I would like a hint on how to complete this puzzle. I need to be able to print what is normally printed out in reverse. Normally this prints, hello there. I need it to print there hello. I am only allowed to add code where it is commented.
Here are some of my thoughts that don't work.
I thought about using the heap to store some data but I can't because stdlib.h is not included.
Can't use goto because I can't add labels and what I would goto is all in one line
Can't use recursion because there are no input parameters and no global variables to modify.
Can't possibly think of a way assembly could help but hey maybe?
I can't do anything obvious like just calling printf's and quitting the program early.
Thoughts on something to do with function pointers? I still don't see how they would help.
#include <stdio.h>
void f1(); void f2(); void f3();
int main() { f1(); printf("\n"); return 0; }
void f1() { f2(); printf(" there "); }
void f2() { f3(); printf(" hello "); }
void f3(){
int x;
//Can add whatever under here
}
I think the only purpose of int x; is to get the stack pointer without using inline assembly.
The solution on how to do this exactly will depend on your platform, the compiler you use and the optimization levels you have used.
I would say first you need to analyze the call stack.
You can do this -
int i;
for (i = 0; i< 10; i++) {
printf ("%p\n", *(void**)((char*) &x - i * 8)); // I am assumming 64 bit machines. If 32 bit replace 8 with 4
}
This will give you the top 10 8 byte values on the stack. Now you need to find the two that look like return addresses. One way to recognize them would be to print the function pointer value of f1 and f2 and see the values close to them.
You now know the indexes where they are stored. Just go ahead and swap them.
For swapping them, say the indices are 12 and 14.
Then you can do this -
*(void**)&x = *((void**)&x + 12);
*((void**)&x + 12) = *((void**)&x + 14);
*((void**)&x + 14) = *(void**)&x;
Also make sure you don't change the stack layout once you get the indices. This means don't remove/add any variables. Don't apply the & operator to any new variables (or remove from any) and don't remove any function calls.
Also another suggestion - Instead of using int x, you could declare another unsigned long long y and use that for the swap instead. Because it would have enough bytes to hold a pointer (on 64 bit machines). Usually there will be padding in case of int x too which should save you from the problem but rather be safe.
Here's an alternate solution that doesn't depend on stack manipulation. The fundamental 'trick' is that the program provides its own implementation of printf() instead of using the standard library's.
Tested on gcc (Mingw, Linux x86 and Linux x64) and MSVC:
#include <stdio.h>
void f1(); void f2(); void f3();
int main() { f1(); printf("\n"); return 0; }
void f1() { f2(); printf(" there "); }
void f2() { f3(); printf(" hello "); }
void f3(){
int x;
//Can add whatever under here
return;
}
void putstr( char const* s)
{
for (;*s;++s) {
putchar(*s);
}
}
int printf(char const* fmt, ...)
{
static char const* pushed_fmt = 0;
if (*fmt == '\n') {
putstr(fmt);
return 0;
}
if (pushed_fmt == 0) {
pushed_fmt = fmt;
return 0;
}
putstr(fmt);
putstr(pushed_fmt);
return 0;
}
I think the idea is that from f3() you have the return addresses on the stack all the way up, and nothing has been printed so far.
You'd have to play with the stack contents so that f3() returns into f1(), which would then return into f2().
Can you take it from here? Depending on the compiler, there will be different ways to accomplish this. Inline assembly might or might not be required.
EDIT: specifically for GCC, see the GCC return address intrinsics.
This should be a portable solution that doesn't mess with the stack and return addresses. Most probably not what was expected by who wrote that challenge, but it's way more fun to think out of the box.
void f3(){
int x;
//Can add whatever under here
static count = 0;
static char buf[256];
if(count==0) {
setvbuf(stdout, buf, _IOFBF, sizeof(buf));
int atexit (void (*func)(void));
atexit(f3);
count = 1;
} else {
const char *src = " there hello \n";
char *dest = buf;
for(; *src;) *dest++ = *src++;
}
}
http://ideone.com/S4zMHP
This works by first using setvbuf to replace the stdout buffer with one that we provide, and switching it to full buffering (instead of line buffering) to make sure that no flush happens before the end of the program (notice that no output has been written yet, so calling setvbuf is legal). We also call atexit to make sure we get called before the end of the program (we don't have stdlib.h, but who needs headers when the required prototypes are already known).
When we are called again (thanks to atexit), the two printf have been called, but the buffer hasn't been flushed yet. We outright replace its content with the string of our interest (which is just as big as what has been written), and return. The subsequent implicit fclose will dump out the modified content of our buffer instead of what was written by the printf.
Related
I have a function like this
void abc()
{
printf("hello\n");
}
lets suppose I checked and know that the address of above function say 0x08000040 now if I assign it to function pointer in main like this
int main()
{
void (*p)()=(void *)0x08000040;
p();// and call it like
return 0;
}
will it call some how. I tried it does not work but suppose I have function in the same program then will it work after I some how found out the address of the function?
and also is this possible
to assign specific fixed address to some function in current C program
is it possible to export a function address (of abc()) in current program and so other programs can call the function in this program to call above abc() function with address hex values. it happens in kernel with exporting of sys-calls and gdb also does this with trap-handlers. So is there any easy way to make it work.
This works for me:
#include <stdio.h>
#include <stdlib.h>
void abc(void) {
puts("abc");
}
void cba(void) {
puts("cba");
}
int main(void) {
printf("type %p or %p\n", (void*)abc, (void*)cba);
char buf[100];
fgets(buf, sizeof buf, stdin);
long unsigned u = strtoul(buf + 2, NULL, 16); // ignore 0x
void (*p)(void) = (void(*)(void))u; // UB!
p(); // and call it
return 0;
}
The virtual address where a given function is located in memory is entirely implementation defined and further depends on many factors:
it is almost always different for different programs ;
it may change if you modify the program source code and recompile it ;
it may even change each time you execute the same program: modern systems perform address space randomisation in order to reduce vulnerability to certain classes of attacks. The same applies to the stack address.
Do not rely on the address values you observe in the debugger, they are likely to be different the next time you debug the program.
I'd like to "override" malloc in pure C with Linux GCC, for memory checking stuffs. Notice that malloc() is a weak symbol, it's OK to do that in pure C. i.e. Making a strong symbol of malloc().
But I just found it crash if calling printf() inside my malloc() implementation, and if removing, it won't crash.
To reproduce:
#include <stdio.h>
extern void *__libc_malloc(size_t size);
static int cnt = 0;
void* malloc(size_t size) {
printf("--- calling customized malloc\n");
cnt += 1;
if(cnt > 1) return NULL;
return __libc_malloc(size);
}
static void leak_test1() {
int* a = malloc(sizeof(int)*5);
a[0] = 3;
}
int main(){
leak_test1();
printf("cnt=%d\n", cnt);
return 0;
}
Does it mean "calling printf is invalid in my own malloc()"? What's the deep reason? (Correct me if I'm wrong)
It is possible that printf call malloc to allocate the buffer for stdout, so you get an infinite recursion.
You might be able to get around this issue by calling fprintf(stderr, ...) as stderr is unbuffered.
I was wondering if there is a function in C (let's dub it int get_stack_depth()), which returns the amount of functions currently being executed on the stack. For example:
int foo(){
return get_stack_depth();
}
int bar2(){
return get_stack_depth();
}
int bar1(){
return bar2();
}
int bar(){
return bar1();
}
int main(){
get_stack_depth(); // = 0
foo(); // = 1
bar(); // = 3
return 0;
}
I would like to use it for debugging info, where each printf would contain get_stack_depth() indents to increase readability. If this is compiler dependent, or anything-else dependent, I take all the constraints; right now I wonder whether this is supported at least somewhere.
EDIT: The answer at the suggested duplicate didn't help me at all, as the accepted answer here suggests, you cannot determine how many functions are on the stack based purely upon the size of the stack; the information is simply not there.
The exact mechanics of the stack in C are implementation-specific, so there is no single, correct, standard way to find the depth of the stack. There are some methods to simulate this behavior, though.
Use a counter. Define a global unsigned depth, and in each function in which you care about the depth of the stack, inject depth++ at the beginning and depth-- at the end. This is obviously the more tedious method, and it's prone to a lot of frustrating issues if an increment or decrement is left off.
Check the stack pointer. On x86 systems (virtually every desktop & laptop device), the stack grows downward, meaning that entering a function call will decrease the value of the stack pointer. In many cases (but not all, e.g. when optimization is enabled) the stack pointer register, %rsp, points to the "top" of the current function's stack frame. A rather hacky way to fetch this value is to assign it to a variable: register uint64_t rsp asm ("rsp");. The lower the value, the greater the depth on the stack.
Unfortunately, the size of the decrement between function calls depends on how large the stack frame for that function is—if one function declares a large array as a local variable, then the stack pointer will be much lower for functions it calls, since more space is consumed by the array.
Ultimately the only reliable way I know of to find an accurate backtrace of function calls is to run the program in a debugger such as gdb and issue the backtrace command, which will print the current call stack. This kind of support just doesn't seem to be available to the program when it is run independent of any debugger.
Have you tried using backtrace()?
for example:
#include <execinfo.h>
unsighed int getDepth(){
const unsigned int max_depth = 200;
void* buffer[max_depth];
return backtrace(buffer, max_depth)-5;
}
The -5 is there because there are some functions above main (added by the libc) that I want to ignore. However, if you want to calculate that automatically, change my function to
int get_stack_depth(int set_caller_as_root){
static int root_depth = 0;
if (set_caller_as_root){
root_depth = get_stack_depth(0) - 1;
}
const int max_depth = 200;
void* buffer[max_depth];
return backtrace(buffer, max_depth) - root_depth;
}
and update your code to
int foo(){
return get_stack_depth(0);
}
int bar2(){
return get_stack_depth(0);
}
int bar1(){
return bar2();
}
int bar(){
return bar1();
}
int main(){
printf("%d\n", get_stack_depth(1)); // = 0
printf("%d\n", foo()); // = 1
printf("%d\n", bar()); // = 3
return 0;
}
which yields the correct, expected results.
Note that execinfo.h is not installed on windows 10 by default (it is on linux).
I would like to do something like that :
#include <stdio.h>
char * myfunction(char * in);
void myfunction2(char * in, const char ** content);
int main(){
char * name="aName";
char * result = myfunction(name);
return 0;
}
char * myfunction(char * in) {
const char *test = NULL;
myfunction2(in, &test);
return test; // I would like to return the value of test
}
void myfunction2(char * in, const char ** content) {
char input[1024];
//do some stuff to fill input
*content = input;
}
But I'm not able to do it, some weird char are printed instead sometimes...
Thank you for your reply, I understand it well now, but I'm stuck on another side of my problem. I didn't write precisely my use case, so I edited it to be complete.
The most glaring things wrong in this code are:
Implicit declaration of myfunction as int myfunction();
Incorrect const-ness of your pointers.
No return value provided for main()
Implicit declaration of myfunction as int myfunction();
This is easy enough to solve, and your compiler should be barking loudly at you when this happens. As a legacy feature of C, when a function call is encountered where no formal declaration, either by prototype or definition, is known, the function is assumed to return int and accept a variable number of parameters. Therefore in main() your call is assumed to be to a function that looks like this:
int myfunction();
Later when the real myfunction is encountered, at a minimum your compiler should scream at you with warning about how the declaration doesn't match the expected type (because by this time it thinks it is int myfunction()). Even then, however, the call should still go through, but it is terrible practice to rely on this. Properly prototype your functions before use.
Incorrect data types for all your pointers.
The string literal in your function is not bound to local array space. It is a read-only data buffer sitting in a read-only segment somewhere in your program's data blocks. The correct declaration is this:
const char *test = "mytest";
but that has the ripple effect of requiring changes to the rest of this code, which you'll see in a moment.
No return value provided for main()
Be definitive in your conclusion of main(). Apparently C99 allows you to skip this and implementation is supposed to return 0 for you. Don't give them that joy; seize it yourself.
Addressing all of the above...
#include <stdio.h>
void myfunction(const char** in);
int main()
{
const char *result = NULL;
myfunction(&result);
printf("in main() %p : %s\n", result, result);
return 0;
}
void myfunction(const char** in)
{
const char* test = "mytest";
printf("in myfunction() %p : %s\n", test, test);
*in = test;
}
Output (varies by implementation)
in main() 0x8048580 : mytest
in myfunction() 0x8048580 : mytest
See it live.
It looks good to me. May I suggest giving it a prototype or moving your myfunc() definition before main(). Also assigning a value to result when it is declared. That will give you a better idea of what is going on if the function is not doing what you expect.
For some reason, the other answers just pointed out technical detail that's wrong, but failed to notice what is really wrong: You are returning the address of an array on the stack. But when the function returns, accessing that array becomes undefined behavior. Other code may freely overwrite the memory, leaving the worst possible garbage in it, or, conversely, writing to the memory behind the returned pointer may trash any vitally important variable of some other, entirely unconnected parts of the code.
If you want to return a pointer, you must either return a pointer to a static object, or you must return a pointer to something on the heap. Here is the static case:
char* foo() {
static char staticArray[1024];
return staticArray;
}
Using static here guarantees that the memory reserved for staticArray[] will remain reserved for it throughout the execution of your program. There are, however, three downsides of this:
the array size is fixed at compile time
this is generally not multithreading safe since all threads will use the same globally allocated memory
you generally cannot expect the data behind the returned pointer to remain intact across a function call. Consider this code:
void bar() {
char* temp = foo();
temp[0] = 7;
}
void baz() {
char* temp = foo();
temp[0] = 3;
bar();
//now temp[0] is 7 !
}
This might be desirable in some rare cases, however, in most it's not.
So, if you want to be able to freely use the memory behind the returned pointer, you have to malloc() memory for it (and free() it afterwards, of course). Like this:
char* foo(int size) {
return malloc(size);
}
void baz() {
char* sevenBytes = foo(7);
//Do something with seven bytes
free(sevenBytes);
}
void bar() {
char* threeBytes = foo(3);
threeBytes[0] = 3;
baz();
assert(threeBytes[0] == 3); //baz() worked on it's own memory
free(threeBytes);
}
In the case of string handling, there is a number of handy functions available in the POSIX-2008 standard that do the memory allocation for you, among them strdup() and asprintf(). Here are some usage examples:
int main() {
char* hello = strdup("Hello");
char* greeting;
if(0 > asprintf(&greeting, "%s World!\nMemory for hello was allocated at %llx", hello, (long long)hello)) {
//error handling
}
printf(greeting);
free(hello);
free(greeting);
}
This will print something like:
Hello World!
Memory for hello was allocated at c726de80
I have argument with my friend. He says that I can return a pointer to local data from a function. This is not what I have learned but I can't find a counterargument for him to prove my knowledge.
Here is illustrated case:
char *name() {
char n[10] = "bodacydo!";
return n;
}
And it's used as:
int main() {
char *n = name();
printf("%s\n", n);
}
He says this is perfectly OK because after a program calls name, it returns a pointer to n, and right after that it just prints it. Nothing else happens in the program meanwhile, because it's single threaded and execution is serial.
I can't find a counter-argument. I would never write code like that, but he's stubborn and says this is completely ok. If I was his boss, I would fire him for being a stubborn idiot, but I can't find a counter argument.
Another example:
int *number() {
int n = 5;
return &n;
}
int main() {
int *a = number();
int b = 9;
int c = *a * b;
printf("%d\n", c);
}
I will send him this link after I get some good answers, so he at least learns something.
Your friend is wrong.
name is returning a pointer to the call stack. Once you invoke printf, there's no telling how that stack will be overwritten before the data at the pointer is accessed. It may work on his compiler and machine, but it won't work on all of them.
Your friend claims that after name returns, "nothing happens except printing it". printf is itself another function call, with who knows how much complexity inside it. A great deal is happening before the data is printed.
Also, code is never finished, it will be amended and added to. Code the "does nothing" now will do something once it's changed, and your closely-reasoned trick will fall apart.
Returning a pointer to local data is a recipe for disaster.
you will get a problem, when you call another function between name() and printf(), which itself uses the stack
char *fun(char *what) {
char res[10];
strncpy(res, what, 9);
return res;
}
main() {
char *r1 = fun("bla");
char *r2 = fun("blubber");
printf("'%s' is bla and '%s' is blubber", r1, r2);
}
As soon as the scope of the function ends i.e after the closing brace } of function, memory allocated(on stack) for all the local variables will be left. So, returning pointer to some memory which is no longer valid invokes undefined behavior.
Also you can say that local variable lifetime is ended when the function finished execution.
Also more details you can read HERE.
My counter-arguments would be:
it's never OK to write code with undefined behavior,
how long before somebody else uses that function in different context,
the language provides facilities to do the same thing legally (and possibly more efficiently)
It's undefined behavior and the value could easily be destroyed before it is actually printed. printf(), which is just a normal function, could use some local variables or call other functions before the string is actually printed. Since these actions use the stack they could easily corrupt the value.
If the code happens to print the correct value depends on the implementation of printf() and how function calls work on the compiler/platform you are using (which parameters/addresses/variables are put where on the stack,...). Even if the code happens to "work" on your machine with certain compiler settings it's far from sure that it will work anywhere else or under slightly different border conditions.
You are correct - n lives on the stack and so could go away as soon as the function returns.
Your friend's code might work only because the memory location that n is pointing to has not been corrupted (yet!).
As the others have already pointed out it is not illegal to do this, but a bad idea because the returned data resides on the non-used part of the stack and may get overridden at any time by other function calls.
Here is a counter-example that crashes on my system if compiled with optimizations turned on:
char * name ()
{
char n[] = "Hello World";
return n;
}
void test (char * arg)
{
// msg and arg will reside roughly at the same memory location.
// so changing msg will change arg as well:
char msg[100];
// this will override whatever arg points to.
strcpy (msg, "Logging: ");
// here we access the overridden data. A bad idea!
strcat (msg, arg);
strcat (msg, "\n");
printf (msg);
}
int main ()
{
char * n = name();
test (n);
return 0;
}
gcc : main.c: In function ‘name’:
main.c:4: warning: function returns address of local variable
Wherever it could been done like that (but it's not sexy code :p) :
char *name()
{
static char n[10] = "bodacydo!";
return n;
}
int main()
{
char *n = name();
printf("%s\n", n);
}
Warning it's not thread safe.
You're right, your friend is wrong. Here's a simple counterexample:
char *n = name();
printf("(%d): %s\n", 1, n);
Returning pointer to local variable is aways wrong, even if it appears to work in some rare situation.
A local (automatic) variable can be allocated either from stack or from registers.
If it is allocated from stack, it will be overwritten as soon as next function call (such as printf) is executed or if an interrupt occurs.
If the variable is allocated from a register, it is not even possible to have a pointer pointing to it.
Even if the application is "single threaded", the interrupts may use the stack. In order to be relatively safe, you should disable the interrupts. But it is not possible to disable the NMI (Non Maskable Interrupt), so you can never be safe.
While it is true that you cannot return pointers to local stack variables declared inside a function, you can however allocate memory inside a function using malloc and then return a pointer to that block. Maybe this is what your friend meant?
#include<stdio.h>
#include<string.h>
#include<stdlib.h>
char* getstr(){
char* ret=malloc(sizeof(char)*15);
strcpy(ret,"Hello World");
return ret;
}
int main(){
char* answer=getstr();
printf("%s\n", answer);
free(answer);
return 0;
}
The way I see it you have three main options because this one is dangerous and utilizes undefined behavior:
replace: char n[10] = "bodacydo!"
with: static char n[10] = "bodacydo!"
This will give undesirable results if you use the same function more than once in row while trying to maintain the values contained therein.
replace:
char n[10] = "bodacydo!"
with:
char *n = new char[10];
*n = "bodacydo!"
With will fix the aforementioned problem, but you will then need to delete the heap memory or start incurring memory leaks.
Or finally:
replace: char n[10] = "bodacydo!";
with: shared_ptr<char> n(new char[10]) = "bodacydo!";
Which relieves you from having to delete the heap memory, but you will then have change the return type and the char *n in main to a shared_prt as well in order to hand off the management of the pointer. If you don't hand it off, the scope of the shared_ptr will end and the value stored in the pointer gets set to NULL.
If we take the code segment u gave....
char *name() {
char n[10] = "bodacydo!";
return n;
}
int main() {
char *n = name();
printf("%s\n", n);
}
Its okay to use that local var in printf() in main 'coz here we are using a string literal which again isn't something local to name().
But now lets look at a slightly different code
class SomeClass {
int *i;
public:
SomeClass() {
i = new int();
*i = 23;
}
~SomeClass() {
delete i;
i = NULL;
}
void print() {
printf("%d", *i);
}
};
SomeClass *name() {
SomeClass s;
return &s;
}
int main() {
SomeClass *n = name();
n->print();
}
In this case when the name() function returns SomeClass destructor would be called and the member var i would have be deallocated and set to NULL.
So when we call print() in main even though since the mem pointed by n isn't overwritten (i am assuming that) the print call will crash when it tried to de-reference a NULL pointer.
So in a way ur code segment will most likely not fail but will most likely fail if the objects deconstructor is doing some resource deinitialization and we are using it afterwards.
Hope it helps