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 2 years ago.
Improve this question
I had an interesting question. I have:
char buf[100]
And I decided to try using close(buf)
Code compiled, the program works. But is there any point in using close() like this?
Thank you.
Assuming "close" is the function from posix, most likely nothing will happen but it's also possible stuff could break badly.
Arrays in c and c++ decay to pointers, close takes an int. Implicitly converting a pointer to an int is not allowed by the c++ spec but some compilers allow it anyway (doing some testing it looks like modern g++ only allows it if -fpermissive is specified).
Most likely the integer that results from said conversion will be large, file descripters are usually small, so most likely close will just return a bad file descriptor error and do nothing but if it does happen to match a file descriptor then things could get interesing.....
It should not compile. The compiler should emit warnings.
The behaviour is undefined
No, there is no point in using close on a char array
There is also no meaning in doing that. What would you want to achieve?
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 is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
The community is reviewing whether to reopen this question as of 1 year ago.
Improve this question
I am slowly writing an emulator for a gameboy using C++, I am currently working on the CPU side of things. I have written a generic function that takes any two registers of the CPU and returns as a Word data type. As it is necessary to access individual registers and also a combination of registers.
const Word get_word(Byte *registerOne, Byte *registerTwo)
{
return ((*registerOne << 8) | *registerTwo);
};
calling this function gets tedious as you have to specify each register
get_word(&this->registers.h, &this->registers.l)
My question is if it okay to define a macro like so
#define get_HL() get_word(&this->registers.h, &this->registers.l)
since now I can call it using
get_HL()
The reason why I want to do it like this since I don't want to create more private/public functions that just perform function calls.
I have tried compiling and it seems to work as it should since its just a pre-processor macro but I am not sure of the design implication
EDIT:
Okay I mean there are glaring flaws with this and you should just make a function, just as much work to make a function or write a macro.
const Word get_HL() { return this->get_word(&this->h, &this->l); };
Let this be a post for people who had the same idea and hopefully stop making the same mistake
No, this isn't OK in my opinion. It hides what arguments you're passing into the function, and macros don't respect scopes and as such are highly susceptible to name conflicts. This seems like an ideal use case for a non-static member function.
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
I'm currently reading through Crash Course C++ and have a question regarding types.
If I declare and initialize both an int and a long long variable on a 64-bit machine running Linux to the decimal value 4, does the compiler recognize the wasted bytes and make changes to the underlying type? This is probably a no, as at some point that field may take on a value that would cause overflow with a smaller type (i.e. going from 8 bytes to 4).
I've read a little about object byte reordering during compilation in c++; that compilers can sometimes rearrange fields to minimize padding in memory. Just wondering if there is a similar optimization that happens for numeric types.
I do not think that the compiler will change the size of a variable. It might do so because of the as if rule, but if it can reliably do that, it means that the variable is used is a very simple context, for example assigned (or initialized) once from a constant and then only used in the same compilation unit and its address is not used (that last point if often said odr-usage for One Definition Rule).
But in that case, the compiler will simply optimize out the variable because it can directly use its value, so it will use no memory at all...
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 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 9 years ago.
Improve this question
I'm trying to make something in WinAPI but I get big loads of errors, corrected most of them but i cant find solution to that one:
for (LPINT i = 1; i <= ilosc; i++)
The compiler shows that error is is the "1".
I would post the entire code but its so unorganized that it would be hard to find this line in it the loop for declares its own variable so i think that I'm using the wrong type of variable (no clue what would be correct)
I changed the names of every variable I have to LP* and it solved almost all of my problems except this one.
Also if someone is well oriented in the topic of WinAPI could you teach me how to declare a variable in a textbox? I want to use textboxes as input sources for the variables so the program would count on numbers I type there? (the most of tutorials is written in very scientific language so I cant clarify myself good)
Also I know how bad at typing I am and that it lacks capitalization, punctuation, etc (I wasn't listening on language lessons in primary school and this mistake keeps showing off so don't rage at me cause I'm fixing it).
LPINT is a long pointer on int. Thats why you cannot assign a 1 to that variable.
LPINT is a typedef for typedef int *LPINT (http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx)
It's a pointer, not an int.