Printable View
Hey,
I'm doing some weird things (mix of C/C++), and I'd like to know if I was allowed to use malloc(0):
Or if Windows may crash after that...Code:#include <stdlib.h>
int main()
{
int *i = malloc (0);
free(i);
return 0;
}
I succeeded making Windows crash with my weird programs once :p
You can't crash Windows with non-kernel mode apps... It will crash your application, sure, but nothing else.
Malloc(0) if I'm not mistaken is allowed, but may give unexpected results (such as an allocation of 0 bytes). Best if you don't do it.
I did it a few times (crashed windows), running some SDL application of my own right after windows started. (blue screen of death... I saw it on Vista!)
I'm totally OK with allowing 0 bytes, i'm just wondering if free(ptr) will behave normally on a 0-byte allocated pointer, and if i may have a memory leak.
Sorry for my bad english :-/
Probably bad drivers or you did something wrong that confused the drivers.Quote:
Originally Posted by coyotte508
Yes, free will work, but you probably won't be able to use your allocated memory for anything.Quote:
I'm totally OK with allowing 0 bytes, i'm just wondering if free(ptr) will behave normally on a 0-byte allocated pointer, and if i may have a memory leak.
ok thanks a lot.
It'd be long to explain why in some cases i may allocate 0 bytes.
I don't believe there's any good reason for it.
Perhaps you should explain your situation.
As it stands, there is nothing wrong with your initial program.
Dereferencing the pointer would be a bad thing to do (malloc(0) is allowed to return NULL).
If there is any crashing in the program, then it's more likely to be some other problem unrelated to this. Cause and effect are separate things when it comes to memory corruption, and all you've seen so far is an effect (not a cause).
Edit:
Thanks Salem for your answer, thanks to you I'm sure there are no probs.
There is no crashing, but i needed to be sure.
also if you don't free, you'll probably have a memory leak due to the record keeping in the CRT.
Oh I wouldn't be too sure of that... there's always a way.Quote:
Originally Posted by Elysia
Hell I even managed to get a complete crash on Linux once, and I wasn't doing anything out of the ordinary.
That seems kind of weird.
What exactly did you do?
Operating systems don't crash right out of the blur from a user mode application...
The easiest way to crash Linux is to use Wine to execute a buggy Windows application. ;)
Wine seems to be doing a little more than just user mode stuff...
Were you running as root?Quote:
Originally Posted by iMalc
Yes, I'm sure it does.Quote:
Wine seems to be doing a little more than just user mode stuff...
I just wouldn't say that you can't crash Windows with a "user-mode" application. You never know what could happen.
Well, alright, it's unlikely.
Unless that app triggers some bug in the code or some bug in kernel mode stuff, there's no chance it will crash the OS, though.
Nope I wasn't running as root, and nope I didn't write a fork bomb:devil:
I was just working on my asignment one day and poof! One of the linux geeks tried everything and told me the kernel really was crashed - nothing whatsoever worked.
As for Windows, that'll crash too if you're unlucky. You learn to avoid doing certain things after a while. For example, don't try performing a drag and drop operation in any program whilst your code is sitting at a breakpoint in the middle of your drag and drop handling code. It's also not good to terminate other processes or their threads at random.
"no chance it will crash the OS" - yeah cause OSes never have bugs - especially not Windows...:eek:
I never did mention Windows wasn't buggy and that there was no way a user mode app your crash windows ;)Quote:
Originally Posted by iMalc
I did mention that it can if it triggers a bug. If there was no bug, it would be impossible... but no OS is perfect and won't ever be, will they?
Of all kernel code, the graphics driver is statistically most likely to cause a BSOD - because graphics drivers, even for Vista where a large portion is moved out of kernel mode, is very complex, and there are oodles of combinations of arguments and functionality that are all handled by a handful of basic functions - many pointers for example are valid to be NULL in some circumstances, but not in others.Quote:
Originally Posted by coyotte508
I would think that it does, but it's quite certainly one of the obvious corner cases that not normally is encountered in well-behaved code (you NEVER need to allocate zero bytes of memory). On the other hand, the management of allocated memory blocks is done outside of the actual allocation, so it shouldn't matter of it's 0, 1, 13 or 400KB - it's all done the same way anyways [and will most likely take up 32 or 64 bytes of memory even if you allocate zero bytes].Quote:
I'm totally OK with allowing 0 bytes, i'm just wondering if free(ptr) will behave normally on a 0-byte allocated pointer, and if i may have a memory leak.
--
Mats