4 ms·
Pointers are not even necessary for writing operating systems or memory allocators. The Oberon system writes those low-level components using intrinsic peek/po
by Athas 8y ago
Pointers are not even necessary for writing operating systems or memory allocators. The Oberon system writes those low-level components using intrinsic peek/poke functions (like some ancient BASIC!) that are recognised specially by the compiler and turned into direct memory modifications. This is clearly just as unsafe as pointers (probably more so), but it means you don't generally pollute the language to support some very specialised code. The rest of Oberon is memory-safe and garbage-collected (with the garbage collector also written in Oberon).
- josteink 8y ago> The Oberon system writes those low-level components using intrinsic peek/poke functions (like some ancient BASIC!) that are recognised specially by the compiler and turned into direct memory modifications. This is clearly just as unsafe as pointers (probably more so), but it means you don't generally pollute the language to support some very specialised code. How is "val = PEEK adr" and "POKE adr, val" any less polluting than allowing "val = &adr" and "&adr = val" in select places?
- pjmlp 8y agoIt shouts to you, "Take care something dangerous going on". Hieroglyphs are easy to pass by.
- josteink 8y agoLots of languages (like C#) allow pointers, but only inside blocks explicitly declared to be unsafe. void DoSomeUnsafeStuffHere() { // regular code here. pointers verboten. unsafe { // pointery stuff here } } I think that is equally clear, if not even more. And again: I don't think this is any more polluting than weird out of place PEEK/POKE statements.
- eterps 8y agoWhat makes it unclear is exactly this 'pointery stuff'. There's nothing inherently unsafe about strongly typed pointers, but that's not the same as direct memory modification (which is obviously unsafe).
- josteink 8y agoStrongly typed pointers is just another name for direct memory access. The following is perfectly typesafe: SuperClass[] items = GetArrayOfSubClass(); Now if we try to do unsafe things to items, we may end up accidentally accessing memory we shouldn't. unsafe { for (int i=0; i < items.Length; i++) { var currentItem = &items[i*sizeof(SuperClass)]; } } This may or may not work, based on the runtime memory-layout of the subclass. Basically the presence of unsafe {} means that beyond this point correctness cannot be guaranteed by the compiler. That's in fact what the keyword is for. And that's the marker you are looking for. No need to go digging deeper into the code looking for the actual pointers themselves.
- pjmlp 8y agoThat is true, my point was that for C and C++ that is not clear at all. You cannot simply search for & and * regarding point operations because those are also valid numeric operators, thus with context dependent meaning. Being able to search for PEEK/POKE, SYSTEM.PUT/SYSTEM.GET, or just unsafe blocks makes all the difference tracking down unsafe code. Also note that unsafe code blocks is older than C almost for 10 years, as ESPOL/NEWP already had such feature in 1961.
- Koshkin 8y ago> You cannot simply search Which is one of the reasons why in the modern world (of fast CPUs and large RAM) code should be edited using editors that "understand" the language's syntax.
- eterps 8y agoIt makes it easier to analyze code (i.e. greppable), and it allows for a distinction between operations that do direct memory modification and regular application code (pass by reference is accomplished with an entirely different syntax in Oberon, same for pointer types).
- informatimago 8y agoIt is as unsafe as pointer, if those PEEK and POKE operations don't perform any control. But there's no reason to allow random PEEK and POKE from random processes. The system process that manage memory may be given the access rights to PEEK and POKE the memory manager registers. But not the IDE registers. And application processes won't have the right to PEEK and POKE anything.