[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: 1741339675902587.jpg (223 KB, 533x1008)
223 KB
223 KB JPG
The beating will continue until the Rewrite it in Rust idiocy ends.
>>
>>107016991
did he really name the language after himself? lol.
>>
>>107017012
It's a compiler for a (very large) subset of C and C++ that aims to be extremely compatible with existing C and C++ code, not a new language. And who cares? If it it works, it works. Better than some stupid reddit name.
>>
>>107016991
good. the world needs a new meme as i'm sure V jokes went stale for a while now.
make sure you spam this in the orange site often, and do it with posts, but in the comment sections of "popular" stories.
>>
>>107017070
The whole point is that you can compile existing C and C++ code with it. It's the farthest thing possible from a "meme". BTW the full list of software is much longer than the screenshot. This is only like 20%.
>>
>>107017089
V's meme status was all the in the claims beyond mere compiling.
anyone with a functioning brain and the most basic but solid knowledge of system programming can recognize how meme-y the claims in OP's picrel are. lol.
>>
>>107016991
ok but do you, personally, write any code? or do you just post random ass snippets from people that others do not know?
you are aware that C has no namespaces? surely you understand how absolutely fucking annoying that is to programmers that actually want to build complex shit?
do you know how useful enums are?
what about generics? have you ever written any generic code in your life?
>>
>>107017153
People had no problem writing compilers and operating systems in C. What's more complex shit than that?
>>
>>107017135
This guy knows his shit really well and you're far too jaded. Sometimes it's good to give people the benefit of the doubt.
Demo here: https://www.youtube.com/watch?v=Gij9UQy_JEQ
>>107017153
lmao
have you ever written vulkan synchronization code? do you know what an image barrier is? ever looked at SPIRV disassembly? ever had to fuck around with DXGI swapchains to minimize input latency? have you ever had to deal with the shit compile times and undebuggable compiler errors from code that was written by people like you who think templates are a virtue?
do you understand how meaningless your syntactic sugar complains are? do you understand that the point of the post is not to discuss retarded language flamewars but to inforrm people that there is a far better way to bring memory safety to existing software?
>>
>>107017203
I've written a distributed fault-tolerant database with a custom algorithm for optimizing the total storage capacity of the network.
a transaction mechanism to go along with this.
niche cryptographic algorithms.
one massive benefit to Rust for crypto shit is being able to lean into the borrow checker to prevent misuse of your API. this prevents bugs.
enums are wonderful for preventing the lack of handling of cases.
the Cargo build system is brain dead simple and allows me to organize all of my shit into microlibs, which I consider good design. Cargo's vendoring allows me to work in airgapped environments with zero issue.
retarded type casting from void results in extra code for every single cast you perform, where an actual modern type system (that use those things called "papers" produced by researchers) corrects that and is so much more fucking convenient to use. like I'm not even going to have this argument with you, it is obvious to me.
>>
>>107017267
that's all well and good but it does not change the fact that you refuse to look at a technical project from an objective standpoint and instead prefer to attack people you know nothing about because they're not being nice to your favorite language.

PS: The only interesting feature in Rust is the borrow checker and the memory/thread safety that come with it. Everything else is banal syntactic sugar that is not worth discussing. Rust enums are just tagged unions that you can do in C89 or probably even older versions of C.
>>
>>107017322
I accept your concession.
>>
>>107017322
// challenge: represent this enum using C's tagged unions
enum SomeEnum {
Foo,
Bar(Vec<i32>),
Baz { some_vec: Vec<i32>, some_index: usize, some_message: String },
}
>>
>>107017329
There is no concession.
>>107017342
struct Ints {
size_t count;
size_t capacity;
int* pointer;
};

enum SomeEnumTag {
SOME_ENUM_FOO = 0,
SOME_ENUM_BAR = 1,
SOME_ENUM_BAZ = 2,
};

// Rust owned Strings are just dynamic arrays that
// contain utf8 bytes. This is how you would do that in C.
struct String {
size_t length;
size_t capacity;
char* pointer;
};

struct SomeEnum {
SomeEnumTag tag;
union {
struct {
Ints ints;
} bar;

struct {
Ints some_vec;
size_t some_index;
String some_message;
} baz;
} as;
};

In C++ I just use my own Variant<Ts...> type that adds a little bit of syntactic sugar.
>>
>>107017426
technically you'd have to typedef the structs as well, but that's just all the time I spend writing C++ giving me brainrot.
>>
>>107017203
half ignorants sound like geniuses to the fully ignorant.
>>
>>107017475
You can just download it and try it with whatever program you want instead of calling yourself "fully ignorant"
>>
>>107017495
>no u
>>
>>107017426
ignoring the implementing of String and Ints, this is still more code than Rust. it's also not exhaustively matched, resulting in potential bugs.
C has no obvious on-ramp for a macro that allows for writing your own enum definition utility to reducing LOC, where Rust does with procedural macros.
>>
>>107017825
>C has no obvious on-ramp for a macro that allows for writing your own enum definition utility to reducing LOC, where Rust does with procedural macros.
A proc macro is just a metaprogram. You can write a metaprogram in any language since by definition it's just a program that operates on a program. I agree that it would be nice if the C standard mandated the inclusion of a C lexer and parser in the standard library.
>it's also not exhaustively matched, resulting in potential bugs.
Anyone writing code in C or C++ who is serious about code quality turns on warnings and warnings as errors. There is a warning for that specifically in every big compiler implementation if you use a switch statement (C4061 on MSVC https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4061).
>>
>>107017135
>>107017475
Fil-C is legit despite the creator's edgelord persona, he basically forked clang to target a GC instead, all memory access become managed and the compiled C/C++ won't be anymore optimized than Go or Switft let along Rust, but yes, it's memory safe

He pops up in compiler threads all the time with narcissist attitude but valuable points, somewhat like the Dlang creator, meanwhile I've never seen V or Zig's "creator" discuss anything remotely technical beyond "AST bad" or "RAII bad", respectively
>>
>>107018012
From a design standpoint, Fil-C has much higher potential throughput compared to Swift because Swift uses automatic reference counting. Code written in C usually avoids doing many tiny allocations, so the performance is probably not that bad compared to a real-world Go application.

Rust will probably be faster, yes. But like, who gives a shit about their sudo or curl being fast CPU-wise? Much rather have battle-tested software that is now also memory safe.

Also, the GC's design is really impressive (https://fil-c.org/fugc). Earlier versions used isoheaps but the creator found that GCs give a better tradeoff.
>>
>>107018000
yes, all proc macros are just programs. but I do not see too many people using Jinja or some other shit with languages that do not natively support macros. macros are a necessity in any language that I would use in 2025.
as for code warning flags: C's standard permits things that are simply not able to be (easily) checked at compile-time, resulting in less warnings than Rust can provide.
why do you like C? when I last wrote C, I, quite quickly, ended up using the preprocessor to do ghetto generics (which are absolutely necessary in statically-typed lang). backslashes everywhere. it's lack of error handling model lead to me flagging errors in retarded ways. oh, I want to check my arithmetic for overflow, better rely on GCC builtins or write some slow ass branches.
Rust has many standard collections with a sizeable API, which is very important when much programming is just the slinging around of data.
Rust's traits/generics allow me to only implement shit once (microlibs), which is very important when I have like 20 projects I want to finish before I leave this planet.
Rust has so many fucking high-quality 3rd-party crates that work well together.
Rust is the language I can reach for to implement a hash table that outperforms Swiss Table by 2--3x in most scenarios. Rust is the language I can reach for to implement a SaaS doing a bunch of complicated SQL queries.
I can build literally anything in Rust. with its type system, I can work at very high abstraction levels, almost like I am writing Clojure.
>>
>>107018012
>all memory access become managed
>yes, it's memory safe
those are the V-like meme claims.
the premise itself is retarded because it's slower (much slower i would safely guess) and less safe than anything rust guarantees (for real). but the meme part is that the premise doesn't even hold true beyond "demos" (again, V-like). and anyone with experience and familiarity with the complexities and variety of low-level shit would trivially grok that.
but again, i'm all for ambitious confident half-ignorants keeping the fully ignorant orange tards busy and confused.
>>
>>107018000
>A proc macro is just a metaprogram. You can write a metaprogram in any language
lmao
i hope that's the retarded /g/eet markov chain tarding out again. otherwise, we have another source of good accidental comedy.
>>
>>107016991
>fil-c
WOAH! That's incredible? Why isn't literally everyone talking about this?
>>
>>107017267
There's no fucking way I'd write crypto anything in rust. Too much magical bullshit like C++ so you're inevitably going to end up with side channel attack.s
>>
File: coverpower.jpg (78 KB, 1200x675)
78 KB
78 KB JPG
>no freestanding support
>no real time support
>no syscalls
>no FFI
>no manual memory managment
>always on garbage collector
>>
>>107018631
https://docs.rs/subtle/latest/subtle/
https://docs.rs/zeroize/latest/zeroize/
https://github.com/RustCrypto
there's a ton of crypto in prod systems using Bouncy Castle, written in Java of all things
anyway, side channel attacks are not a "solved problem." time analysis attacks are trivial to defeat in a myriad of ways. things like power draw analysis are more difficult. anyway, at some point, you begin to question if you do not have bigger problems if an attacker is monitoring your power draw and shit.
>>
>>107017203
>have you ever written vulkan synchronization code? do you know what an image barrier is? ever looked at SPIRV disassembly? ever had to fuck around with DXGI swapchains to minimize input latency? have you ever had to deal with the shit compile times and undebuggable compiler errors from code that was written by people like you who think templates are a virtue?
I did. Vulkano makes Vulkan in Rust really comfy.

>>107018631
Why not? Rust is really neat for small, self contained software like cryptographic libraries.
>>
>>107017174
You do realize you can't use Fil-C to make an operating system, right?
>>
>>107016991
Fil-C is literally slower than Rust.
>>
>>107018469
you are the one claiming "system programming knowledge" but cannot give even one trivial example against it's memory safety guarantee, cope harder
>>
>>107017342
This. C cucks don't understand how powerful this is. I write whole state machines with enums with fn whatever(self, data). It's beautiful.
>>
>>107018782
spam this enough as i already encouraged you to do, and you will get posts memeing you, don't worry about that.
unfortunately, some of us are both busy, and don't have the patience to explain 101 level shit to people anymore.
you might be surprised, but some of us shitpost only when we are actually physically taking a shit.
>>
>>107018873
out of arguments already? lmao
> "solid knowledge of system programming "
>>
>>107017012
kinda baseded
>>
>>107017203
Putting out a youtube video is the modern equivalent to scammers putting their scams on VCR to dupe morons
>>
File: 1736648400398664.gif (1.92 MB, 450x357)
1.92 MB
1.92 MB GIF
>>107018012
>adding garbage collection to C
>>
what are they hiding that theyre so afraid of buffer overflow attacks?
>>
>I can't invent new things so just rewrite stuff that already exists in Rust
>I can't make an original story so let's just reboot movies, shows, videogames, and cartoons that already exist
What causes this?
>>
>>107016991
weak bait, but rust has abstracted all unsafe func calls, wrapped all unsafe callable things out of a libraries
>>
>>107017267
>>retarded type casting from void results in extra code for every single cast you perform

Found C++ nigger larping as a C programmer.
>>
File: 1760892451195416.jpg (27 KB, 461x461)
27 KB
27 KB JPG
>>107016991
This thing has a garbage collector and instead of preventing UB at compile time it will just crash. Safety my ass
>>107017322
Peak dunning kruger
>>
>>107019888
They wouldn't know, I think that's the point.
You don't know which bugs are hiding in unsafe code until after you find them.
>>
>>107020567
>peak dunning kruger
Ironic considering you don't know what the fuck memory safety means. What do you think RefCell does? Do you think it's magic? I wouldn't be surprised if you think it's magic that runs on pixie dust just like everything else in Rust of course. What do you think indexing out of bounds in rust does? It creates a magic valid value for you?
>>107019796
didnt understand the demo and just defaults to calling everything he doesn't understand a scam award
>>
File: file.png (944 KB, 959x981)
944 KB
944 KB PNG
>>107020567
>Safety my ass
>Peak dunning kruger

>>107019941
i remember reading somewhere how rust project's jannies were going to turn all unsafe code in their libraries to safe but not sure what happened with that. i think it might have bothered people that they're promoting use of safe code while they're libraries don't, mostly because it'll tank the performance.
>>
>>107017322
>Rust enums are just tagged unions that you can do in C89 or probably even older versions of C.
Pattern matching is neat.
>>
>>107016991
Post source retard
>>
>>107020567
>Peak dunning kruger
lol you wish. you converse with literal retards here, as evidenced by the replies you got.
they are not expert in anything, topic-adjacent or not.
if in doubt, ask them to post code and wait..forever.. lmao
>>
>>107017135
>>107018012
Anyone with half brain knows V is a joke. Idk shit about Fil-C. Dlang is kitchen sink without clear direction. Zig is cool.
>>
>>107020613
>You don't know which bugs are hiding in unsafe code until after you find them.
You also don't know what bugs are hiding in Fil-C runtime either. This is it's counterpart of unsafe.
>>
>>107020689
NTA, you don't need magic for RefCell to work. RTFM
>>
>>107017322
>you refuse to look at a technical project from an objective standpoint and instead prefer to attack people you know nothing about
Hmm, where have I seen this before.
>>
So rust pressured Cniles to finally implement proper memory safety? That seems like a total Rusttranny victory to me, philosophically if not literally
>>
>>107020764
>i remember reading somewhere how rust project's jannies were going to turn all unsafe code in their libraries to safe but not sure what happened with that.
I don't think you understand what is the point of unsafe.
>>
>>107021571
yes so what? Some devs don't have ideologies enabling them to evolve unlike rust devs that usually are very ideologically entrench.

memory safety is a great thing and VM languages are a prove of it
>>
>>107021573
anon was right. it's about rewriting the standard libraries to no longer use unsafe{}, in order for the whole tranny eco system to use safe instead. there are performance penalties in doing that that but nobody really cares. unfortunately everyone is trusting rust tranny's libraries so the whole idea of "safety" seems to change with the direction of the wind, depending on which incompetent no-coder tranny you are talking to. they will also try to justify 100mb+ for an executable to open a window and display text is perfectly normal and pretend the same problems that plague C also plague rust because reading CVEs about rust is too much work. if it's not on reddit then it never happened.
>>
>>107021772
>it's about rewriting the standard libraries to no longer use unsafe{},
That's why I said you don't know the point of unsafe. Unsafe exists in order to create safe abstractions over unsafe operations. Calling a syscall, deallocating memory, dereferencing a raw pointer, setting up MMIO, etc are all inherently unsafe operations. You can't write standard library or runtime of any language without these operations. In order for Rust, Java, JavaScript, Ada or any other memory safe language to support any non trivial code, they need their standard library to provide safe interface for these unsafe operations.

>there are performance penalties in doing that that but nobody really cares.
This is not matter of performance penalty. There is slow but safe way of calling a syscall.
And Rust cares a lot about performance. That's why it is made with zero cost abstractions in mind.

>so the whole idea of "safety" seems to change with the direction of the wind
Safety is defined as lack of observable undefined behavior. It always meant that.

>they will also try to justify 100mb+ for an executable to open a window and display text
If your minimal Rust program that opens a window and displays text takes 100mb+ for an executable then that's some serious skill issue and you need to git gud.

>pretend the same problems that plague C also plague rust
No one says that. People claim that Rust prevents or significantly mitigate entire kinds of runtime bugs.
>>
>>107018012
Wait so it's just adding a GC to c? Is this really any better than existing GC-ed languages, like Go for that matter?

The selling point of rust is not that it's just memory safe (java achieved that three decades ago, arguably shit like lisp was memory safe even earlier), it's that it's memory safe while compiling directly to ASM and being competitive with C/C++. Adding memory safety while making the language slower is easy and has been done many times before.
>>
>>107019883
would this disqualify someone in an eating contesf
>>
>>107022038
This is not just GC, it's also mandatory bounds checks, fat pointers with capabilities and no real FFI. Dunno if they allow for optimizations to remove any of this, because if not, in practice this might be even slower than JIT compiled languages like JS or Lua.
The Fil-C doesn't provide any comparisons nor even mentions performance once in the documentarion except claiming it's "reasonable" and the author self proclaiming to have 15 years of experience building high performance high level languages lmao.
Performance is probably not their concern. I don't understand why even bother with C at this point but whatever.
>>
>The only way to make C as safe as Rust is to make it so painfully slow that you can't use it for anything you'd want to use C for
Total Rust victory
>>
>>107021542
very good reading comprehension
>>
>>107022146
>>107022038
the selling point of filc is that you can make existing C programs memory safe using it with little to no effort
>>
>>107022253
The thing is it's a very niche selling point if your performance is significantly degraded. Few people would take an e.g. 2x or even 1.5x hit to their libc performance in return for memory safety. Especially when the main selling point of C code is that it's been battletested for decades - if libc had any major vulnerabilities right now then everyone all over the world would be vulnerable, so even if it exists it's probably hidden as a zero-day hoarded by the NSA only to be used against the highest value targets.

So maybe it makes sense in some hyper critical application where you really want safety and can sacrifice performance. It has to be critical enough to where decades of production isn't good enough, but at the same time not so critical that you'd want to use ADA or SPARK instead. Seems pretty niche to me.
>>
>>107022295
Computers have gotten very fast and many people would be willing to take the performance hit in exchange for a hardened system (the same kind of people who disable JITs in browsers).
I can think of many use cases. Not having to worry about memory vulnerabilities in core system components (especially things like sudo and sshd and openssl) is pretty nice. If you just want to use a battle-tested http server like nginx to host a website, it would be a pretty good idea to compile it with filc. etc.
According to the author, the perf hit right now is like 4x, down from 200x when he started. Says he can bring it down further.
>>
This does not look very safe.

So much for type safety. It couldn't even catch this simple type confusion bug. No matter how much GC and runtime checks you add, as long as you stick to C's stdlib you will never be safe from footguns.
If you need safety, use different language.
>>
>>107022559
the security concern with type confusion is that you are able to forge a pointer you control and get a read/write primitive. otherwise it's just a normal bug (or a feature depending on your use case, this is C after all) in the program like any other.
your code does not do that. it just gives interprets a const char** as a const char*, so printf is reading the bytes of the pointer and thinking it's a string. It shouldn't be possible to read past the bytes of the pointer, otherwise the runtime would crash because a,b in cmp both have capabilities that determine bounds.
if you are able to forge a pointer, that is a soundness issue in filc and should probably reported. however, that is not what your code does.
>>
>>107022714
>so the whole idea of "safety" seems to change with the direction of the wind
Hmm...
>>
>>107022793
no. it's just that looking at the bytes of a valid initialized thing in memory is not a memory safety issue. half the C programs in existence would insta-crash if you disallowed that. If it cannot be exploited then it's not a memory safety issue. Looking at the bytes that describe a valid pointer is not a memory safety issue.
>>
>>107022820
>If it cannot be exploited then it's not a memory safety issue
Another redefinition
>>
Alright, let's put this to test.

I will repurpose my string copying demo for this. Let's compare how fast can Fil-C sort lines from stdin. And... it doesn't look good. It's 7 times slower than Rust, 2 times slower than retarded C++ implementation that does allocations on each operation and even nearly 2 times slower than javascript...
>>
File: 1753251299863966.jpg (137 KB, 726x991)
137 KB
137 KB JPG
>>107022939
performance can always be improved. no one said it's fast.
btw picrel is an example of what i was saying earlier.
>>
>>107017174
>People had no problem writing compilers and operating systems in C. What's more complex shit than that?
They also had no problem using Pascal, PL/I, Ada, Lisp and other better languages. C is the enshittification of computing. A guy in the 80s compared using C and Unix to being born in East Africa. C programmers are out here acting like smallpox and Guinea worm are normal and unavoidable things that happen to people every day.
>>
>>107023013
>performance can always be improved
It can't actually. As soon as you begin optimizing checks away, any such type confusion bug will result in undefined behavior. The only way to maintain memory safety while such confusion/corruption is allowed is to ensure that every pointer dereference is checked. And that will in practice result in runtime that is even slower than any sophisticated JIT compiled language. Like I've theorized and tested against JS.

>no one said it's fast.
That's what made me suspicious. The reason why people use C over managed languages is because it is very fast and/or allows for writing in bare metal environment. Fil-C has none of advantages of either managed and unmanaged languages while having all the disadvantages of both. That is kind of funny.
>>
>>107018227
>why do you like C? when I last wrote C, I, quite quickly, ended up using the preprocessor to do ghetto generics (which are absolutely necessary in statically-typed lang). backslashes everywhere. it's lack of error handling model lead to me flagging errors in retarded ways. oh, I want to check my arithmetic for overflow, better rely on GCC builtins or write some slow ass branches.
When you use C, you get ghetto everything. C is the ghetto language.
>>
>>107023065
you can hoist checks and eliminate them in certain cases. the same way rust optimizes bounds checks. e.g you can imagine before doing a memcpy you check the capabilities once and then call into the hardware accelerated assembly simd routine. there are many other opportunities like that. right now the author is just focusing on making it work with as much C code as possible.

Fil-C is a tool for system administration and software distribution/hardening, not a new programming language for programmers. It's a way to take existing C programs and make them memory safe.
>>
>>107023137
>you can hoist checks and eliminate them in certain cases. the same way rust optimizes bounds checks
The difference is that Rust will not allow you to confuse pointer types and potentially mutate data which compiler assumed won't be mutated as a base to optimize away checks.
>>
>>107023167
You can't forge a pointer that allows you to read and write wherever you like, like I showed here >>107023013. You can do a lot of optimizations with just that guarantee.
>>
>>107023206
>You can't forge a pointer that allows you to read and write wherever you like
Because there are checks done on every dereference. As soon as you start optimizing them away, you will be able to break any assumed invariant via type confusion.
>>
>>107023222
you can just check the capabilities once for the entire block of memory before accessing a block of memory. logically speaking, this is probably what the compiler already does when dereferencing a pointer to a structure for example. the model you're thinking of is more like ASAN (shadow bytes) which is very different from this and incredibly slower.
>>
>>107023240
>you can just check the capabilities once for the entire block of memory before accessing a block of memory
And then some random function will have some unexpected side effect which will render that check invalid.

>>107022820
>If it cannot be exploited then it's not a memory safety issue.
Here is a working exploit.
It is by no means trivial to catch.
>>
>>107018227
The macro question is not so simple. Macros have both significant advantages and disadvantages.
In my experience the biggest possible issue with them is that they interact poorly with each other. For instance there may be a situation where macro a wants to run after macro b but macro b wants to run after macro a.
>>
>>107023793
NTA, Rust mitigates that by forcing macros to be stateless, pure functions. There is no way of macros to interact with each other except for nesting. Macros can at best generate code that will interact with code from other macro, but they can't directly talk to each other. Therefore the order of their evaluation does not matter.
This of course limits what you can do with them. But it works for 99% of usecases in my experience.
>>
>>107023647
The bug is that bsearch returns a pointer to an element and not the element itself. It should be User**.
This obviously breaks type safety, but it is not clear to me that it is breaking memory safety. You do not have an arbitrary read/write primitive because of memory management bugs such as a user-after-free. To me (in a reductive sense) this is morally equivalent to someone writing
// should have written if admin
if !admin {
// ...
}

or accidentally pushing their API key to a public repo. The scary thing about memory exploits is that they are probabilistic in nature. They may not appear except under certain scenarios and address space configurations with many attempts. What you showed can be caught just by coverage testing the code.

Yes, it's of course better to have type safety for security-sensitive applications, just like it's better to have design by contracts and dependent types and so on as not all security bugs are memory exploits, but that is a separate matter of discussion.
>>
>>107024107
>The bug is that bsearch returns a pointer to an element and not the element itself. It should be User**.
Of course. But this shows how easy it is still to shoot your foot off because C is C, even if you sacrifice performance tenfold and force checks everywhere.

>You do not have an arbitrary read/write primitive because of memory management bugs such as a user-after-free.
You do not need arbitrary read/write primitive to execute such exploit, as demonstrated above.

>To me (in a reductive sense) this is morally equivalent to someone writing
>// should have written if admin
>if !admin {
> // ...
>}
Every vulnerable code can be reduced to intentionally malicious code.

>The scary thing about memory exploits is that they are probabilistic in nature.
While working on this code, the previous versions were probabilistic as well. I purposefully changed the code to make sure it happens every time to showcase this vulnerability.

>What you showed can be caught just by coverage testing the code.
Doesn't have to be. If this is just some rare case where it happens if stars align it might be just as easily missed.



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.