Hacker News new | past | comments | ask | show | jobs | submit login

A chaotic part of me thinks that C should be illegal for security code for the lack of this.



Just Googled and seems fat pointers can at least prevent buffer overflow. I want to know more about other returns and costs on changing C to fat pointers.

https://security.stackexchange.com/questions/155572/how-are-...


They can prevent some buffer overflows, assuming that the data in the fat pointer remains correct. If you want to prevent buffer overflows completely you need to go well beyond that and effectively either use a higher-level language with a runtime and GC making sure everything remains coherent or do what Rust is doing with its borrow checker.

Not that I'm against fat pointers in C, I always thought that in hindsight not having a primitive "slice" type was a mistake. In particular using NUL-terminated strings instead of slices is both error-prone and makes implementing even basic string-splitting functions like strtok annoying or inefficient (you need to be able to mutate the source string to insert the NULs or you have to allocate memory and copy each component. If you had slices you could easily return a portion of the string without mutation or copy).


> If you had slices you could easily return a portion of the string without mutation or copy).

In this case you get another problem: how to free memory when there might be many slices pointing at it.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: