411–420 of 433 posts
Earlier quoted context omitted.
I don't quite understand. Why use a janky, lossy Linux emulation layer when you can just target Windows natively?
For some reason git for windows is a cygwin build.
Earlier quoted context omitted.
The compiler has already the concept of scope and variables existing at least in the optimizer. Ownership tracking programs for C have been existing for 20 years, so it can't be too hard to integrate it in the compiler, once it has been implemented for one language.
> The compiler has already the concept of scope and variables existing at least in the optimizer. My gut feeling is that while the high-level concepts might share a name I'm not actually sure if they're similar enough for useful transfer? The optimizer is working on a very different representation at a later stage of the compilation process, so I'm a bit skeptical about the level of similarity and/or transferability…
You're probably right, I was saying it just can be transferred, with a large "just".
> the fact that neither GCC nor Clang appear to have discussed reusing concepts from their optimizer passes to recreate the borrow checker or borrow checker-like functionality
There is however a commitment from GCC, that every UB the compiler exploits must be reported by -fanalyzer, otherwise it's a compiler bug.
> Ownership tracking programs for C
I think Frama-C is a modern program: https://frama-c.com/.
Where I got to know the concept is SPlint: http://splint.org/ Last I checked the development stopped in 2010 and the implementation shipped in Debian was buggy, but there seams to be newer development on Github. The initial commit is from 2000-06-13.
I've given up on using it due to bugs, but I do use the annotation to specify, among other things, ownership semantics in C.
Any C API already documents ownership semantics, otherwise its underspecified and can't be used. It's just specified in prose instead of code. The semantics are however more often more complicated then a simple owning pointer. A common thing is for example, that whether ownership was transferred depends on the return value of the called function.
There are C APIs out there without the necessary documentation, but you can't actually use them, without either introducing leaks, use-after-free bugs or reading the source code.
> Sorry, I'm getting a bit confused here. When you say "integrate it in the compiler", by "it" do you mean the above mentioned "ownership tracking programs for C", or do you mean features implemented in the GCC Rust frontend?
"it" means ownership tracking implementation intended for Rust in the frontend.
Earlier quoted context omitted.
Im on the same boat :) But no worries. You can always build and use older git without rust. Of course, it will work for a while until those kids will change the proto for the "better". And being old and grumpy also means, you can slowly care less and less about all that moot :) Kids: now downvote it into oblivion :) Like I give a shit...
These things often get presented as an age thing, but I think they aren't. It's very weird, I'm young but I feel like having the same stance in a lot of topics, in politics, but also here. I don't know how to deal with this. You guys have it easy (/s), you don't have to live with this for long, but I feel like I'm growing up into an increasingly hostile environment.
Well, dunno what to say about it to you.. Its indeed sad.
Earlier quoted context omitted.
> Any non-free standing program running on a modern OS on modern hardware trying to access memory its not supposed to will be killed by the OS. This seems like a rather strong statement to me. Do you mind elaborating further?
I think bugs in the MMU hardware or the kernel accidentally configuring the MMU to allow access across processes that isn't supposed to be are quite rare.
Earlier quoted context omitted.
These things often get presented as an age thing, but I think they aren't. It's very weird, I'm young but I feel like having the same stance in a lot of topics, in politics, but also here. I don't know how to deal with this. You guys have it easy (/s), you don't have to live with this for long, but I feel like I'm growing up into an increasingly hostile environment.
Well, it is age thing, because young people start they experience in current tech and only those determined enough can take a look on past tech, how it was used and how it evolved. Thats always was minority.. There are just 2 kind of people there: Those who belive and those who research.. ;) Well, dunno what to say about it to you.. Its indeed sad.
Earlier quoted context omitted.
> The compiler has already the concept of scope and variables existing at least in the optimizer. My gut feeling is that while the high-level concepts might share a name I'm not actually sure if they're similar enough for useful transfer? The optimizer is working on a very different representation at a later stage of the compilation process, so I'm a bit skeptical about the level of similarity and/or transferability…
> My gut feeling is You're probably right, I was saying it just can be transferred, with a large "just". > the fact that neither GCC nor Clang appear to have discussed reusing concepts from their optimizer passes to recreate the borrow checker or borrow checker-like functionality There is however a commitment from GCC, that every UB the compiler exploits must be reported by -fanalyzer, otherwise it's a compiler bug.…
I'm not really convinced it can be transferred at all, but I'm not convinced it can't be either. The "just" feels so large as effectively
> There is however a commitment from GCC, that every UB the compiler exploits must be reported by -fanalyzer, otherwise it's a compiler bug.
Huh, don't think I've heard that commitment before. Do you mean that the GCC devs intend for -fanalyzer to (eventually?) guarantee catching all exploitable UB (which would be... ambitious, to say the least), or that -fanalyzer is a best-effort analysis? The docs currently state the latter more or less ("It is neither sound nor complete: it can have false positives and false negatives.") but that doesn't necessarily rule out attempts to make it so later (though that feels like it should run into Rice's theorem and/or false positive rate issues and/or require code alterations).
The closest thing I heard of is something about Clang/LLVM aiming to catch all the UB it exploits using sanitizers, but that's done at runtime so it's a lot easier to be precise about what you catch.
> I think Frama-C is a modern program: https://frama-c.com/.
Ah. I suppose that counts, though I would probably describe Frama-C as more than just an ownership tracking program given its other capabilities. I guess it technically could fill the same niche as the borrow checker, though given its capabilities and what's needed to use it I think there's probably not a lot of practical overlap in use cases.
> Where I got to know the concept is SPlint: http://splint.org/
Haven't heard of that one before. It does look like it can provide (some?) similar capabilities, though perhaps not to the same level of soundness as what the borrow checker provides. From one of the papers linked on the website [0]:
> In real programs it is sometimes necessary to use weaker assumptions about memory use. The `owned` annotation denotes a reference with an obligation to release storage. Unlike `only`, however, other external references (marked with `dependent` annotations) may share this object. It is up to the programmer to ensure that the lifetime of a `dependent `reference is contained within the lifetime of the corresponding `owned` reference.
It's also not quite clear to me whether Splint can cover more "interesting" borrow checker cases like those involving named lifetimes or view structs, but given this is the first time I've heard of it I definitely don't have the experience or knowledge to say for sure.
> There are C APIs out there without the necessary documentation, but you can't actually use them, without either introducing leaks, use-after-free bugs or reading the source code.
Sure, and that's what makes analysis so practically difficult. Whole program analysis doesn't scale well, standard C doesn't have enough information for cheap inference, etc., etc.
> "it" means ownership tracking implementation intended for Rust in the frontend.
In that case I'm not sure if gccrs would provide the implementation you hope for since they currently plan on integrating rustc's borrow checker implementation as-is. I'm not aware of a desire to write an independent borrow checker implementation at the moment as well.
Earlier quoted context omitted.
I think bugs in the MMU hardware or the kernel accidentally configuring the MMU to allow access across processes that isn't supposed to be are quite rare.
Sure, but I think illegal interprocess memory accesses is a fairly narrow definition for "access[ing] memory its not supposed to". There's plenty of undesirable memory accesses that are possible without needing to cross process boundaries and I don't think the OS does that much to solve those outside of currently niche hardware.
Earlier quoted context omitted.
Well, it is age thing, because young people start they experience in current tech and only those determined enough can take a look on past tech, how it was used and how it evolved. Thats always was minority.. There are just 2 kind of people there: Those who belive and those who research.. ;) Well, dunno what to say about it to you.. Its indeed sad.
Well the young people I meet know a mix of Python, C++ and C. And then they are those, who don't use C, because its too high-level and design their own processors instead. That's the current tech I experience directly.
Its cool to design sth from scratch, like its own CPU, but it only makes sense if you really enjoy it.. Except, its waste of time. I myself live in retro computing abit, but it have it limits. Like, I would not go back to prised 6502 CPU. Yeah, it was great, legendary CPU, but if we take a look at even cheap options we can buy and use for hobbie projects, there are plenty of pretty quick and capable 32bit CPUs. Its hard to go below 32bit really.
Dont get me wrong, I pay big respect to demoscene, and what they can achieve on C64 for example :). Uber skilled guys, but this is an art :)
Earlier quoted context omitted.
Well the young people I meet know a mix of Python, C++ and C. And then they are those, who don't use C, because its too high-level and design their own processors instead. That's the current tech I experience directly.
Hah.. C as too high level :) Thats weird.. Its cool to design sth from scratch, like its own CPU, but it only makes sense if you really enjoy it.. Except, its waste of time. I myself live in retro computing abit, but it have it limits. Like, I would not go back to prised 6502 CPU. Yeah, it was great, legendary CPU, but if we take a look at even cheap options we can buy and use for hobbie projects, there are plenty of…