[HN Gopher] Type++: Prohibiting Type Confusion with Inline Type ...
       ___________________________________________________________________
        
       Type++: Prohibiting Type Confusion with Inline Type Information
       [pdf]
        
       Author : pjmlp
       Score  : 28 points
       Date   : 2025-02-28 12:19 UTC (1 days ago)
        
 (HTM) web link (www.ndss-symposium.org)
 (TXT) w3m dump (www.ndss-symposium.org)
        
       | pizlonator wrote:
       | This is interesting, but it feels like the beginning of a path to
       | nowhere, since it only addresses bad downcasts and none of the
       | other memory safety problems in C/C++. It's totally unclear if
       | the technique they propose could compose with other memory safety
       | techniques to get us to a memory-safe C++.
       | 
       | Also their story about finding allocation sites using static
       | analysis is wishful thinking. There's just too much code out
       | there that does super funky stuff at allocation sites.
       | 
       | And they forgot to cite Fil-C (and Fil-C++), which does achieve
       | full memory safety (and has a complete story for what happens in
       | downcasts). They also forgot to cite a lot of their other
       | competition.
        
         | ok123456 wrote:
         | It's a low-cost way to eliminate a whole class of C++ memory
         | usage errors that typically arise at API boundaries. If g++ or
         | clang offered this as a flag, I'd turn it on.
        
           | pizlonator wrote:
           | Would you though? You'd pay a cost and you'd still have a
           | dumpster fire of memory safety bugs. Not to mention you'd
           | have to make code changes to be able to use it.
        
       | tialaramex wrote:
       | > This inline type field is key for fast and effective type
       | checks for all casts, similar to other type-safe languages (e.g.,
       | Java or Rust).
       | 
       | I am not a Java expert but I know enough Rust to detect a problem
       | here. Maybe it just needs clarification?
       | 
       | Rust is often not in fact storing the "inline type field", so
       | presumably they're thinking of some very particular cast and not
       | "all casts". But what cast?                 some_f64 as i32 //
       | Nope, that's going to emit code to work out the closest integer
       | <&str>::try_from(filename).unwrap() // Nope, that's just going to
       | check the filename is UTF-8 encoded
       | 
       | OK, they talk about "down casts" Rust doesn't have inheritance,
       | but presumably they're thinking of e.g how you go from an IpAddr
       | to an Ipv4Addr ? And now at last it makes a little sense, yes we
       | do need to store the difference between v4 and v6 in the data
       | structure. But, what I do not understand is, how can the
       | equivalent C++ (without type++) do anything reasonable here? Why
       | would this be a bug people repeatedly trip? I know C++ is
       | famously the language for footguns, but this is some gets() level
       | stuff if the "no type info YOLO cast" is a thing people actually
       | write.
        
       ___________________________________________________________________
       (page generated 2025-03-01 23:01 UTC)