From: alexfrunews@gmail.com   
      
   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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)