[HN Gopher] C can be memory safe
       ___________________________________________________________________
        
       C can be memory safe
        
       Author : udev4096
       Score  : 17 points
       Date   : 2024-06-20 17:31 UTC (5 hours ago)
        
 (HTM) web link (blog.erratasec.com)
 (TXT) w3m dump (blog.erratasec.com)
        
       | nesarkvechnep wrote:
       | C can be memory safe, we only need to turn these features on. Oh,
       | by the way, these features don't exist.
        
         | favorited wrote:
         | Don't worry, they said it's relatively easy to add!
        
       | ycombinatrix wrote:
       | >The core principle of computer-science is that we need to live
       | with legacy, not abandon it.
       | 
       | ...wat
        
       | TwentyPosts wrote:
       | > The core principle of computer-science is that we need to live
       | with legacy, not abandon it.
       | 
       | I feel like the author misunderstands what a "core principle" is.
       | This here is (at most) a bitter lesson learned from several
       | decades of experience. It's _not_ a principle, it 's at best a
       | conclusion following multiple stories of getting rid of legacy
       | systems, but even as that this is highly dubious.
        
       | comex wrote:
       | See also Clang bounds safety, an implementation of a very similar
       | concept:
       | 
       | https://clang.llvm.org/docs/BoundsSafety.html
        
       | JonChesterfield wrote:
       | This is abject nonsense to the extent that I hope it is machine
       | generated.
       | 
       | Sufficiently carefully written C can execute without memory
       | errors, in exactly the same way that sufficiently carefully
       | written assembly can be. That's not a memory safe language, it's
       | a program which manages to not corrupt its own state.
       | 
       | There are compiler flags, sanitisers, static analysis, testing
       | strategies and so forth to help one write something in C that
       | doesn't fall over unexpectedly, but even with absolutely all of
       | it implemented you still don't have a memory safe platform to
       | build on.
        
       | pdimitar wrote:
       | Everything can be theoretically be safe if you just do X and Y,
       | but very often the economical incentives are to avoid doing X and
       | Y (mostly to reduce expenses) so if you don't have safety as a
       | complete stopper (as in: program does not compile if you don't
       | abide by safety) then programs will be unsafe until the end of
       | time.
       | 
       | We have to stop the problem at the door, not let it in and try to
       | pacify it after it has destroyed half the room.
       | 
       | What a nonsensical article. I mean yeah, guns with the safety off
       | are perfectly safe if 100% of all users have perfect trigger
       | discipline, right?
        
       | thecodedmessage wrote:
       | The way they're using hard-fork and soft-fork, is that based on
       | the blockchain usage of the words? If so, that makes it hard for
       | me to take seriously!
        
         | zaphod420 wrote:
         | I think a better term would have been "non-breaking backwards
         | compatible change". hard/soft forks are very much the jargon
         | used when talking about ways to upgrade blockchain based
         | protocols.
        
       | FridgeSeal wrote:
       | Gosh some people are really, really desperate to continue with
       | the whole C-is-still-perfectly-fine thing aren't they?
       | 
       | I mean sure, feel free to continue writing it, nobody else cares,
       | but let's not pretend it doesn't have rampant issues.
        
       | pjmlp wrote:
       | Microsoft has introduced SAL during Windows XP SP2 days, which
       | these articles keep forgetting about, including that SAL is sadly
       | largely ignored, other than Microsoft teams.
       | 
       | https://learn.microsoft.com/en-us/cpp/code-quality/understan...
        
       ___________________________________________________________________
       (page generated 2024-06-20 23:02 UTC)