I meant exactly what the parent-comment pointed out - that C can't be parsed without a symbol table. Like the example on wikipedia:
A * B;
Which either represents a multiplication or a pointer of type A* to B, depending what the symbol table looks like. That means parsing C is impossible without these hacks, and you need to basically parse the whole file to build up this information.
A lot text editors which only support grammars can't parse this properly, there are a ton of buggy C parsers in the wild.
The issues that led to this were completely avoidable, and many languages like Pascal (which was more or less its contemporary), Go or Rust did avoid them. They don't lead to the language being more powerful or expressive.
Calling it the 'worst' might be hyperbole, but given how influential C-style syntax has become, and how much C code is out there, these issue have affected a ton of other languages downstream.
I'm not sure I understand this article, but the argument you present seems to be that when considering P and NP as relational objects, they don't have the same signature, thus cannot be compared, so the statement "P = NP" is meaningless?
You should probably have linked the whole work which is briefly referenced at the end of the article, and isn't yet indexed by search engines. I found it by myself:
Is each branch-free run of instructions an object (which in general will be smaller than "function" or "method" objects) that can be abstracted? How does one manage locality ("these objects are the text of this function")?
Maybe one compromises and treats the text of a function as linear address space with small relative offsets. Of course, other issues will crop up. You can't treat code as an array, unless it's an array of the smallest word (bytes, say) even if the instructions are variable length. How do you construct all the pointer+capability values for the program's text statically? The linker would have to be able to do that...
Isn't a virtual ISA like an intermediate representation? It doesn't have to include static addresses, only symbolic references, which could be resolved at launch time.
Another thing is that array addressing is tricky. You need to support arrays, but then how do you construct pointers to individual elements of the arrays? The cleanest option is to not allow that and force the programmer to always pass around the pointer to the array and an index. The same applies to slices. This definitely makes life harder for porting existing codebases or making existing languages work.
This is probably the worst possible way to implement a processor.
Instead of just bumping the instruction pointer by one or an offset, you now need to have code labels in your processor and a way to efficiently look them up.
goto "exit" means the processor needs to have a lookup table of all the possible nodes in the computational graph. Calling a function requires a global look up table.
How is that table implemented? Obviously you can't just have an array of code labels, because using a linear data structure would kind of defeat the point.
Instead you need to build hardware that can store a graph and its edges directly and each hardware unit also has a label matcher so you can load a particular node and its edges.
This seems like an absurd amount of effort for moving from one instruction to the next. You know, something that could have been done by doing a single IP+1 or IP+jump_offset.
See my sibling comment. Basically each text fragment (either each branch-free run of instructions or each function/method) would need to be an object w/ capability, and the linker-loader must arrange for all text references to have the correct pointers. And then it would work. It's just a complication of the linker-loader, but once a program is loaded there would be no further lookups (unless you use something like `dlsym()`). The compromise to make is that within each such text object you have linear addressing with small offsets.
What I meant, and indeed it was poorly explained, is that an address shouldn't be just an integer freely manipulable by any instruction. The microcode will obviously know how to an manipulate an address, but the ISA as a whole doesn't have to, and in fact shouldn't, with the exception of a few specific instructions. What I am advocating is that addresses should constitute a separate type, which isn't a simple alias to integers. I think that this is what capabilities are about.
> The problem with that argument is that the reports don’t necessarily come from the organization for whom it’s an issue.
You can already say that for the majority of the bugs being fixed, and I think that's one of the points: tagging certain bugs as exploitable make it seem like the others aren't.
More generally, someone's minor issue might be a major one for someone else, and not just in security. It could be anything the user cares about, data, hardware, energy, time.
Perhaps the real problem is that security is just a view on the bigger picture. Security is important, I'm not saying the opposite, but if it's only an aspect of development, why focus on it in the development logs? Shouldn't it be instead discussed on its own, in separate documents, mailing lists, etc by those who are primarily concerned by it?
Are memory leak fixes described as memory leak fixes in the logs or intentionally omitted as such? Are kernel panics or hangs not described in the commit logs even if they only happen in weird scenarios? Thats clearly not what’s happening meaning security bugs are still differently recorded and described through omission.
However you look at it, the only real justification that’s consistent with observed behaviors is that pointing out security vulnerabilities in the development log helps attackers. That explains why known exploitable bugs are reported differently before hand and described differently after the fact in the commit logs. That wouldn’t happen if “a bug is a bug” was actually a genuinely held position.
> However you look at it, the only real justification that’s consistent with observed behaviors is that pointing out security vulnerabilities in the development log helps attackers.
And on top of your other concerns, this quoted bit smells an awful lot like 'security through obscurity' to me.
The people we really need to worry about today, state actors, have plenty of manpower available to watch every commit going into the kernel and figure out which ones are correcting an exploitable flaw, and how; and they also have the resources to move quickly to take advantage of them before downstream distros finish their testing and integration of upstream changes into their kernels, and before responsible organizations finish their regression testing and let the kernel updates into their deployments -- especially given that the distro maintainers and sysadmins aren't going to be moving with any urgency to get a kernel containing a security-critical fix rolled out quickly because they don't know they need to because *nobody's warned them*.
Obscuring how fixes are impactful to security isn't a step to avoid helping the bad guys, because they don't need the help. Being loud and clear about them is to help the good guys; to allow them to fast-track (or even skip) testing and deploying fixes or to take more immediate mitigations like disabling vulnerable features pending tested fix rollouts.
There are channels in place to discuss security matters in open source. I am by no mean an expert nor very interested in that topic, but just searching a bit led me to
There’s lot of different kinds of bad guys. This probably has marginal impact on state actors. But organized crime or malicious individuals? Probably raises the bar a little bit and part of defense in depth is employing a collection of mitigations to increase the cost of creating an exploit.
> Are memory leak fixes described as memory leak fixes in the logs or intentionally omitted as such? Are kernel panics or hangs not described in the commit logs even if they only happen in weird scenarios?
I don't know nor follow kernel development well enough to answer these questions. My point was just a general reflection, and admittedly a reformulation of Linus's argument, which I think is genuinely valid.
If you allow me, one could frame this differently though: is the memory leak the symptom or the problem?
Indeed nobody does that, because it would just be pointless, it doesn't expose the real issue. Is a security vulnerability a symptom, or the real issue though? Doesn't it depends on the purpose of the code containing the bug?
That is a somewhat broad claim that needs decomposing. I would agree that Chinese EV industry is quite more advanced in terms of manufacturing processes and cost optimization, but that is not "technically" more advanced per se, its just a reflection of a culture. Maybe the salt batteries will be a breakthrough, but at least for me it has been difficult finding reliable data on it; Other than that, afaik (and from a layman perspective) there isn't anything inherently superior in chinese EV vehicles from a technological perspective, when compared to western counterparts. Cheaper, yes. But thats about it.
I think ungrouping make sense if you consider reverse parentheses as a syntactic construct added to the language, and not replacing the existing parentheses.
For instance, using "] e [" as the notation for reverse parentheses around expression e, the second line showing reverse parenthese simplification, third line showing the
grouping after parsing, and the fourth line using postfix notation:
A + B * (C + D) * (E + F)
=> A + B * (C + D) * (E + F)
=> (A + (B * (C + D) * (E + F)))
=> A B C D + E F + * * +
A + ] B * (C + D) [ * (E + F)
=> A + B * C + D * (E + F)
=> ((A + (B * C)) + (D * (E + F)))
=> A B C * + D E F * + +
So what ungrouping would mean is to undo the grouping done by regular parentheses.
However, this is not what is proposed later in the article.
Possibilities include reversing the priority inside the reverse parentheses, or lowering the priority wrt the rest of the expression.
reply