Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I know for what we use this argument, and I even know how to work with the argument.
There is only one things I still do not understand. How a program allocate memory for strings which came from the input. **argv has no allocated memory at the start of the program, isn't it? I was expecting segfault, but it didn't happen.
Does anybody know how this memory allocation work?
The C/C++ runtime processes the command line arguments and creates an area of memory where the arguments are put. It then calls your main() providing you a count of the number of arguments along with a pointer to the area where the arguments are stored.
So the C/C++ runtime owns the memory area allocated and it is up to the C/C++ runtime to deallocate the area once your main() returns or if some other C/C++ function is used to stop the program such as exit().
This procedure originated with the use of C under Unix and was kept for C++ as a part of providing the degree of backwards compatibility the C++ committee has tried to maintain.
Normally when your program loads, the entry point that is started by the loader is not your main() function but rather an entry point defined in the C/C++ runtime. The C/C++ runtime does various kinds of initialization to setup the environment that the C/C++ standards say will exist at the point when the main() function is called by the C/C++ runtime once the initialization is completed.
One of the steps during this initialization is the parsing of command line arguments provided which are then provided to the main() function as its function arguments.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
Does declaring a variable after a buffer in a function make its memory area inaccessible by the buffer? Because I tried doing that and every time I compile the program the buffer can still access it. First address of the buffer is always the lowest possible address of the stack frame.
Does it have to do with the compiler? I'm using gcc.
int check_authentication(char *password){
int demovar;
char password_buffer[16];
int auth_flag;
strcpy(password_buffer,password);
if(strcmp(password_buffer,"brilling")==0)auth_flag=1;
if(strcmp(password_buffer,"outgrabe")==0)auth_flag=1;
return auth_flag;
}
First:
The C standard does not tell anything about the location of your variables. The C standard doesn't even say that they are on a (call) stack. So your variables can be anywhere in memory (or they can not even be in memory).
A stack is an implementation specific thing that is never ever mentioned by the standard. Most (if not all) implementations use a stack but still there is no way to tell from the C code how variables will be located on the stack. It's an implementation thing - it's decided by your compiler.
Second:
C has no overflow protection what so ever. If you copy more into password_buffer than it can hold (16 char in this example), C will not warn you. It's called Undefined Behavior. It means that anything may happen. Maybe your program crash. Maybe it overwrites another variable. Maybe ... whatever. But nothing in C will help you. It's your responsebility to make sure such things doesn't happen.
It's kind of how C works. The programmer is responsible for doing things correctly. There is almost no help in C. The benefit is that there is almost no overhead in C. You win some, you lose some...
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
My application has a huge memory leak which eats all my memory instantly, and I can't debug as it freezes the computer ...
Do you guys have any technical solution for that kind of issue?
Edit : I am using Qt Creator with Windows 7 and MSVC compiler.
Cheers
You cannot just freeze a computer with a single instruction. If you allocate a lot of memory, it will either crash the program or use a virtual memory space without actually consuming the real space.
Thus, if you debug it further, maybe in smaller steps, I am sure you will find your solution.
There are many debugging tools that you can try to use, depending on your working environment. Assuming you are working under linux, the simplest one is the command line gdb, allowing you to execute code line-by-line. More advanced, tailored specifically to memory problems is valgrind.
In the comment you are asking if there is a way for the OS to artifically limit the available memory to a program/process. You can try by reading this question:
https://unix.stackexchange.com/questions/44985/limit-memory-usage-for-a-single-linux-process
however, given the little information you provided, I am not convinced it will solve your problem.
If you have got global variables which allocate memory immediately, i.e. before reaching the first line of code in main(), which could be found for instance in class constructors, then you may consider placing your breakpoints not on the first line of main() but rather on the class constructors. Just as a hint based on a previous similar experience ...
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I need to implement default behavior of exit call. I don't know what should I do and what is the most suitable way to do this. I have read that it should close file descriptors and something else.
Should I close default streams (stdout,err and in) ?
How to exit from nested functions calls ? Using goto is bad practice, what is the best way to break out ?
Thanks.
Do all of the things listed in exit(3), then invoke the _exit(2) system call. Alternatively, use longjmp(3) to jump back up to the main() function, then return from it. This invokes the same behavior as calling exit(3), and is just as dependent on the C runtime, so if exit(3) is unavailable for some reason, returning from main() will probably not work correctly either.
Unfortunately, AFAIK there is no portable way to enumerate all of the functions which may have been registered with atexit(3) and on_exit(3), so you'll have to keep track of those manually (i.e. every time you call atexit(3) or on_exit(3), append the function pointer to a list). Flushing stdio(3) is 3 straightforward fflush(3) calls.
You do not need to close any streams or file descriptors; the OS should do that automatically (the OS must not leak streams and fd's, so it is responsible for cleaning them up).
NB: longjmp() is almost always wrong under C++; throw an exception instead. It generally should only be used under straight C.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
Consider this two variable declaration. both of these declarations have data types. What is the actual usage of these data types.
int a;
MyClass b;
Is there a part of each declared memory to hold the data type?
Do these data types for human usage?
Do these data types not required beyond compiler(after compiled the program)?
Any good resource to read about this?
It is used to allocate the needed memory. Also it is used for (strong) type checking.
Also (but that is not the main reason).
Both. The compiler uses them, but afterwards dynamic behavior might be used depending on the object type.
?
The compiler is going to allocate memory on the stack for this variables. You cannot tell how much memory is allocated because this depends on the compiler and the system you are compiling your source code. Variables in c++ are always allocated on the stack unless you use pointer. In that case they are allocated on the heap.
In general yes. You CPU doesn't understand data types, in the end your code is compiled into a binary format (set of CPU instructions) to run on a CPU. You could as well write your program as a set of these instructions instead of c++. Then you would be using Assembler. But even Assembler is kind of a commodity interface to machine code since it has to be compiled an linked as well.
Based on your code the compiler can probably do some optimization of the code (for example copy elision).
I am not sure what you are expecting or trying to learn but i guess you could look for some compiler architecture literature.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 9 years ago.
Improve this question
I've recently hit a segmentation fault on a line equivalent to
some_file << some_number << ": ";
When the stack memory allocated to this application (it's on a pseudo-embedded system) is increased to 512 kB, we don't segmentation fault.
When writing to a file with the operator (<<), how is stack memory usage affected?
The some_file being written to is a std::ofstream. The some_number being written is passed by reference to the method where this sample line of code lives. The software is 32-bit and compiled with g++ on CentOS.
I'm curious how (or if) ofstream uses dynamic allocation, even in higher-level, general terms.
My first thought was to just upvote jalf's comment, but there are some things that are known. Unless the systems implementation of STL or the compiler is really unusual.
Unless it's inlined, and that's up to the compiler, there's a function call which means pushing a bunch of things to the stack. How much the call requires depends on the number of registers, size of registers and so on.
But more stack could be used inside the call to operator<<. All local variables use stack, and other function calls inside of the operator<< use the stack, unless they're inlined. And so on.
It depends on the implementation of whichever class some_file is an instantiation of. Without more details we can't say anything specific.