5 ms·

You don't see an issue with needing to write and maintain a verification script for something that is essentially a solved problem? Why add more development run

by vageli 8y ago

You don't see an issue with needing to write and maintain a verification script for something that is essentially a solved problem? Why add more development runtime overhead? What do string-based flags get you that bit-based don't?

protomyth 8y ago
Nope, I really don't. I don't fear strings in code because I have to run verification scripts on whatever config format we end up using or you get stuff like [1]. Its just another part of the compile process once setup, and their reasoning was sound[2], so why stress. Heck, the script isn't even complicated. Now, at a language level, would I like the C committee to start looking at some of these things? Yes, but why bother hoping for miracles. 1) https://www.engadget.com/2018/07/13/aliens-colonial-marines-typo-ai/ https://www.engadget.com/2018/07/13/aliens-colonial-marines-... 2) https://www.tedunangst.com/flak/post/string-interfaces https://www.tedunangst.com/flak/post/string-interfaces
- fbender 8y ago
  If I’m not mistaken, you can even have the best of both worlds in languages with proper macro support (I’m sure you know which lang I‘m talking about): The Macro call can take the string input and „desugar“ it into bitmasks / function calls / whatever you need at compile time. Then you have: 1) easily readable, string-like input; 2) built-in-your-code verification and 3) compile-time check; 4) zero-overhead execution. Just reading Ted‘s blog post gave me an idea how lang-specific libraries / (thin-layer) abstractions (or simply additional magic helper functionality) can improve upon legacy API designs (e.g. the GLX example) by using lang-specific functionality I never knew I‘d need or even cared about. Sometimes one can learn when you‘d never expect it. :D Unless I‘m mistaken and misunderstood the whole thing, please correct me in that case.
  - protomyth 8y ago
    I think the issue is that for most languages you have to update the libraries with the new constants for bit-wise operations and not for the string approach. Some languages would be fine, but this is multi-language in the end.
temprature 8y ago
Removes the need to add a separate include for namespacing, ie. no pledge.h header needed. Makes the calls shorter and easier to read. Consider: if (pledge("stdio rpath tmppath proc exec", NULL) == -1) err(1, "pledge"); vs. if (pledge(PLEDGE_STDIO | PLEDGE_RPATH | PLEDGE_TMPPATH | PLEDGE_PROC | PLEDGE_EXEC, NULL) == -1) err(1, "pledge"); Makes it easier to add a pledge interface to other languages with having to keep chasing bit flag changes, ie. there's been several new promises add since 2015 but the OpenBSD::Pledge perl module hasn't needed to change. And really, unless you're using pledge wrong, ie. by using it outside of the startup path and/or not checking the return value, what does compile-time checking get you?

by vageli 8y ago

protomyth 8y ago

Nope, I really don't. I don't fear strings in code because I have to run verification scripts on whatever config format we end up using or you get stuff like [1]. Its just another part of the compile process once setup, and their reasoning was sound[2], so why stress. Heck, the script isn't even complicated. Now, at a language level, would I like the C committee to start looking at some of these things? Yes, but why bother hoping for miracles. 1) https://www.engadget.com/2018/07/13/aliens-colonial-marines-typo-ai/ https://www.engadget.com/2018/07/13/aliens-colonial-marines-... 2) https://www.tedunangst.com/flak/post/string-interfaces https://www.tedunangst.com/flak/post/string-interfaces

fbender 8y ago
If I’m not mistaken, you can even have the best of both worlds in languages with proper macro support (I’m sure you know which lang I‘m talking about): The Macro call can take the string input and „desugar“ it into bitmasks / function calls / whatever you need at compile time. Then you have: 1) easily readable, string-like input; 2) built-in-your-code verification and 3) compile-time check; 4) zero-overhead execution. Just reading Ted‘s blog post gave me an idea how lang-specific libraries / (thin-layer) abstractions (or simply additional magic helper functionality) can improve upon legacy API designs (e.g. the GLX example) by using lang-specific functionality I never knew I‘d need or even cared about. Sometimes one can learn when you‘d never expect it. :D Unless I‘m mistaken and misunderstood the whole thing, please correct me in that case.
- protomyth 8y ago
  I think the issue is that for most languages you have to update the libraries with the new constants for bit-wise operations and not for the string approach. Some languages would be fine, but this is multi-language in the end.

temprature 8y ago

Removes the need to add a separate include for namespacing, ie. no pledge.h header needed. Makes the calls shorter and easier to read. Consider: if (pledge("stdio rpath tmppath proc exec", NULL) == -1) err(1, "pledge"); vs. if (pledge(PLEDGE_STDIO | PLEDGE_RPATH | PLEDGE_TMPPATH | PLEDGE_PROC | PLEDGE_EXEC, NULL) == -1) err(1, "pledge"); Makes it easier to add a pledge interface to other languages with having to keep chasing bit flag changes, ie. there's been several new promises add since 2015 but the OpenBSD::Pledge perl module hasn't needed to change. And really, unless you're using pledge wrong, ie. by using it outside of the startup path and/or not checking the return value, what does compile-time checking get you?