> 1. More often than not programmers cannot choose on which platform their
product will be used.
This code will be used on Windows, and not on some other platform, isn’t this obvious?
- MISRA rules do not agree with you when it comes to dynamic allocations.
MISRA rules - after a quick Google search - prohibit any sane C coding
Not only malloc() is prohibited, but also offsetof().
Neither Windows nor Linux is definitely not compatible with such moronic rules. Only some tiny OS-less embedded code with hardcoded table sizes (design of 1970ies like of RSX-11M), string sizes (hello buffer overruns!) etc.
And yes, DirectShow (which is what you’re working on) is not compatible with such moronic rules too.
Another guy (his name is Mr. Bill Gatliff) here is agree with me on “moronic”:
http://www.embedded.com/design/prototyping-and-development/4007569/The-yin-and-yang-of-dynamic-allocation
No wonder that, after such moronic rules were developed, we have stack overflow bug in Toyota’s ECU which causes the engine to sometimes do full throttle without the human pushing a gas pedal.
Surely, if you ban dynamic allocations, people WILL allocate stuff on stack, to overflow it soon.
I really cannot understand why pull this nightmarish coding style of 1970ies (or assembler coding style of ZX-Spectrum of 1990ies) to modern OSes.
- When you have 256MB of memory you should worry about dynamic
allocations,
256MB is not enough to allocate the DirectShow device name? amazing 
256MB is I think the RAM size of iPhone 1, which could run lots of smart apps.
especially if you are writing a Windows service which has
to run for weeks or even months without reboot.
Nothing fancy. Windows or Linux kernel, with lots of custom drivers, is surely capable of this. And yes, both use dynamic allocations a lot.
Test your stuff with a memory leak detector. Use AppVerifier, or write your own (like MFC does).
- When you know that any exception thrown by your service (for example
by double free() or by accessing free’d memory)
Eliminate all this stuff by testing.
Or well, use C++ and wrap all allocations to classes. This will even increase the stability, and is a Best Way To Defeat The Buffer Overruns since at least 1992.
(and that behavior is out of your control), you look for ways to
minimize the risks.
Minimizing the risks by hardcoding the sizes???
Don’t you understand that you (together with the authors of the moronic rule set mentioned above) maximize the risks instead?
It is by far easier to miss something in the size calculation, then to free() a wrong pointer. Much easier.
- In this case worrying about buffer overruns is pointless when the
system is running XP SP2 and both hardware and software is strictly
controlled.
Oh my God… it is your code which will do the buffer overrun, not XP SP2s 
Yes, your strictly controlled code, on your strictly controlled hardware.
It will do the buffer overrun immediately after the static array you use for some string will have size 1 less since you’ve forgotten to count the terminating zero.
BTW - why SP2? Why not SP3? Another moronity?
I hope the above explains why I was asking such a simple question.
Oh yes. You’re pushing the very, very doubtful rules from the world of 64K embedded systems (I doubt that, for instance, MISRA-compatible TCP/IP stack ever existed) to modern (well, XP is not, but still more or less modern) mature OS with 256MB of memory.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com