←back to thread

The provenance memory model for C

(gustedt.wordpress.com)
224 points HexDecOctBin | 2 comments | | HN request time: 0.523s | source
Show context
smcameron ◴[] No.44424882[source]
Ugh. Are unicode variable names allowed in C now? That's horrific.
replies(5): >>44424985 #>>44425020 #>>44425869 #>>44426140 #>>44426336 #
OkayPhysicist ◴[] No.44425869[source]
Why shouldn't they be? It's not the 00's anymore, Unicode support is universal. You'd have to dust off some truly ancient tech to find something incapable of rendering it.

Source code is for humans, and thus should be written in whatever way makes it easiest to read, write, and understand for humans. If your language doesn't map onto ASCII, then Unicode support improves that goal. If your code is meant to directly implement some physics formula, then using the appropriate unicode characters might make it easier to read (and thus spot transcription errors, something I find far too often in physics simulations).

replies(3): >>44425932 #>>44426021 #>>44426146 #
someplaceguy ◴[] No.44426021[source]
> using the appropriate unicode characters might make it easier to read

It's probably also a great way to introduce almost undetectable security vulnerabilities by using Unicode characters that look similar to each other but in fact are different.

replies(1): >>44426189 #
1. OkayPhysicist ◴[] No.44426189[source]
This would cause your compilation to fail, unless you were deliberately declaring and using near identical symbols. Which would violate the whole "Code is meant to be easily read by humans" thing.
replies(1): >>44426222 #
2. someplaceguy ◴[] No.44426222[source]
> unless you were deliberately declaring and using near identical symbols.

Yes, that would probably be one way to do it.

> Which would violate the whole "Code is meant to be easily read by humans" thing.

I'd think someone who's deliberately and sneakily introducing a security vulnerability would want it to be undetectable, rather than easily readable.