From: cross@spitfire.i.gajendra.net   
      
   In article <10eok5t$2u3pu$1@dont-email.me>,   
   Arne Vajhøj   wrote:   
   >On 11/8/2025 6:09 PM, Lawrence D’Oliveiro wrote:   
   >> On Sat, 8 Nov 2025 17:14:33 -0500, Arne Vajhøj wrote:   
   >>> On 11/8/2025 4:59 PM, Lawrence D’Oliveiro wrote:   
   >>>> On Fri, 7 Nov 2025 15:01:23 -0500, Arne Vajhøj wrote:   
   >>>>> Anyway the memory safety of Rust makes it clearly different from   
   >>>>> C/C++, but if we look at languages typical used for business   
   >>>>> applications, then memory safety is common.   
   >>>>   
   >>>> Do “business applications” need to do network connections?   
   >>>   
   >>> Absolutely.   
   >>>   
   >>> Requests coming in over the network. Accessing database servers,   
   >>> message queue servers, cache servers etc. during processing.   
   >>   
   >> Those are well-known sources of memory errors, buffer overflows,   
   >> security vulnerabilities caused by (accidentally or deliberately)   
   >> corrupted packets etc.   
   >   
   >Yes.   
   >   
   >But I don't think you got the point.   
   >   
   >Rewriting the business application from one   
   >memory safe language (Java, C#, Python, Pascal   
      
   Given the `POINTER` type, consequent support for type-casting   
   pointers, and dynamic memory allocation, it's hard to understand   
   how VSI Pascal can be considered meaningfully memory safe in the   
   way that Rust or a managed language is.   
      
   >or whatever) to Rust does not help anything.   
   >   
   >If the issue is at the application level, then   
   >the old language already prevent buffer overflow   
   >and if the issue is in some low level library,   
   >then nothing changes by rewriting the application.   
      
   I suspect that there is a lot of business code floating around   
   in memory-unsafe languages (MACRO-32, Pascal, maybe COBOL if   
   used in some odd ways) etc.  Not to mention FFI calls from safe   
   languages into unsafe code.   
      
   Rust on VMS would be cool.  Getting the compiler to generate   
   code that would load and run probably wouldn't be _that_ much of   
   a lift; a much bigger challenge would be getting the standard   
   library ported.  A Tokio executor for async code built on VMS   
   primitives would be cool; I suspect it's a pretty good fit.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)