>use Rust they said. >it's memory safe they said. >bam...

>use Rust they said
>it's memory safe they said
>bam... MEMORY LEAK on a fricking PRIMITIVE ARRAY TYPE that EVERYONE USES
https://blog.polybdenum.com/2024/01/17/identifying-the-collect-vec-memory-leak-footgun.html
No fricking wonder the Linux Kernel has gone up by like 2GB of RAM usage over the past year.

Beware Cat Shirt $21.68

Rise, Grind, Banana Find Shirt $21.68

Beware Cat Shirt $21.68

  1. 1 month ago
    Anonymous

    NOO! DELETE THIS!1

    • 1 month ago
      Anonymous

      What does this have to do with the Linux kernel? Are all the paid shills from M$ this new?

  2. 1 month ago
    Anonymous

    That's not a memory leak, you still have access to the resource. Clickbait title.

  3. 1 month ago
    Anonymous

    >just shrink_to_fit

    • 1 month ago
      Anonymous

      ok but actually, imagine a future where all the clothes are self-fitting and you just get in a bath some chemical while wearing new clothes to fit them

  4. 1 month ago
    Anonymous

    This is not a memory leak. The memory is still in use and available for further elements and will be released when the vector drops. This is not a bug, it's an optimization you opt-in to use when calling collect

    • 1 month ago
      Anonymous

      >This is not a memory leak.
      that is, in fact, very much a memory leak.

      • 1 month ago
        Anonymous

        >It's a memory leak because I said so!
        Frick off moron, the entire vector drops when it goes out of scope

  5. 1 month ago
    Anonymous

    This ostensibly isn't a memory leak but they could have designed the API better. This is why people (in both Rust and C++) tend to steer clear of optimized standard library crap and just use C-style basics.

    • 1 month ago
      Anonymous

      No we don't. We use reserve() and shrink_to_fit() as we see fit. Majority of the time reserve() does the job for both optimization and reserving only what we need.

      • 1 month ago
        Anonymous

        akshually reserve don't shrink the memory (at least in C++)

      • 1 month ago
        Anonymous

        C++'s std::collect doesn't have this problem thow.

        Floating point operations do not, on their own, have the capability to cause memory corruption. Therefore, it is not considered unsafe by Rust's standards.

        [...]
        The f32 and f64 data types in Rust both implement the PartialEq trait, and thus can be compared using the == and != operators. You may be confused slightly because PartialEq is not the Eq trait, which does not actually implement any new operators, but instead is just a hint to the compiler that a == a is a safe assumption (this is not a safe assumption for floating point numbers because of NaN).

        >do not, on their own, have the capability to cause memory corruption. Therefore, it is not considered unsafe
        There's more to safety than memory safety, that's a large part of why Rust gets clowned on by C++ people, but even ignoring that the standard library math functions don't check for NaN and you absolutely can get memory corruption out of them because it's not like they return options.

        • 1 month ago
          Anonymous

          how does a math function returning NaN produce memory corruption in current rust?

          • 1 month ago
            Anonymous

            cast the NaN to an int and try to get the NaNth item in an array

          • 1 month ago
            Anonymous

            NTA but doesn't this just result in panic? Not a memory corruption.

  6. 1 month ago
    Anonymous

    this is what 99% of population would call a memory leak

  7. 1 month ago
    Anonymous

    DEBOONKED on orange website
    confirmed NOT a memory leak

    • 1 month ago
      Anonymous

      And the troons move the goal posts when logic stands in the way of their ideology.

  8. 1 month ago
    Anonymous

    This is literally how dynamic arrays work in every language.

  9. 1 month ago
    Anonymous

    This is their std::vector equivalent, not a primitive array type

  10. 1 month ago
    Anonymous

    >PRIMITIVE ARRAY TYPE
    Vec<T> is not the primitive array type, [T; N] is.

    • 1 month ago
      Anonymous

      >[T;ROO;N] is.
      frick off.

      • 1 month ago
        Anonymous

        dumb moron
        error: expected one of `!`, `.`, `::`, `?`, `]`, `{`, or an operator, found `;`
        --> src/main.rs:2:18
        |
        2 | let _: [T;ROO;N] = todo!();
        | - ^ expected one of 7 possible tokens
        | |
        | while parsing the type for `_`

      • 1 month ago
        Anonymous

        Stop watching porn, Your gay fetish is getting out of control.

  11. 1 month ago
    Anonymous

    >uses vec
    >Vec helpfully does not realloc and waste CPU cycles when using collect
    I don't get it. The blog tells you you can Box slices anyhow.

  12. 1 month ago
    Anonymous

    Literally nothing.

  13. 1 month ago
    Anonymous

    >why is my dynamic array eating memory
    lmao, people unironically think that because it's fungus lang, everything will magically be small and fast no matter what

    • 1 month ago
      Anonymous

      Bugs just can not exist in rust, they just can't.

    • 1 month ago
      Anonymous

      It's amazing that basically no one, outside the standard library authors, has even considered how functions like map work when changing types up until this point.

      • 1 month ago
        Anonymous

        What does map have to do with this? Isn't this about collect?

        • 1 month ago
          Anonymous

          >In my code, the last step prior to insertion maps the edge lists from (u64, u128) to (u32, u32), which is a third the size, hence why the capacity always increased by 3x after the conversion.

        • 1 month ago
          Anonymous

          yes. it's specific case of into_iter and then casting to a smaller primitive's alignment (eg, u16 as u8)

        • 1 month ago
          Anonymous

          The problem isn't limited to map but the behavior is typically much, much worse when a combinator is used that changes the original type to a smaller type.

  14. 1 month ago
    Anonymous

    >"""safe""" language
    >provides unfettered access to primitive floating-point math
    lol

    • 1 month ago
      Anonymous

      You can't even do == in rust on floats lmao. It's so dogshit.

      • 1 month ago
        Anonymous

        Why are you lying?

      • 1 month ago
        Anonymous

        why are you making shit up lol, you can literally go to rust playground and disprove your claim in a second

      • 1 month ago
        Anonymous

        I literally did that though. And honestly it's probably a good thing to prevent it in most cases because floats are Black personlicious and you should compare in a range anyhow.

    • 1 month ago
      Anonymous

      >>>>>>>>>>>>>>>>>>>>>>>safe
      >can't define custom integers
      what did the meme lang meme by this?

      • 1 month ago
        Anonymous

        Why are you lying?

        • 1 month ago
          Anonymous

          i am not

          • 1 month ago
            Anonymous

            You are.
            https://docs.rs/num-bigint/latest/src/num_bigint/bigint.rs.html#62-65

          • 1 month ago
            Anonymous

            >struct
            oh no no no no

          • 1 month ago
            Anonymous

            ??

          • 1 month ago
            Anonymous

            I think he's suggesting Rust should have subtypes like Ada, where you could for instance... define an integer type that could only have a value between 1 and 5. You could probably still do this in Rust by enforcing some constraints on the constructor of that type, as well as providing custom operators for it.

    • 1 month ago
      Anonymous

      Floating point operations do not, on their own, have the capability to cause memory corruption. Therefore, it is not considered unsafe by Rust's standards.

      You can't even do == in rust on floats lmao. It's so dogshit.

      The f32 and f64 data types in Rust both implement the PartialEq trait, and thus can be compared using the == and != operators. You may be confused slightly because PartialEq is not the Eq trait, which does not actually implement any new operators, but instead is just a hint to the compiler that a == a is a safe assumption (this is not a safe assumption for floating point numbers because of NaN).

  15. 1 month ago
    Anonymous

    >this is idiomatic rust
    use std::fmt;

    struct Wrapper(Vec<String>);

    impl fmt::Display for Wrapper {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
    write!(f, "[{}]", self.0.join(", "))
    }
    }

    fn main() {
    let w = Wrapper(vec![String::from("hello"), String::from("world")]);
    println!("w = {}", w);
    }

    sirs.... i am going back to java

    • 1 month ago
      Anonymous

      What's wrong with it, sar?

      • 1 month ago
        Anonymous

        rusts trait system encourages really bizarre ad-hoc anit-patterns like this,

        • 1 month ago
          Anonymous

          Sars, if it is anti-pattern, how is it idiomatic, sar.

        • 1 month ago
          Anonymous

          How is it an anti pattern, other than being syntactically ugly?

  16. 1 month ago
    Anonymous

    Memory leaks are totally heckin memory safe though, you transphobic chud.

  17. 1 month ago
    Anonymous

    Memory safe doesn't mean no memory leaks.

    • 1 month ago
      Anonymous

      >in Rust
      It does to the rest of the world, but hey you do you while we laugh at your delusional asses.

      • 1 month ago
        Anonymous

        No, not even in the rest of the world.

        • 1 month ago
          Anonymous

          This may come as a surprise to you anon, but a lie is still a lie even if you have convinced yourself to believe in it.

  18. 1 month ago
    Anonymous

    LMAO, the amount of "It's not a leak despite leaking! It's a feature despite no one using it! Pay no mind to the ever-growing memore on a fricking vector all dynamic arrays do this except uhhhhhh"
    COPE, IDIOTS.

    • 1 month ago
      Anonymous

      Create a dynamic vector class that is performant yet also doesn't have this issue without the user requesting it be shrunk, or reversing the capacity up front.

      • 1 month ago
        Anonymous

        >reate a dynamic vector class that is performant yet also doesn't have this issue without the user requesting it be shrunk, or reversing the capacity up fronetceetcblahblah
        I'll let you know when I'm done weeks from now. What is your point?

        Here's an idea, take the system page sized mmap, and partition the vector thusly. There you go, no need to oversize because you haven't figured out that you do not need to put them right side by side. Write your own replacement allocator since you're already needing to have virtually sequential memory.

        • 1 month ago
          Anonymous

          L M A O

  19. 1 month ago
    Anonymous

    Clickbait. Not a leak

    • 1 month ago
      Anonymous

      That's not a memory leak, you still have access to the resource. Clickbait title.

      This is not a memory leak. The memory is still in use and available for further elements and will be released when the vector drops. This is not a bug, it's an optimization you opt-in to use when calling collect

      literally not a leak
      cope and sneethe

      >It's a memory leak because I said so!
      Frick off moron, the entire vector drops when it goes out of scope

      > if we just say it's not a leak we can pretend it never happened
      rust trannies seriously are this delusional. another day goes by, another thread displaying the incompetence of rust and its programmers exists. sad. confirming once again that rust's safety is just a meme.

      • 1 month ago
        Anonymous

        >memory is freed once the vec is out of scope
        >NOOOOOOO SHUT UP ITS A LEAK
        impressive that IQfy doesn't even know what memory leaks are anymore.

        • 1 month ago
          Anonymous

          >User of the API didn't ask for it, therefore it should be considered a leak, from inception.
          Has you considered what happens over a runtime of years? Yeah, it's a leak. That the leak goes away eventually doesn't mean it doesn't leak. It just means it's harder to find.

          • 1 month ago
            Anonymous

            >User of the API didn't ask for it
            Yes you did by using Vec over a normal array. Case closed. RTFM.

          • 1 month ago
            Anonymous

            Then I will not use Rust who makes moronic designs in my stead, leaking memory just in case, and having explicitly told it only to be ignored. troony thinking.

      • 1 month ago
        Anonymous

        Memory leak means that the reference to region is lost and you cannot free the memory before the program exits. Which is not the case here.
        This is just vectors reserving extra memory, and all dynamic array implementations in all languages do the same.

        • 1 month ago
          Anonymous

          "Stop looking for memory that you leaked!"
          Unexpected memory usage may SOJMETIMES be because you're misusing the api and lost track of memory. But that's not the only reason you would be looking with a leak checker. You may be unaware, and curious why your numbers are way off. It IS a memory leak. Stop covering for bullshit, because it's not necessarily the correct behavior, as you can tell, by the use of a leak detection tool. Just because YOU are ok with it does not mean that it's ok on its' own. You're just saying "It's fine for me".

          I did. Not a leak, should've checked the capacity

          Should have been able to SET the capacity, you mean.
          You morons will defend anything just to say it's not a leak, but you can't say that he didn't have reason to look up WHY his memory and resolve his problem, correct? Then you must admit that there IS a leak because he couldn't conceive of it possibly being a source beforehand. Leak is unaccounted, by YOUR USAGE not the fricking garbage collector. For instance, perfectly legitimate memory could be requested every run, and still it builds up garbage that your definition of only unaccounted (by GC and not you) would be legitimate to you, even if it clearly isn't.

          • 1 month ago
            Anonymous

            Hmm, just curious, if you are collecting 65 ints in a vector, do you say you leak 63 bytes in the process? Because vectors allocate by the power of twos.

          • 1 month ago
            Anonymous

            >Because vectors allocate by the power of twos.
            Rust vectors allocate by a random amount Chud. Powers of two are for bigots.

          • 1 month ago
            Anonymous

            It depends on both the implementation actually does AND what I expect to happen. Ergo when dissonant and what I would expect, I may find memory usage to have leaked. Being okay with an implementation that may be sane or insane is always an option, since I'm unwilling to dunk my head into the sand and declare all memory usage as fine and dandy. Furthermore, it's actually going by the stride of the type's length, and the page length. Because once you go much further than that there is way too much slop in huge sizes. But going by the page size is as way to cut down on overhead as well for the middle sized...
            Saying "it's like this" is the least thoughtful thing to contribute because I have said from the get go that it SHOULDN'T be that way and even brought up a potentially better way that would eradicate the supposed necessary sequential behavior of allocating an array 'cuz "gottas be fast" and the overly allocated slop thast follows as a result.

          • 1 month ago
            Anonymous

            your posts are borderline incomprehensible

          • 1 month ago
            Anonymous

            What part are you having trouble with? I can rephrase simpler.

          • 1 month ago
            Anonymous

            the part where you are rambling and writing 60 word sentences

          • 1 month ago
            Anonymous

            I cannot help you become less stupid.

          • 1 month ago
            Anonymous
          • 1 month ago
            Anonymous

            Thank you for your literature notes. I'll keep it in mind if I write a non-programming book instead of conversant english with intentional slang on a forum.

          • 1 month ago
            Anonymous

            Long sentences aren’t a problem, the guy just doesn’t know how to write.

        • 1 month ago
          Anonymous

          >This is just vectors reserving extra memory
          the greatest cope

          • 1 month ago
            Anonymous

            Where is the lie?

        • 1 month ago
          Anonymous

          >This is just the vector reserving extra memory
          Also known as a leak.

          • 1 month ago
            Anonymous

            No, it's not. See

            Hmm, just curious, if you are collecting 65 ints in a vector, do you say you leak 63 bytes in the process? Because vectors allocate by the power of twos.

          • 1 month ago
            Anonymous

            Yes. That is a memory leak. The fact that you are used to it and ok with it does not make it "not a memory leak", it just means that you are ok with certain classes of memory leaks. And that's ok, as long as you aren't lying to yourself about it, and are clear as to *why* you are ok with those classes of memory leaks.

          • 1 month ago
            Anonymous

            Ah I see. That means every single garbage collected language leaks memory according to your delusional definition of what a memleak is.
            You are also free to have your own wrong opinion.

        • 1 month ago
          Anonymous

          Yes, it's a memory leak
          No, you are not a woman

          • 1 month ago
            Anonymous

            No it's not a memory leak, nor will you ever be a real programmer.

  20. 1 month ago
    Anonymous

    literally not a leak
    cope and sneethe

  21. 1 month ago
    Anonymous

    >reuse the allocation
    LMAO MEMORY LEAK
    >allocate a new array and place contents there
    LMAO NOT REUSING THE ALLOCATION

    it's all so tiring

    • 1 month ago
      Anonymous

      Don't worry, the language knows better and will happily 3x your amount called for, because frick you. Don't worry, it's not like you knew better, feel safe yet, imbecile?

      • 1 month ago
        Anonymous

        It's reusing the memory you've already allocated. How is that imbecilic? It's much less surprising than shrinking it behind your back

        • 1 month ago
          Anonymous

          >already allocated
          You have not read the link, that's what makes you an imbecile. Even being told directly you fail to see the problem. Another indicator of ibecile.
          You need to reread, particularly, 3x. Find out what that means. Was "your allocation" actually what happened? No.

          • 1 month ago
            Anonymous

            I did. Not a leak, should've checked the capacity

    • 1 month ago
      Anonymous

      Reusing buffers that are ridiculously oversized is not correct or expected behaviour.

  22. 1 month ago
    Anonymous

    Memory leaks are literally not something Rust protects you against as they do not compromise memory safety.

  23. 1 month ago
    Anonymous

    No worries, I'm familiar with israelite argumentation tactics. Instead of providing counter arguments, play stupid instead, then blame me for your ;lack of understanding, despite being unable to delimit your lack so that I could help you. Definitely make no conversational progress. How dare I converse with you. That'll teach me. Pearls before swine.

    • 1 month ago
      Anonymous

      you write like a schizo

      • 1 month ago
        Anonymous

        >take your meds Russian agitprop

    • 1 month ago
      Anonymous

      you rambled and wrote incoherent, unnatural english. it's not clear what your point is

      • 1 month ago
        Anonymous

        Not clear to you. Unfamiliar to you. Unspecified by yoy. The conversation is paused by YOU because you refuse to specify any issue that you could give in order to arrive at understanding for you. Saying the whole thing is not honest, and not worth my time because you are not invested in understanding, but actually more interested in attacking my character. You could come up with an assertion I have made, but you're so busy playing stupid that you'd rather assert that I have not made any.
        Did you ask me a question? Do you think I've answered it, even immediately? Why does my answer not agree with the question?

  24. 1 month ago
    Anonymous

    >footgun footgun footgun
    Fricking hate meme speak

  25. 1 month ago
    Anonymous

    didn't think it could get any worse but it looks like half this board doesn't know what a memory leak is or that over allocating is how dynamic arrays work in literally every language.
    are these /misc/ tourists or are IQfy users actually this clueless to the subject matter of their own board?

    • 1 month ago
      Anonymous

      This is the level of intelligence you could expect from old IQfy long before the threat of election tourism

  26. 1 month ago
    Anonymous

    pls understand, the rust trannies are having a burn out.
    They just need beg somefolk to rewrite the standard library.

  27. 1 month ago
    Anonymous

    test123

  28. 1 month ago
    Anonymous

    According to Rust, memory leaks are safe.

  29. 1 month ago
    Anonymous

    Memory Transition

    • 1 month ago
      Anonymous

      Best post ITT btw

  30. 1 month ago
    Anonymous

    More like your real gender leaking.

Comments are closed.