211–220 of 322 posts
Earlier quoted context omitted.
Never had this happen, this is largely eliminated by using tools like black or other autoformatters.
The point still stands that this is an inherit possibility in the language it self.
Earlier quoted context omitted.
> Well, there's also the opposite: Goldman Sachs's Slang allows space as part of identifiers. Many SQL implementations permit whitespace in identifiers, but then you need to use quoted identifiers.
That's reasonably sane of SQL. In Slang, you don't need to quote. (The syntax is still unambiguous. In principle, eg Python could do something similar, because they don't have any existing syntax where you just put two identifiers next to each other with only a space in between. But C could not, because variable declaration is just two identifiers, one for the type and one for the variable name, next to each other wi…
> eg Python could do something similar, because they don't have any existing syntax where you just put two identifiers next to each other with only a space in between
The interaction with keywords would cause some issues. For example, right now, “if” is not a valid identifier (keyword), but “if_” and “_if” are. However, with this proposal “x y” could be a valid identifier, but “x if” would introduce ambiguity
> But C could not, because variable declaration is just two identifiers, one for the type and one for the variable name, next to each other with a space in between
This is one aspect of C syntax I have never liked. I always wish it had been Pascal-style `x:int;` instead of `int x;`
I can't believe that system security is dependent on such a loose chain of correctness. Any number of things could have stopped this. + # A compile check is done here because some systems have + # linux/landlock.h, but do not have the syscalls defined + # in order to actually use Linux Landlock. Fix those headers on those systems to explicitly opt-out. What's the point of headers if they don't declare their capabilit…
Since users could be trying to compile it on GCC 9.4.0, and as the functionality dependent on the header isn't critical to the application, if the build detects the header is broken, it just disables the functionality and emits a warning.
Back to xz: If security isn't your top priority, it seems reasonable to just ignore the failure of an optional feature and just move along. Of course, in hindsight, it's easy to point fingers, but without that, it doesn't sound completely unreasonable to me.
Earlier quoted context omitted.
Isn’t it a bit ironic with how much code everyone depends on that can freely be altered by some unknown party, while so much time goes into code reviews to verify internal changes at most companies.
> while so much time goes into code reviews to verify internal changes at most companies Very easy claim to make. Difficult to verify.
Earlier quoted context omitted.
Even more evil would have been to replace this line (void)SYS_landlock_create_ruleset; with this: (void)SYS_landloсk_create_ruleset;
Putting random Unicode confusables in source code would be far easier to consider malicious
Earlier quoted context omitted.
For those squinting, the "landlock" regular "c" is replaced with a Cyrillic U+0441.
Is there a GCC option to error on non-standard English characters?
Earlier quoted context omitted.
Perhaps, but given how most build systems work, that would complicate things in other ways (since build systems often try to compile all .c files).
I am a CMake novice. Is that true for CMake in this example?
Earlier quoted context omitted.
Fails the build, so that Landlock support is never enabled.
I don't think it fails the build. It's part of a test, trying to compile a bit of code. If it compiles the test is true and a certain feature is enabled. If the compilation fails the the feature is disabled. This is quite common in build systems. I had such a test produce incorrect results in the kernel build system recently. The problem is that the tests should really look carefully for an expected error message. If…
Earlier quoted context omitted.
configure would print that it's not enabled, so it seems like the kind of thing people would eventually notice.
Maybe, eventually, but how many people read the reams of garbage autoconf spouts out until the feature they wanted fails to materialize?