From: muta...@gmail.com   
      
   On Thursday, March 2, 2023 at 4:30:12 PM UTC+8, Alexei A. Frounze wrote:   
      
   > > "undefined behavior" shouldn't mean "let's leave the stack    
   > > uninitialized, and not even issue a warning". It just means    
   > > you can't guarantee what the result will be.   
      
   > This is wishful thinking. The standard means that all bets are off    
   > regardless of your thinking of what should or should not be.   
      
   Sure. The standard doesn't stop the compiler from   
   detecting the unportable code and reformatting my   
   hard disk. That doesn't mean it should. There is a   
   sensible thing to do, and it could have done it.   
      
   There's even an asshole thing to do - throw a compile   
   error.   
      
   But it's simply diabolical to introduce a random value.   
      
   > > But you can still give a sensible result.   
      
   > Sure. Garbage in, garbage out, as is the case here, is a sensible result.   
      
   No it isn't. The perfectly fine stack manipulation is the   
   sensible result.   
      
   > > In this case, I am trying to inspect the stack. I'm using    
   > > knowledge of the x86 as to what the stack looks like,    
   > > and the calling convention.   
      
   > If the compiler inlines some code or uses link-time optimization,    
   > there may be no stack at all. This likely won't happen if the caller    
   > is some assembly code, but throw in enough C and it becomes    
   > a possibility.   
      
   The caller is an external unit of work. The parameter passing   
   mechanism needs to be fixed in place.   
      
   It is the equivalent of assembler.   
      
   That is what I want - a compile time option that assumes that   
   this is an independent body of work called by assembler.   
      
   If only ancient compilers support that concept, then fine,   
   I'm going to use a modern ancient compiler.   
      
   > > Yes. That code won't work on every platform in the world.    
   > >    
   > > But it should work perfectly fine when I know the layout.   
      
   > If you use an ancient compiler or disable optimizations in a modern    
   > one, maybe.   
      
   Or use gcc. It didn't have a problem.   
      
   > > It is not in the spirit of C to catch every undefined behavior    
   > > and throw an error. And in this case, even throwing an error    
   > > would be better than silent failure and garbage.   
      
   > The standard does not require to detect undefined behavior    
   > at compile or run time and inform of it. In some cases such    
   > detection is impractically expensive if not outright impossible.   
      
   See above about reformatting the hard disk.   
      
   > > Even if setting a pointer to the arbitrary value 0xb8000 and    
   > > indexing up a 1000 bytes is undefined behavior, doesn't    
   > > mean it should be disallowed either.   
      
   > That's less relevant to your current problem, I think.    
      
   No. It's exactly relevant.   
      
   > If you really want to manipulate stuff directly on the stack,   
   > declare a structure type with those things that will be on   
   > the stack. On the caller side push the struct contents to the   
   > stack and pass ESP as an argument to your C function   
   > (make sure to abide by the ABI w.r.t. saved and non-saved   
   > registers and ESP alignment (ESP may be expected to be   
   > a multiple of 8 or 16, not just a multiple of 4)).   
      
   I can't control the external caller.   
      
   Which is the Linux OS.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)