From: alexfrunews@gmail.com   
      
   On Thursday, March 2, 2023 at 12:30:12 AM UTC-8, Alexei A. Frounze wrote:   
   > On Wednesday, March 1, 2023 at 10:47:09 PM UTC-8, muta...@gmail.com wrote:    
   > > On Thursday, March 2, 2023 at 1:34:09 PM UTC+8, Alexei A. Frounze wrote:    
   > > > On Wednesday, March 1, 2023 at 8:53:51 PM UTC-8, muta...@gmail.com   
   wrote:    
   > > > > Ok, I'm back on my computer now and was able to raise a bug report:    
   > > > >    
   > > > > https://github.com/llvm/llvm-project/issues/61112    
   > > > >    
   > > > > BFN. Paul.    
   > > > Without looking any further, you're taking address of a parameter (p),    
   > > > and doing pointer arithmetic on it. The only valid arithmetic here    
   > > > would be adding 0 or 1, but not 5, 6 or 7. But even if you add 1 to &p,    
   > > > you aren't allowed to dereference it (as in *(&p + 1)).    
   > > > You can only subtract the 1 back (as in (&p + 1) - 1) or compute    
   > > > a difference of that and &p (as in (&p + 1) - &p or the other way   
   around).    
   > > > Your shady pointer manipulation is undefined behavior and    
   > > > I almost guarantee your clang bug being soon closed as invalid.    
   > > >    
   > > > Write clean code. OK, write cleaner code. Maybe, refresh your ANSI C    
   > > > to get there.    
   > > "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.   
   > > But you can still give a sensible result.   
   > Sure. Garbage in, garbage out, as is the case here, is a 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.   
   > > 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.   
   > > 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.   
   > > 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.    
   >    
   > Alex   
      
   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)).   
      
   Alex   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)