Octal literals have their uses (you Unix haters skip this one)

Brendan Eich brendan at mozilla.com
Thu Jan 12 10:01:28 PST 2012


See https://github.com/jashkenas/coffee-script/pull/2021 -- strict mode 
support in CoffeeScript exposes a valid use-case, Unix-flavor file 
permissions (mode bits we used to say). Node.js APIs really want users 
to call with literals such as 0644. Strict mode says no way.

For now CoffeeScript probably will support 0o644 and translate to hex or 
decimal literals to dodge the strict error. But ES5 still has octal in 
Annex B, and AFAIK octal support is still required for web compatibility.

Strict mode is not being adopted widely enough, certainly not in node.js 
code, to kill octal literals. Killing octal literals is user-hostile 
when it comes to Unix permissions. So I think we should stop tilting at 
a friendly windmill, and either support octal literals (but not noctal 
-- no 08 or 09), or support 0o377 etc. as CoffeeScript looks like it 
will do.

Some may object to lowercase o as prefix. It's clear enough in all 
fonts, but if we allow uppercase O too, then some might fear user 
confusion with 0 used instead of O. But if we support 0o377 and 0O377, 
we can continue to reject (in strict mode and therefore in Harmony) 
00377. Anyway, there's no homograph phishing attack threat as with URLs.

If the CoffeeScript experiment with 0o prefixes for octal works out, I 
think we should adopt that prefix. But at this point I wouldn't be 
surprised to see retention of 0377 support be demanded by 
CoffeeScript/Node.js users, and they have a point.

CoffeeScript can certainly compile this to a strict hex or decimal 
literal to dodge the error, but then JS/Node.js is at a loss, and for no 
good reason. In this case I will argue for supporting octal literals in 
strict mode.

/be



More information about the es-discuss mailing list