From: mutazilah@nospicedham.gmail.com   
      
   On Monday, November 14, 2022 at 4:13:11 PM UTC+8, R.Wieser wrote:   
   > Paul,   
   > > What is the best way of producing an error here?   
   > That depends on 1) what kind of error you want (run or assmble time) 2) the   
   > assembler you're using.   
   >   
   > Looking at the example code it looks to me you want #2. In that case you   
   > could check if your assember has something like "@err" (for errors) and   
   > "@out" (for warnings).   
   >   
   > And a suggestion : when one of the blocks contains an program (error) exit   
   > than you do not need to use an "else". Just make sure that the error-exit   
   > is in the first, main block :   
   > - - - - - - - - - -   
   > if not @DataSize   
   > error you must use a model with far data pointers   
   > endif   
   > push ds   
   > - - - - - - - - - -   
   > notice the "not" after the "if"   
      
   Hi Rudy, thanks for your reply.   
      
   Yes, I am after an assembly error.   
      
   But neither @err nor not seem to work on masm or wasm.   
      
   @err gives an error and "not" seems to be used as a variable   
   which is false.   
      
   However, I now accept small data pointers so I no longer   
   need to produce an error so it doesn't matter any more.   
      
   On the subject of small and medium memory model -   
   how is it possible for them to work? Functions can   
   accept pointers that originated from either the stack   
   or the data segment, or potentially even the code   
   section if literals are stored there.   
      
   Those are different address spaces. How did DOS compiler   
   vendors manage to get a sensible result?   
      
   Did they define the buffer in fwrite etc to be "far" to force   
   an override? That would work for the C library, but fall down   
   when it comes to user code.   
      
   Thanks. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)