Large buffers

[K_F]

Van,

Just step back 1 branch of your call tree, allocate and deallocate in the same scope OR use a GLOBAL handle for the memory and you won't have either problem.

Yup.. I've looked at that, but it doesn't make much difference as I have to keep the buffers alive for the whole duration of the applicaton. Essentially it's either using the .data? or the heap thing.
I suppose it would be more manageable picking up errors using the heap, than it being out of one's control using .data? section.
I'll try a balance of both - the larger buffers in the heap.

[Tedd]

We agree on that point, but proving it is difficult. You might find zerobytes in the global buffer because the OS gave you "by accident" a memory area that was zeroed. Maybe one in a Million times the OS gives you garbage - how can you prove that? So I chose the other way: To prove (successfully) that the C compiler does nothing to the memory, i.e. it relies on the memory being zeroed by the OS.

The fact that C programs rely on the memory being zeroed is proof that it will be zeroed.
It it wasn't purposely zeroed by the OS, the majority of software would have problems (aside from the numerous pre-existing bugs :P)
It is well known that the majority of software relies on this, and so it is necessarily enforced by the OS.

Making assumptions based on "we don't know for sure this one thing might not be done once every million times" is ridiculous. If you write software that relies on the underlying OS, you have to make certain assumptions of its competence and trust those assumptions, otherwise you're going to be reimplementing the OS in every single program.

[jj2007]

The fact that C programs rely on the memory being zeroed is proof that it will be zeroed.

That was exactly my point, thanks for confirming it :icon14:

[hutch--]

If there is one thing I have learnt writing Windows code (since win 3.0) is not to trust an assumption about the future intent of the OS developer. Time after time I have seen these assumptions broken, Win95 assumption were broken with the introduction of UNICODE in later OS versions as the core guts of the OS is different. I am currently seeing it in code that was developed in 32 bit XP that used fully documented API calls break in Win7 64 bit, one of the more common ones is some SendMessage() calls fail due to timing issues and where you replace it with PostMessage() to get the necessary time lag.

Now bring this approach back to the distinction between initialised memory and uninitialised memory, the distinction is there for a reason, one you write values to in the .DATA section and the other you allocate space and initialise them in runtime code to whatever you want. Trusting and hoping that BSS memory will always be zero is a formula for a future OS making your code go BANG. You advantage in using uninitialised memory is disk space saving, not a pseudo initialised to zero .DATA section. If you want zero filled memory, allocate it and if you need to re-use it zero filled, use a simple algo to zero it again.

I have yet to see the point of writing sloppy dangerous code.

[redskull]

We agree on that point, but proving it is difficult.

Well, yes and no.  Any common-criteria certified operating system has to give out initialized pages as a basic security measure; if pages were uninitialized, you would end up with the data from the process most recently ended, potentially receiving all manner of fun plain-text passwords and other sensitive data.  Windows has a whole class of "demand zero" page faults to specify such an occurrence (as opposed to when pages are read from disk, for example, and can be initialized to their contents), as well as a background thread to do this during downtime.

That being said, nothing says that it has to be initialized to zero other than convention.  The MMU on Windows 10, for example, could give out pages initialized to 1, or 2, or BAAD F00D, or whatever else it wanted if they felt so inclined.  So no, depending on it being initialized specifically to zero is never a good idea.

-r

[jj2007]

The MMU on Windows 10, for example, could give out pages initialized to 1, or 2, or BAAD F00D

SCARY!! Indeed, that would be much more fun than the year 2000 bug

(and Pelles C, Microsoft Visual C and probably a bunch of other compilers will have to be rewritten, because currently they do rely on uninitialised memory being zeroed by the OS...)

[sinsi]

If you use VirtualAlloc it's guaranteed zero-filled.

Memory allocated by this function is automatically initialized to zero, unless MEM_RESET is specified.

[K_F]

SCARY!! Indeed, that would be much more fun than the year 2000 bug
(and Pelles C, Microsoft Visual C and probably a bunch of other compilers will have to be rewritten, because currently they do rely on uninitialised memory being zeroed by the OS...)

Well, I don't think it's scary at all...
I always 'zip' my variables/buffers (.data(?) or heap) before I use them, as a matter of course.
Never had a problem
:)

[FORTRANS]

Hi,

That being said, nothing says that it has to be initialized to zero other than convention.  The MMU on Windows 10, for example, could give out pages initialized to 1, or 2, or BAAD F00D, or whatever else it wanted if they felt so inclined.  So no, depending on it being initialized specifically to zero is never a good idea.

   Yeah, I worked on a mainframe where the uninitialized memory
(in a FORTRAN program) was set to an illegal value for a floating point
number.  So, if you did not actually specify something, your program
died.  Sets up some programming habits that last a long time.

Regards,

Steve N.