1. 19
  1.  

  2. 2

    For me, it’s a frustrating glimpse into the Windows culture of disrespect to conventions. Why, why on earth would you use unallocated volatile memory? Why *nix developers do not need this kind of reminders? Is it lack of trust and transparency from/to the OS vendor in case of Microsoft? A more disciplined culture around *nix?

    Also, I don’t see the question properly answered.

    A debugger may use the memory beyond the red zone as a convenient place to store some data.

    — while it may choose to do so, it’s the fault of a debugger to use volatile memory.

    My understanding of red zone is that it’s often useful for a compiler to have some space for leaf subroutines to avoid stack allocation/deallocation instructions. The article seems to hint that a debugger might use the red zone too, but that’s another dangerous decision: the program is free to use the red zone as well, also making it volatile.

    1. 5

      There are similar ABI rules on UNIX systems as well. On 64-bit x86, illumos has a red zone of (I believe) 128 bytes beyond the top of the stack. Unless you have made other arrangements, a signal taken on that thread will write into memory beyond the red zone to establish the signal handling call frame. A debugger may also have taken control of a process, stopped a particular thread, and arranged a call frame (similar to the .call command in the article) which must also start beyond the red zone.

      None of this advice seems particularly Windows specific in anything but the finest details.

      1. 4

        Why *nix developers do not need this kind of reminders?

        Who says they don’t? I’ve read plenty of angry letters about violating platform conventions.

        I’d say the biggest differences is that, instead of writing a blog post, FOSS people complain about violations of platform conventions on the project’s public issue tracker. Because Windows apps often don’t have a public issue tracker.