Sorry to disappoint, but the compilers for nearly 100% of the server, desktop, and mobile computers in the real world do not allow arbitrary pointer arithmetic. They cannot issue an error message for it because that is provably impossible to detect in the general case, but they do optimise on the basis that it does not happen, even if it breaks programs that try to make use of it. Consider this example for GCC:
int a[2], b[2];
int offset(void) { return b - a; }
int check(void) { return &a[1] + offset() == &b[1]; }
The function check() is optimised by GCC to return zero at -O1 optimisation level or higher, because it reasons that no matter how offset() is implemented, either the addition is undefined, or the comparison results in false.
(Note that GCC does this even in a few cases where it is unclear whether the optimisation is valid. The example I provided is slightly more complicated than I would have liked to avoid that issue; the optimisation is definitely valid in this example.)
> With the right hackish arithmetic, all pointers could be aliased with pointer arithmetic in C.
This is not true. The behaviour is undefined in C if pointer arithmetic results in crossing the beginning or end of an object. If we have int a, b;, then the behaviour is undefined if we do &b - &a even if we never use the result to try to reconstruct &b from &a.
> Using `restrict` says your code won't do that so the compiler can optimize more.
`restrict` covers objects modified through one pointer and accessed through another. It does not cover pointers that point to the same object in general; if only one is used to access the object, or if both are used only for reading, all is fine. (It's actually a little bit more complicated than I'm presenting here, but not in a way that's relevant right now.)
A practical consequence (not necessarily the only consequence) would be for the people who starred it who use stars as a bookmark feature: they have now lost their bookmark.
And since the article is using podman as an example: podman does have a manpage. The actual standard way of getting documentation on utilities, man podman, works just fine.
I did not last even two paragraphs: I clicked through on "Ubuntu MATE cannot be trusted" and found something better summarised as "I tried getting away with calling people idiots on Ubuntu MATE forums in a bizarre social experiment and cannot deal with them not putting up with that."
The temporary file should be created in such a way that other users cannot modify it. If that does not happen, if other users can modify it, I would regard that as a bug.
Malicious processes running as the same user could potentially modify the file, but if you have malicious processes running as a user with sudo privileges you have probably already lost.
The documentation does call it out explicitly. The message you responded to pointed out where the documentation called it out. You're attacking the authors' intentions and competence when there is no reason for that.
sudo $EDITOR launches the editor itself as root, sudo -e launches the editor as a regular user on a temporary copy of the original file, and copies the contents back over to the original file when you are done. The less done as root, the less opportunity to mess things up.
We know that b and c both happen after a, and that d happens after c. However, we do not know whether b happens before c, between c and d, or after d. Your a.out process will only get killed by SIGPIPE if it happens after d.
On my system, running a.out under strace is enough to slow it down enough to affect the timing and see the SIGPIPE you were expecting. You may alternatively insert artificial delays in your test program such as by calling the sleep() function between the two lines of output to see the same result.
That's a POSIX thing. It doesn't apply to all C implementations but it does apply to many more than just Linux-based ones. You've not got a closed pipe so you wouldn't see it, you've just got a closed file descriptor. Try running it as
./a.out | :
and you will probably see it. I say probably because there is a timing aspect as well, the write may happen before the pipe gets closed in which case it will not fail, but it is unlikely to.
> This isn't just about the filesystem being full btw. If you imagine a command like ./foo.py | head -n 10, it only makes sense for the 'head' command to close the pipe when it's done, and foo.py should be able to detect this and stop printing any more output.
The usual way of handling this is by not (explicitly) handling it. Writes to a closed pipe are special, they do not normally fail with a status that the program then all too often ignores, they result in a SIGPIPE signal that defaults to killing the process. Extra steps are needed to not kill the process. No other kind of write error gets this special treatment that I am aware of.
Yeah, that's a good point. There is a chance it is simply not a possibility in the way their systems are currently set up, but if so, that's on Google and they should change their systems to make it possible.
Are you overreacting? In my opinion, depending on how long the suspension lasts, you may be, though not necessarily. You sent unsolicited bulk e-mail. That is spam. It is possible that your mail helped some people, but anyone who had set up their own filtering to prevent the original mail from coming through would then only see it because of your followup, and additionally the "To" list may well have been spoofed as well and not reflect who the original mail was actually sent to. Google have a responsibility to prevent spam from being sent through their systems, and if this suspension is the minimal they can do to stop your spam, it was the right thing for Google to do, and you would see the same with a lot of other e-mail providers as well. However, if this suspension lasts beyond the point where you are clearly aware of it and can make sure you do not repeat that, then no, as far as I am concerned you will no longer be overreacting and should look to avoid Google in the future.
It's all fun until you get something like FIGHT where the last four letters are right and have to just guess from LIGHT, MIGHT, RIGHT, SIGHT, TIGHT, WIGHT, anything I might have missed, and there's no way to use any strategy and you just have to randomly guess and hope you guess right.
I assume and hope that they do not, if there is no rule stating that they are invalid. There are valid reasons for JSON to massive keys. A simple one: depending on the programming language and libraries used, an unordered array ["a","b","c"] might be better mapped as a dictionary {"a":1,"b":1,"c":1}. Now all of your keys are semantically values, and any limit imposed on keys only makes sense if the same limit is also imposed on values.
The post mentions from_chars specifically, and the quote about the range is about that function. That means we need to ask the question whether NaN is "in the range representable by the type of value" too. For most other functions I would agree with you as NaN would be called out as a special case, and we have a meaningful range for all non-NaN values, but for from_chars I do not think "semantically important ranges" gets us there.
let mut file = File::create("valuable_data.txt").unwrap();
file.write_all(b"important message").expect("failed to write message");
The use of .expect("Could not read file") is consistent with Rust's documentation.
And I agree with OP that .expect() is poorly named. I wouldn't raise it as an issue on the work of others who just use Rust and are stuck with it though.
> This departs from the policy of the user [private], from which noDRM has forked the repository DeDRM_tools. The user [private] does not provide circumvention material for the LCP solution, therefore it is not part of our request for takedown.
A typo in a list of tests to skip means tests are run that are not intended to be run. This can lead to unexpected failures, so in my opinion is not the same as the errors in test suites where tests run with other test data than intended but should still pass.
Beware that PATH being unset or empty is a special case and does not necessarily mean that no directories are searched. Different shells handle it differently, and other utilities spawned by the shells handle it themselves in a way that may or may not match the shell. Whether setting PATH to $dir if it was previously unset or empty is the right thing to do is therefore a matter of opinion. Personally, I would stay out of that mess and either issue an error or leave PATH unmodified.
That's what the extra :s in ":$PATH:" are for: they prepend and append an empty component to the list. Any component in the original "$PATH" will still be in ":$PATH:" too, but no longer be at the end or the beginning, allowing the pattern to be simplified.
You showed a screenshot earlier, I know what they look like for you. :) I don't override the font either. HN specifies a CSS font family "Verdana, Geneva, sans-serif", where Verdana is installed by default on Windows but is not a full sans-serif font, so it's a somewhat odd choice by HN. As for the English alphabet, I didn't say there was a problem with it, just that you cannot reliably tell just from looking at letters which letters they are. In practice it is not an issue.