<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: genrilz</title><link>https://news.ycombinator.com/user?id=genrilz</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Mon, 01 Jun 2026 20:09:12 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=genrilz" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by genrilz in "The case against social media is stronger than you think"]]></title><description><![CDATA[
<p>There is plenty of research on social media outcomes. I've looked through some of it before by just searching semanticscholar.org, and the general consensus is that it has both positive and negative effects.<p>I don't want to have to do a literature review again, and sharing papers is hard because they are often paywalled unless you are associated with a university or are willing to pirate them.<p>Luckily, The American Psychological Association [0] has shared this nice health advisory [1] which goes into detail. The APA has stewarded psychology research and communicated it to the public in the US for a long time. They have a good track record.<p>[0]: <a href="https://en.wikipedia.org/wiki/American_Psychological_Association" rel="nofollow">https://en.wikipedia.org/wiki/American_Psychological_Associa...</a><p>[1]: <a href="https://www.apa.org/topics/social-media-internet/health-advisory-adolescent-social-media-use" rel="nofollow">https://www.apa.org/topics/social-media-internet/health-advi...</a></p>
]]></description><pubDate>Sun, 14 Sep 2025 18:23:24 +0000</pubDate><link>https://news.ycombinator.com/item?id=45242071</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=45242071</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45242071</guid></item><item><title><![CDATA[New comment by genrilz in "PuTTY has a new website"]]></title><description><![CDATA[
<p>One non-obvious strategy is that the number of mines that are left on the field is known. Especially near the end, this can break a tie between two patterns of mines.</p>
]]></description><pubDate>Sat, 16 Aug 2025 22:03:26 +0000</pubDate><link>https://news.ycombinator.com/item?id=44927240</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=44927240</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44927240</guid></item><item><title><![CDATA[New comment by genrilz in "Building the Rust Compiler with GCC"]]></title><description><![CDATA[
<p>> IRC the plan isn't to use Polonius instead of NLL, but rather use NLL and kick off Polonius for certain failure cases.<p>Indeed. Based on the last comment on the tracking issue [0], it looks like they have not figured out whether they will be able to optimize Polonius enough before stabilization, or if they will try non-lexical lifetimes first.<p>[0]: <a href="https://github.com/rust-lang/rust-project-goals/issues/118">https://github.com/rust-lang/rust-project-goals/issues/118</a></p>
]]></description><pubDate>Mon, 07 Jul 2025 17:00:07 +0000</pubDate><link>https://news.ycombinator.com/item?id=44492327</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=44492327</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44492327</guid></item><item><title><![CDATA[New comment by genrilz in "Building the Rust Compiler with GCC"]]></title><description><![CDATA[
<p>There isn't a formal definition of how the borrow checking algorithm works, but if anyone is interested, [0] is a fairly detailed if not mathematically rigorous description of how the current non-lexical lifetime algorithm works.<p>The upcoming Polonius borrow checking algorithm was prototyped using Datalog, which is a logical programming language. So the source code of the prototype [1] effectively is a formal definition. However, I don't think that the version which is in the compiler now exactly matches this early prototype.<p>EDIT: to be clear, there is a polonius implementation in the rust compiler, but you need to use '-Zpolonius=next' flag on a nightly rust compiler to access it.<p>[0]: <a href="https://rust-lang.github.io/rfcs/2094-nll.html" rel="nofollow">https://rust-lang.github.io/rfcs/2094-nll.html</a><p>[1]: <a href="https://github.com/rust-lang/polonius/tree/master">https://github.com/rust-lang/polonius/tree/master</a></p>
]]></description><pubDate>Mon, 07 Jul 2025 13:05:33 +0000</pubDate><link>https://news.ycombinator.com/item?id=44489984</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=44489984</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44489984</guid></item><item><title><![CDATA[New comment by genrilz in "Matt Godbolt sold me on Rust by showing me C++"]]></title><description><![CDATA[
<p>Actually, the x86 'ADD' instruction automagically sets the 'OF' and 'CF' flags for you for signed and unsigned overflow respectively [0]. So all you need to do to panic would be to follow that with an 'JO' or 'JB' instruction to the panic handling code. This is about as efficient as you could ask for, but a large sequence of arithmetic operations is still going to gum up the branch predictor, resulting in more pipeline stalls.<p>[0]: <a href="https://www.felixcloutier.com/x86/add" rel="nofollow">https://www.felixcloutier.com/x86/add</a></p>
]]></description><pubDate>Wed, 07 May 2025 21:17:26 +0000</pubDate><link>https://news.ycombinator.com/item?id=43920644</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=43920644</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43920644</guid></item><item><title><![CDATA[New comment by genrilz in "Matt Godbolt sold me on Rust by showing me C++"]]></title><description><![CDATA[
<p>The reason '+ 1' is fine in the example you gave is that length is always less than or equal to capacity. If you follow 'grow_one' which was earlier in the function to grow the capacity by one if needed, you will find that it leads to the checked addition in [0], which returns an error that [1] catches and turns into a panic. So using '+1' prevents a redundant check in release mode while still adding the check in debug mode in case future code changes break the 'len <= capacity' invariant.<p>Of course, if you don't trust the standard library, you can turn on overflow checks in release mode too. However, the standard library is well tested and I think most people would appreciate the speed from eliding redundant checks.<p><pre><code>  [0]: https://doc.rust-lang.org/src/alloc/raw_vec.rs.html#651
  [1]: https://doc.rust-lang.org/src/alloc/raw_vec.rs.html#567</code></pre></p>
]]></description><pubDate>Wed, 07 May 2025 16:14:29 +0000</pubDate><link>https://news.ycombinator.com/item?id=43917535</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=43917535</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43917535</guid></item><item><title><![CDATA[New comment by genrilz in "Matt Godbolt sold me on Rust by showing me C++"]]></title><description><![CDATA[
<p>The point I'm sure was to prevent the checks from incurring runtime overhead in production. Even in release mode, the overflow will only wrap rather than trigger undefined behavior, so this won't cause memory corruption unless you are writing unsafe code that ignores the possibility of overflow.<p>The checks being on in the debug config means your tests and replications of bug reports will catch overflow if they occur. If you are working on some sensitive application where you can't afford logic bugs from overflows but can afford panics/crashes, you can just turn on checks in release mode.<p>If you are working on a library which is meant to do something sensible on overflow, you can use the wide variety of member functions such as 'wrapping_add' or 'checked_add' to control what happens on overflow regardless of build configuration.<p>Finally, if your application can't afford to have logic bugs from overflows and also can't panic, you can use kani [0] to prove that overflow never happens.<p>All in all, it seems to me like Rust supports a wide variety of use cases pretty nicely.<p>[0]: <a href="https://github.com/model-checking/kani">https://github.com/model-checking/kani</a></p>
]]></description><pubDate>Wed, 07 May 2025 14:16:35 +0000</pubDate><link>https://news.ycombinator.com/item?id=43916003</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=43916003</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43916003</guid></item><item><title><![CDATA[New comment by genrilz in "Matt Godbolt sold me on Rust by showing me C++"]]></title><description><![CDATA[
<p>If you obscure the implementation a bit, you can change GP's example to a runtime overflow [0]. Note that by default the checks will only occur when using the unoptimized development profile. If you want your optimized release build to also have checks, you can put 'overflow-checks = true' in the '[profile.release]' section of your cargo.toml file [1].<p><pre><code>  [0]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=847dc401e16fdff14ecf3724a3b15a93
  [1]: https://doc.rust-lang.org/cargo/reference/profiles.html</code></pre></p>
]]></description><pubDate>Tue, 06 May 2025 21:15:11 +0000</pubDate><link>https://news.ycombinator.com/item?id=43909733</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=43909733</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43909733</guid></item><item><title><![CDATA[New comment by genrilz in "Understanding Memory Management, Part 5: Fighting with Rust"]]></title><description><![CDATA[
<p>I think it is important to note that in 59nadir's example, the reason Rust gives an error and Odin doesn't is not memory safety. Rust uses move semantics by default in a loop while Odin appears to use copy semantics by default. I don't really know Odin, but it seems like it is a language that doesn't have RAII. In which case, copy semantics are fine for Odin, but in Rust they could result in a lot of extra allocations if your vector was holding RAII heap allocating objects. Obviously that means you would need to be careful about how to use pointers in Odin, but the choice of moving or copying by default for a loop has nothing to do with this. For reference:<p>Odin (from documentation):<p><pre><code>  for x in some_array { // copy semantics
  for &x in some_array { // reference semantics
  // no move semantics? (could be wrong on this)
</code></pre>
Rust:<p><pre><code>  for x in vec.iter_ref().copied() { // bytewise copy semantics (only for POD types)
  for x in vec.iter_ref().cloned() { // RAII copy semantics
  for x in &vec { // reference semantics
  for x in vec { // move semantics
</code></pre>
C++:<p><pre><code>  for (auto x : vec) { // copy semantics
  for (auto &x : vec) { // reference semantics
  for (auto &&x : vec) { // move semantics</code></pre></p>
]]></description><pubDate>Tue, 06 May 2025 13:42:26 +0000</pubDate><link>https://news.ycombinator.com/item?id=43905023</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=43905023</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43905023</guid></item><item><title><![CDATA[New comment by genrilz in "Understanding Memory Management, Part 5: Fighting with Rust"]]></title><description><![CDATA[
<p>I think 0xdeafbeef is roughly recreating the first code snippet from the article (which is one of the things diath is complaining about) in C++ to show that the compiler <i>should</i> produce an error or else undefined behavior could occur on resize.</p>
]]></description><pubDate>Tue, 06 May 2025 12:09:06 +0000</pubDate><link>https://news.ycombinator.com/item?id=43904164</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=43904164</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43904164</guid></item><item><title><![CDATA[New comment by genrilz in "Expanding on what we missed with sycophancy"]]></title><description><![CDATA[
<p>We get into a bit of a weird space though when they know your opinions about them. I'm sure there are quite a few people who can only build a billion dollar startup if someone emotionally supports them in that endeavor. I'm sure more people could build such a startup if those around them provide knowledge or financial support. In the limit, pretty much anyone can build a billion dollar startup if handed a billion dollars. Are these people capable or not capable of building a building a billion dollar startup.<p>EDIT: To be clear, I somehow doubt an LLM would be able to provide the level of support needed in most scenarios. However, you and others around the potential founder might make the difference. Since your assessment of the person likely influences the level of support you provide to them, your assessment can affect the chances of whether or not they successfully build a billion dollar startup.</p>
]]></description><pubDate>Sat, 03 May 2025 11:14:54 +0000</pubDate><link>https://news.ycombinator.com/item?id=43878291</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=43878291</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43878291</guid></item><item><title><![CDATA[New comment by genrilz in "Pitfalls of Safe Rust"]]></title><description><![CDATA[
<p>EDIT: A summary of this is that it is impossible to write a sound std::Vec implementation if NonZero::new_unchecked is a safe function. This is specifically because creating a value of NonZero which is 0 is undefined behavior which is exploited by niche optimization. If you created your own `struct MyNonZero(u8)`, then you wouldn't need to mark MyNonZero::new_unchecked as unsafe because creating MyNonZero(0) is a "valid" value which doesn't trigger undefined behavior.<p>The issue is that this could potentially allow creating a struct whose invariants are broken in safe rust. This breaks encapsulation, which means modules which use unsafe code (like `std::vec`) have no way to stop safe code from calling them with the invariants they rely on for safety broken. Let me give an example starting with an enum definition:<p><pre><code>  // Assume std::vec has this definition
  struct Vec<T> {
    capacity: usize,
    length:   usize,
    arena:    * T
  }
  
  enum Example {
    First {
      capacity: usize,
      length:   usize,
      arena:    usize,
      discriminator: NonZero<u8>
    },
    Second {
      vec: Vec<u8>
    }
  }
</code></pre>
Now assume the compiler has used niche optimization so that if the byte corresponding to `discriminator` is 0, then the enum is `Example::Second`, while if the byte corresponding to `discriminator` is not 0, then the enum is `Example::First` with discriminator being equal to its given non-zero value. Furthermore, assume that `Example::First`'s `capacity`, `length`, and `arena` fields are in the in the same position as the fields of the same name for `Example::Second.vec`. If we allow `fn NonZero::new_unchecked(u8) -> NonZero<u8>` to be a safe function, we can create an invalid Vec:<p><pre><code>  fn main() {
    let evil = NonZero::new_unchecked(0);
  
    // We write as an Example::First,
    // but this is read as an Example::Second
    // because discriminator == 0 and niche optimization
    let first = Example::First {
      capacity: 9001, length: 9001,
      arena: 0x20202020,
      discriminator: evil
    }

    if let Example::Second{ vec: bad_vec } = first {
      // If the layout of Example is as I described,
      // and no optimizations occur, we should end up in here.

      // This writes 255 to address 0x20202020
      bad_vec[0] = 255;
    }
  }
</code></pre>
So if we allowed new_unchecked to be safe, then it would be impossible to write a sound definition of Vec.</p>
]]></description><pubDate>Mon, 07 Apr 2025 00:36:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=43606286</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=43606286</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43606286</guid></item><item><title><![CDATA[New comment by genrilz in "Tracing the thoughts of a large language model"]]></title><description><![CDATA[
<p>I realize I'm butting in on an old debate, but thinking about this caused me to come to conclusions which were interesting enough that I had to write them down somewhere.<p>I'd argue that rather than thoughts containing extra contents which don't exist in brain states, its more the case that brain states contain extra content which doesn't exist in thoughts. Specifically, I think that "thoughts" are a lossy abstraction that we use to reason about brain states and their resulting behaviors, since we can't directly observe brain states and reasoning about them would be very computationally intensive.<p>As far as I've seen, you have argued that thoughts "refer" to real things, and that thoughts can be "correct" or "incorrect" in some objective sense. I'll argue against the existence of a singular coherent concept of "referring", and also that thoughts can be useful without needing to be "correct" in some sense which brain states cannot participate in. I'll be assuming that something only exists if we can (at least in theory if not in practice) tie it back to observable behavior.<p>First, I'll argue that the "refers" relation is a pretty incoherent concept which sometimes happens to work. Let us think of a particular person who has a thought/brain state about a particular tiger in mind/brain. If the person has accurate enough information about the tiger, then they will recognize the tiger on sight, and may behave differently around that tiger than other tigers. I would say in this case that the person's thoughts refer to the tiger. This is the happy case where the "refers" relation is a useful aid to predicting other people's behavior.<p>Now let us say that the person believes that the tiger ate their mother, and that the tiger has distinctive red stripes. However, let it be the case that the person's mother was eaten by a tiger, but that tiger did not have red stripes. Separately, there does exist a singular tiger in the world which does have red stripes. Which tiger does the thought "a tiger with red stripes ate my mother" refer to?<p>I think it's obvious that this thought doesn't coherently refer to any tiger. However, that doesn't prevent the thought from affecting the person's behavior. Perhaps the person's next thought is to "take revenge on the tiger that killed my mother". The person then hunts down and kills the tiger with the red stripes. We might be tempted to believe that this thought refers to the mother killing tiger, but the person has acted as though it referred to the red striped tiger. However, it would be difficult to say that the thought refers to the red striped tiger either, since the person might not kill the red striped tiger if they happen to learn said tiger has an alibi. Hopefully this is sufficient to show that the "refers" relationship isn't particularly connected to observable behavior in many cases where it seems like it should be. The connection would exist if everyone had accurate and complete information about everything, but that is certainly not the world we live in.<p>I can't prove that the world is fully mechanical, but if we assume that it is, then all of the above behavior could in theory be predicted by just knowing the state of the world (including brain states but not thoughts) and stepping a simulation forward. Thus the concept of a brain state is more helpful to predicting their behavior than thoughts with a singular concept of "refers". We might be able to split the concept of "referring" up into other concepts for greater predictive accuracy, but I don't see how this accuracy could ever be greater than just knowing the brain state. Thus if we could directly observe brain states and had unlimited computational power, we probably wouldn't bother with the concept of a "thought".<p>Now then, on to the subject of correctness. I'd argue that thoughts can be useful without needing a central concept of correctness. The mechanism is the very category theory like concept of considering all things only in terms of how they relate to other things, and then finding other (possibly abstract) objects which have the same set of relationships.<p>For concreteness, let us say that we have piles of apples and are trying to figure out how many people we can feed. Let us say that today we have two piles each consisting of two apples. Yesterday we had a pile of four apples and could feed two people. The field of appleology is quite new, so we might want to find some abstract objects in the field of math which have the same relationship. Cutting edge appleology research shows that as far as hungry people are concerned, apple piles can be represented with natural numbers, and taking two apple piles and combining them results in a pile equivalent to adding the natural numbers associated with the piles being combined. We are short on time, so rather than combining the piles, we just think about the associated natural numbers (2 and 2), and add them (4) to figure out that we can feed two people today. Thus the equation (2+2=4) was useful because pile 1 combined with pile 2 is related to yesterday pile in the same way that 2 + 2 relates to 4.<p>Math is "correct" only in so far as it is consistent. That is, if you can arrive at a result using two different methods, you should find that the result is the same regardless of the method chosen. Similarly, reality is always consistent, because assuming that your behavior hasn't affected the situation, (and what is considered the situation doesn't include your brain state) it doesn't matter how  or even if you reason about the situation, the situation just is what it is. So the reason math is useful is because you can find abstract objects (like numbers) which relate to each other in the same way as parts of reality (like piles of apples). By choosing a conventional math, we save ourselves the trouble of having to reason about some set of relationships all over again every time that set of relationships occurs. Instead we simply map the objects to objects in the conventional math which are related in the same manner. However, there is no singular "correct" math, as can be shown by the fact that mathematics can be defined in terms of set theory + first order logic, type theory, or category theory. Even an inconsistent math such as set theory before Russell's Paradox can still often produce useful results as long one's line of reasoning doesn't happen to trip on the inconsistency. However, tripping on an inconsistency will produce a set of relationships which cannot exist in the real world, which gives us a reason to think of consistent maths as being "correct". Consistent maths certainly are more useful.<p>Brain states can also participate in this model of correctness though. Brain states are related to each other, and if these relationships are the same as the relationships between external objects, then the relationships can be used to predict events occurring in the world. One can think of math and logic as mechanisms to form brain states with the consistent relationships needed to accurately model the world. As with math though, even inconsistent relationships can be fine as long as those inconsistencies aren't involved in reasoning about a thing, or predicting a thing isn't the point (take scapegoating for instance).<p>Sorry for the ramble. I'll summarize:<p>TL;DR: Thoughts don't contain "refers" and "correctness" relationships in any sense that brain states can't. The concept of "refers" is only usable to predict behavior if people have accurate and complete information about the things they are thinking about. However, brain states predict behavior regardless of how accurate or complete the information the person has is. The concept of "correctness" in math/logic really just means that the relationship between mathematical objects is consistent. We want this because the relationships between parts of reality seem to be consistent, and so if we desire the ability to predict things using abstract objects, the relationships between abstract objects must be consistent as well. However, brain states can also have consistent patterns of relationships, and so can be correct in the same sense.</p>
]]></description><pubDate>Fri, 04 Apr 2025 15:52:14 +0000</pubDate><link>https://news.ycombinator.com/item?id=43584181</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=43584181</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43584181</guid></item><item><title><![CDATA[New comment by genrilz in "Microsoft Word and Excel AI data scraping switched to opt-in by default"]]></title><description><![CDATA[
<p>Because they boxed themselves in with legalese. Companies would definitely switch off Microsoft services if at all possible if the company's lawyers thought their trade secrets were getting sold off. So I think the "as necessary" framing does probably prevent them from doing some things.<p>As I laid out in my other comment, I think training AI in particular is covered under the "improving Microsoft products or services" bit of legalese. I do wonder how companies lawyers will respond to this though. They probably thought of that phrase as just allowing Microsoft employees access to documents to see how Word or other pieces of software were being used, or to fix crashes, etc.</p>
]]></description><pubDate>Tue, 26 Nov 2024 14:10:29 +0000</pubDate><link>https://news.ycombinator.com/item?id=42245895</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=42245895</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42245895</guid></item><item><title><![CDATA[New comment by genrilz in "Microsoft Word and Excel AI data scraping switched to opt-in by default"]]></title><description><![CDATA[
<p>IANAL again, but I don't think they get to do literally anything with your data. The phrase used is "to the extent necessary". For instance, I don't think they could scrape their user data for trade secrets and then sell those to the highest bidder.</p>
]]></description><pubDate>Tue, 26 Nov 2024 13:35:20 +0000</pubDate><link>https://news.ycombinator.com/item?id=42245579</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=42245579</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42245579</guid></item><item><title><![CDATA[New comment by genrilz in "Microsoft Word and Excel AI data scraping switched to opt-in by default"]]></title><description><![CDATA[
<p>IANAL, but I think the "to improve Microsoft products and services" bit does mean that they do legally get to train their AI (which is a Microsoft service) on your data. Still a bastard move though.</p>
]]></description><pubDate>Tue, 26 Nov 2024 13:29:29 +0000</pubDate><link>https://news.ycombinator.com/item?id=42245532</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=42245532</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42245532</guid></item><item><title><![CDATA[New comment by genrilz in "The two factions of C++"]]></title><description><![CDATA[
<p>Problem with memory corruption as a bug is that unlike most classes of bug, memory corruption allows remote code execution. (see return oriented programming for the basic version, block oriented programming for the more complex version that bypasses most (all?) mitigation strategies) There are other types of bug that allow remote code execution like this, such as SQL or command-line injection, but those can be solved with better libraries.* However, memory management requires a strong enough type system in the language.<p>* Sorta, for command-line injection you have to know the way the command you are using processes flags and environmental variables in order to know that the filtering you are doing will work. It is absolutely better to use a library instead if you can get away with it.</p>
]]></description><pubDate>Mon, 25 Nov 2024 14:51:43 +0000</pubDate><link>https://news.ycombinator.com/item?id=42236726</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=42236726</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42236726</guid></item><item><title><![CDATA[New comment by genrilz in "The two factions of C++"]]></title><description><![CDATA[
<p>One, iterator invalidation can be a temporal safety problem. Specifically, if you have an iterator into a vector and you insert into the same vector, the vector might reallocate, resulting in the iterator pointing into invalid memory.<p>Two, consider the unique_ptr example then. Perhaps a library takes a reference  to the contents of the unique_ptr to do some calculation. (by passing the reference into a function) Later, someone comes along and sticks a call to std::async inside the calculation function for better latency. Depending on the launch policy, this will result in a use after free either if the future is first used after the unique_ptr is dead, or if the thread the future is running on does not run until after the unique_ptr is dead.<p>EDIT: Originally I was just thinking of the person who inserted the std::async as being an idiot, but consider that the function might have been templated, with the implicit assumption that you would pass by value.</p>
]]></description><pubDate>Mon, 25 Nov 2024 14:31:33 +0000</pubDate><link>https://news.ycombinator.com/item?id=42236575</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=42236575</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42236575</guid></item><item><title><![CDATA[New comment by genrilz in "The Onion buys Infowars"]]></title><description><![CDATA[
<p>I'm kind of worried about society deciding which speech is "intolerant", so I'm not completely on board with the idea of treating tolerance as a social contract. That being said, if we could stop a genocide merely by suppressing people's speech, I feel like that would probably be a worthwhile thing to do. That is to say, it feels like the least bad way to prevent a genocide.<p>Again, figuring out which speech is worth suppressing is a whole other can of worms.<p>EDIT: note that Jones did have his speech suppressed, and this was done because his speech was causing people to make death threats against the sandy hook parents. I feel like we could classify Jones's speech as intolerant against sandy hook parents, and the same logic applies as for any other type of intolerant speech.</p>
]]></description><pubDate>Thu, 14 Nov 2024 18:57:33 +0000</pubDate><link>https://news.ycombinator.com/item?id=42139811</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=42139811</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42139811</guid></item><item><title><![CDATA[New comment by genrilz in "The Onion buys Infowars"]]></title><description><![CDATA[
<p>I think it's actually closer to "terrorists should go to prison". Terrorists and other criminals have broken a social contract, and a level of punishment that some approximation of society deems to be acceptable is extracted from the terrorists. This doesn't mean that terrorists don't/shouldn't have some rights. Similarly, thinking about tolerance as a social contract doesn't require stripping anyone who violates this contract of <i>all</i> of their rights.</p>
]]></description><pubDate>Thu, 14 Nov 2024 18:40:37 +0000</pubDate><link>https://news.ycombinator.com/item?id=42139579</link><dc:creator>genrilz</dc:creator><comments>https://news.ycombinator.com/item?id=42139579</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42139579</guid></item></channel></rss>