>nooooo our language is safe!
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
>can't slice zero copy >faster
NPC broken radio
>can't imagine how to do anything without a library function >a library function which, btw, was written in C
kek
2 months ago
Anonymous
>she thinks libraries are still written in C
lmao who gonna tell him its not 1980s anymore
2 months ago
Anonymous
>couldn't come up with one example >"noooo it's not the 1980s any more"
>Heap buffer overflow in vp8 encoding in libvpx in Google Chrome prior to 117.0.5938.132 and libvpx 1.13.1 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)
Bug in C code, it's not Rust, just like most of other CVEs.
Can't spell CVE without C.
>finds one cve where he can claim it was really c's fault >RUST IS PERFECTLY SAFE
No language is safe, and you will never be a woman.
2 months ago
Anonymous
>N-NOOOO THAT DOESNT COUNT REEE
Humiliation ritual
2 months ago
Anonymous
C is not claiming to be safe
2 months ago
Anonymous
So don't give me a list that blames Rust for C's lack of safety.
2 months ago
Anonymous
most of those CVEs are due to rust not C
2 months ago
Anonymous
>Heap buffer overflow in vp8 encoding in libvpx in Google Chrome prior to 117.0.5938.132 and libvpx 1.13.1 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)
Bug in C code, it's not Rust, just like most of other CVEs.
Can't spell CVE without C.
imagine actually thinking youre a good programmer because you know c.
a good programmer knows all languages, not only c.
when there is a debate about which programming language can do what, you cannot claim that one language cannot do something if you do not know said language.
but oh well, larp along.
i cant teach a rock to think.
Why can’t C into strings? It’s been 45 years and they still can’t figure it out.
Strings are arrays of characters. If you wrongly access beyond their boundaries, that's a segmentation fault. How is that a problem with C? It's a mistake you're making as the programmer. >The language should have built-in management tools for strings since they are commonplace
but then you get performance overhead and memory slop because the string library is bloated to hell with every single unimportant use case and problem, when all you wanted to do was store a simple user name.
If you have something much more complex than that and don't need performance, why even use C in the first place?
>If you wrongly access beyond their boundaries, that's a segmentation fault.
No it's not. That's only if it crosses a page boundary and it's an unmapped page. Most accesses out of bounds in C have no indication at all. They just cause more trouble later on and that's how your code gets backdoored.
>but then you get performance overhead and memory slop because the string library is bloated to hell with every single unimportant use case and problem, when all you wanted to do was store a simple user name.
The creators of normal languages know that strings are used by almost every program so the creators of the language optimize strings as much as possible. C "strings" turn your simple user name into another source of buffer overflows and memory exploits.
He means not being able to represent the null character in a string without it terminating the string.
2 months ago
Anonymous
ah
but then you use
struct string
{
size_t size;
char *data;
};
2 months ago
Anonymous
at which point you can no longer use your string with anything except your own code
not even the stdlib can handle your intermediate-null'd string
2 months ago
Anonymous
the C stdlib exists to trick newbies
2 months ago
Anonymous
tsmt
2 months ago
Anonymous
yeah.
but the libc sucks ass.
and null terminating your string is not a problem.
you allocate room for it in your initial string (which you should anyways)
you store the char of the end of your slice
you put a 0 in its place
you shove the "c-ified string" into the libc
get your results
replace the 0 with the original char
profit.
2 months ago
Anonymous
at which point you've added O(n) to anything that requires handing it off to an external lib
2 months ago
Anonymous
blud fr if you want it fast dont import stdlib ong, include fastlib
lil bro tryina go at standard speed lol no cap :skull:
2 months ago
Anonymous
>le big o notation
do you only know what it means?
bc in practice your big sounding "o(n)" amounts to less than one tenth of a percent runtime overhead (4 cycles?maybe even 2) with most of things you might wanna call within the libc
2 months ago
Anonymous
>i can use vector operations to make it run faster, therefore good
sneed
2 months ago
Anonymous
C doesn't have the concept of vocabulary types.
2 months ago
Anonymous
no the real problem is not being able to slice strings withour copying
2 months ago
Anonymous
if you read by size instead of checking for null termination you can represent null allright.
as for opisagay's slices you can use
struct string
{
char *start;
char *end;
//size_t size; if you need it
};
I used C for the xdg-desktop-portal for the filepicker I wrote, and the dbus library uses null terminated strings and takes ownership of them so you can't use it with non-standard string types
C is literally the best language to do fast string processing in as long as you're intelligent enough to roll your own code. Your high level language 0-copy slice is almost certainly written in C and compiled to a library that gets linked in. It obviously is not using NUL but describing the strings with structures optimized for the desired language behavior. >t. has used C to build libraries called from high level languages in order to accelerate string processing
>Your high level language
C is a high level language too, not sure why you are making a distinction. > 0-copy slice is almost certainly written in C
Wrong. This isn't 1885 anymore. Nobody writes new language or compilers in C. Not even C compilers are written in C.
>>Your high level language >C is a high level language too,
Not by comparison. It's not a black/white thing but a gradient.
>> 0-copy slice is almost certainly written in C >Wrong. This isn't 1885 anymore. Nobody writes new language or compilers in C.
Why do people mouth off like this when they don't know? I'll never understand that aspect of human psychology. Especially today with fricking Google. I mean, was this bait? Or just another example of over confident ignorance?
>Why do people mouth off like this when they don't know?
I don't know you tell me, you are one of them. Python was written in 1989. Lot has changed and C has lost its relevancy in language tooling.
2 months ago
Anonymous
python isnt new
>HURR MUH CURRENT YEAR
Tell us please which high level language has been implemented without ANY C/C++ libraries used in the framework or the compiler. Go ahead. Tell us. Rust maybe? Rust can implement string processing in Rust because Rust isn't as high level as something like Python and can do efficient string processing.
You can't use Python to implement Python string processing libraries (among other things) efficiently because the features that make Python "hurr high level durr easy to use derp safe" also prevent it from doing efficient string processing. Any language like that is using C (or Rust) under the hood.
2 months ago
Anonymous
Disclaimer: This is my first post in this thread. >Tell us please which high level language has been implemented without ANY C/C++ libraries used in the framework or the compiler.
That's a bullshit question for any language that runs on a modern OS. The syscall interface is defined by C libraries. It's not stable across OS versions at the assembly level. Go tried to be totally 100% C-free and kept getting in deep shit as a result, even on Linux where this is supposedly doable.
Aside from Go, SBCL comes to mind. It's written in Common Lisp. You bootstrap it from Common Lisp. It compiles Common Lisp directly to machine code. That said, I'm sure it still uses C somewhere to interface with the OS.
2 months ago
Anonymous
>Disclaimer: This is my first post in this thread.
What an odd thing to say.
>That's a bullshit question for any language that runs on a modern OS. The syscall interface is defined by C libraries.
Don't cope, you know damn well what I was asking for.
>Aside from Go
C can run circles around Go in terms of string processing. So you have your example, but it only proves my original point.
>SBCL comes to mind.
Well would you look at those runtime files...
https://sourceforge.net/p/sbcl/sbcl/ci/master/tree/src/runtime/ >nooooo that's just to interface to the OS!
Noooo, there's a ton of code there to support the data types and core functions of Common Lisp. Including strings.
uhm cbros... I was only looking it up as a meme but..
You're not going to see Python in Python. It would be vastly slower than it already is. Rust can do fast string/data processing, though C still has the edge. These "why can't C do X?" threads are pure bait. X is probably done in or supported by C. If you want zero copy slices in C, implement it yourself or find a library that does it for you.
2 months ago
Anonymous
python isnt new
>cnile brainlet eats his own word in yet another display of self-own: episode 91
>samegay doesn't know shit about string processing, frameworks, compilers, or bootstrapping
Probably a jeet.
2 months ago
Anonymous
Just take the L and move on bro. You learned today Python isn't new.
2 months ago
Anonymous
>nobody has touched python since 1989
kek >no examples
Take the L and move on bro. You know jack shit about any of this. You're bragging about "muh X language slice function is better than C" when C was used to write your slice function.
2 months ago
Anonymous
>nobody has touched python since 1989
Bro python was written in C because it was written in the previous century. I understand you thought it was some new language but why is your ego too big to take an L and make it an educational moment for you?
>Your high level language 0-copy slice is almost certainly written in C and compiled to a library that gets linked in.
Rust and C++ self-host this. Haven't used C++ but it's fantastic in Rust, can probably manage the things you're thinking of
C is a byte-pusher language, not for the actual logic.
This abdication of the role was done decades ago when Obect-Orientation and high-level languages became real (as in, you can run them on a regular computer from the dollar store)a n2y
Because "smart" save space, choice string as char arrays with last character is choice by null.
Then programmers must do array processing with null fails, silent O(n^2) problems and array out bounders, dozens of thousands of different string implementation as char array plus size.
But but but save space a single integer.
Any competent c/c++ codebase will use it's own internal string slice type and only convert to null terminated when it absolutely needs to (interfacing with other libraries).
Rust trannies cannot comprehend this because they worship the language and it's standard library and can't imagine not using part of it.
You can't slice strings in C so you can't not create a copy by slicing to begin with.
What a terrible bait and strawman. kys.
>try to write a simple program in C
>Segmentation fault
Frick this, I'm going back to python.
C sisters… our response?
Samegay
skill issue unironically
>nooooo our language is safe!
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
>can't imagine how to do anything without a library function
>a library function which, btw, was written in C
kek
>she thinks libraries are still written in C
lmao who gonna tell him its not 1980s anymore
>couldn't come up with one example
>"noooo it's not the 1980s any more"
>finds one cve where he can claim it was really c's fault
>RUST IS PERFECTLY SAFE
No language is safe, and you will never be a woman.
>N-NOOOO THAT DOESNT COUNT REEE
Humiliation ritual
C is not claiming to be safe
So don't give me a list that blames Rust for C's lack of safety.
most of those CVEs are due to rust not C
>Heap buffer overflow in vp8 encoding in libvpx in Google Chrome prior to 117.0.5938.132 and libvpx 1.13.1 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)
Bug in C code, it's not Rust, just like most of other CVEs.
Can't spell CVE without C.
imagine actually thinking youre a good programmer because you know c.
a good programmer knows all languages, not only c.
when there is a debate about which programming language can do what, you cannot claim that one language cannot do something if you do not know said language.
but oh well, larp along.
i cant teach a rock to think.
> schizo rust troony posts same thread daily
> continually gets shit on
have a nice day, thanks.
>try to implement a double linked list
>50 compiler errors
>segfault
C/C++ sistas how are we gonna recover from this?
Strings are arrays of characters. If you wrongly access beyond their boundaries, that's a segmentation fault. How is that a problem with C? It's a mistake you're making as the programmer.
>The language should have built-in management tools for strings since they are commonplace
but then you get performance overhead and memory slop because the string library is bloated to hell with every single unimportant use case and problem, when all you wanted to do was store a simple user name.
If you have something much more complex than that and don't need performance, why even use C in the first place?
>If you wrongly access beyond their boundaries, that's a segmentation fault.
No it's not. That's only if it crosses a page boundary and it's an unmapped page. Most accesses out of bounds in C have no indication at all. They just cause more trouble later on and that's how your code gets backdoored.
>but then you get performance overhead and memory slop because the string library is bloated to hell with every single unimportant use case and problem, when all you wanted to do was store a simple user name.
The creators of normal languages know that strings are used by almost every program so the creators of the language optimize strings as much as possible. C "strings" turn your simple user name into another source of buffer overflows and memory exploits.
You have posted this exact bait before. Go kys or go back to r/rust.
std::string_view
Stop changing the image hash, spambot.
Skill issue
seethe cnile
>he doesn't use perceptual hashes
Sucks to suck.
There is literally nothing preventing you from using slices in c. Just don't null terminate the array.
see
the problem is apparently the standard library
ugh
>not being able to put null into a string
wtf?
its
str[i] = 0;
thats how you put the "null terminated" in "null terminated string"
He means not being able to represent the null character in a string without it terminating the string.
ah
but then you use
struct string
{
size_t size;
char *data;
};
at which point you can no longer use your string with anything except your own code
not even the stdlib can handle your intermediate-null'd string
the C stdlib exists to trick newbies
tsmt
yeah.
but the libc sucks ass.
and null terminating your string is not a problem.
you allocate room for it in your initial string (which you should anyways)
you store the char of the end of your slice
you put a 0 in its place
you shove the "c-ified string" into the libc
get your results
replace the 0 with the original char
profit.
at which point you've added O(n) to anything that requires handing it off to an external lib
blud fr if you want it fast dont import stdlib ong, include fastlib
lil bro tryina go at standard speed lol no cap :skull:
>le big o notation
do you only know what it means?
bc in practice your big sounding "o(n)" amounts to less than one tenth of a percent runtime overhead (4 cycles?maybe even 2) with most of things you might wanna call within the libc
>i can use vector operations to make it run faster, therefore good
sneed
C doesn't have the concept of vocabulary types.
no the real problem is not being able to slice strings withour copying
if you read by size instead of checking for null termination you can represent null allright.
as for opisagay's slices you can use
struct string
{
char *start;
char *end;
//size_t size; if you need it
};
>"developer" can't even imagine how to process strings without using a library
Now you know why web pages are MBs in size not counting media.
I used C for the xdg-desktop-portal for the filepicker I wrote, and the dbus library uses null terminated strings and takes ownership of them so you can't use it with non-standard string types
C is literally the best language to do fast string processing in as long as you're intelligent enough to roll your own code. Your high level language 0-copy slice is almost certainly written in C and compiled to a library that gets linked in. It obviously is not using NUL but describing the strings with structures optimized for the desired language behavior.
>t. has used C to build libraries called from high level languages in order to accelerate string processing
>Your high level language
C is a high level language too, not sure why you are making a distinction.
> 0-copy slice is almost certainly written in C
Wrong. This isn't 1885 anymore. Nobody writes new language or compilers in C. Not even C compilers are written in C.
>>Your high level language
>C is a high level language too,
Not by comparison. It's not a black/white thing but a gradient.
>> 0-copy slice is almost certainly written in C
>Wrong. This isn't 1885 anymore. Nobody writes new language or compilers in C.
Why do people mouth off like this when they don't know? I'll never understand that aspect of human psychology. Especially today with fricking Google. I mean, was this bait? Or just another example of over confident ignorance?
>Why do people mouth off like this when they don't know?
I don't know you tell me, you are one of them. Python was written in 1989. Lot has changed and C has lost its relevancy in language tooling.
>HURR MUH CURRENT YEAR
Tell us please which high level language has been implemented without ANY C/C++ libraries used in the framework or the compiler. Go ahead. Tell us. Rust maybe? Rust can implement string processing in Rust because Rust isn't as high level as something like Python and can do efficient string processing.
You can't use Python to implement Python string processing libraries (among other things) efficiently because the features that make Python "hurr high level durr easy to use derp safe" also prevent it from doing efficient string processing. Any language like that is using C (or Rust) under the hood.
Disclaimer: This is my first post in this thread.
>Tell us please which high level language has been implemented without ANY C/C++ libraries used in the framework or the compiler.
That's a bullshit question for any language that runs on a modern OS. The syscall interface is defined by C libraries. It's not stable across OS versions at the assembly level. Go tried to be totally 100% C-free and kept getting in deep shit as a result, even on Linux where this is supposedly doable.
Aside from Go, SBCL comes to mind. It's written in Common Lisp. You bootstrap it from Common Lisp. It compiles Common Lisp directly to machine code. That said, I'm sure it still uses C somewhere to interface with the OS.
>Disclaimer: This is my first post in this thread.
What an odd thing to say.
>That's a bullshit question for any language that runs on a modern OS. The syscall interface is defined by C libraries.
Don't cope, you know damn well what I was asking for.
>Aside from Go
C can run circles around Go in terms of string processing. So you have your example, but it only proves my original point.
>SBCL comes to mind.
Well would you look at those runtime files...
https://sourceforge.net/p/sbcl/sbcl/ci/master/tree/src/runtime/
>nooooo that's just to interface to the OS!
Noooo, there's a ton of code there to support the data types and core functions of Common Lisp. Including strings.
You're not going to see Python in Python. It would be vastly slower than it already is. Rust can do fast string/data processing, though C still has the edge. These "why can't C do X?" threads are pure bait. X is probably done in or supported by C. If you want zero copy slices in C, implement it yourself or find a library that does it for you.
>samegay doesn't know shit about string processing, frameworks, compilers, or bootstrapping
Probably a jeet.
Just take the L and move on bro. You learned today Python isn't new.
>nobody has touched python since 1989
kek
>no examples
Take the L and move on bro. You know jack shit about any of this. You're bragging about "muh X language slice function is better than C" when C was used to write your slice function.
>nobody has touched python since 1989
Bro python was written in C because it was written in the previous century. I understand you thought it was some new language but why is your ego too big to take an L and make it an educational moment for you?
python isnt new
>cnile brainlet eats his own word in yet another display of self-own: episode 91
uhm cbros... I was only looking it up as a meme but..
>MIT license
>cucking yourself because you hate stallman
Why don't they use the GPL?
commercial license friendly
>GPL license
>cucking yourself because you love stallman
People who use rust love mega corporations and support the political status quo.
GCC hardly uses any C++ features. Have you ever looked at its source? LLVM I'll give you.
For now, C++ is a cancerous rott that slowly spreads.
>Your high level language 0-copy slice is almost certainly written in C and compiled to a library that gets linked in.
Rust and C++ self-host this. Haven't used C++ but it's fantastic in Rust, can probably manage the things you're thinking of
kys
Who are these kalemales?
The gods of computing.
Your god looks like low T söyboy numales.
C is a byte-pusher language, not for the actual logic.
This abdication of the role was done decades ago when Obect-Orientation and high-level languages became real (as in, you can run them on a regular computer from the dollar store)a n2y
Because "smart" save space, choice string as char arrays with last character is choice by null.
Then programmers must do array processing with null fails, silent O(n^2) problems and array out bounders, dozens of thousands of different string implementation as char array plus size.
But but but save space a single integer.
Any competent c/c++ codebase will use it's own internal string slice type and only convert to null terminated when it absolutely needs to (interfacing with other libraries).
Rust trannies cannot comprehend this because they worship the language and it's standard library and can't imagine not using part of it.
> use it's own internal string slice type
Which is basically pointer and length, which Rust uses.
Yes, that's my point, but rust zealots will insist c forces you into null terminated strings, which it doesn't, you can use the same thing as in rust.
C zealots say char* is "all you need" which is not true if all you are doing is mimicing what superior language does.
no one says this
I say and I look like this
movie
char *
int
let me guess...
>char *
>int
So, rust?
>rust
>raw pointers
if you wrap everything in an unsafe block, rust is almost as good as c
ok nerd
jai fixes this
>by being a vaporware made by some irrelevant eceleb to collect cult coins
I think you mean treasureware made by some eternally relevant celebrated software developer as a free gift to mankind
>totally not a cult
>strings
bloat
It's basically boomers having Alzheimers. They keep forgetting things and shit in their boomer diapers
because C is 30% more memory efficient than Rust and about 10% faster.
they have figured it out 50 years ago, the rust trannies haven't.
Source?
Switch to cpp or git gud
C strings are faster
>can't slice zero copy
>faster
NPC broken radio