How does it make you feel that every time you do something basic like File::open(some_path_to_file) Rust actually has to do a heap allocation and copy the entire string just to add a null bite at the end because C screwed you over 60 years back with it's null terminated string nonsense and Unix kernel apis still demand it?
File::open(some_path_to_file)
At least I'm not on Windows where it needs to be converted into UTF-16
It feels good because in C++ it's just char* buffer::c_str(){ reserve(size_ + 1); data_[size_] = '\0'; return data_;}
char* buffer::c_str(){ reserve(size_ + 1); data_[size_] = '\0'; return data_;}
>>100175979One more Rust brainlet filtered by C strings. Many such cases, I've come to the conclusion that HRT rots the brain
>>100176055https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page>As of Windows Version 1903 (May 2019 Update), you can use the ActiveCodePage property in the appxmanifest for packaged apps, or the fusion manifest for unpackaged apps, to force a process to use UTF-8 as the process code page.>Until recently, Windows has emphasized "Unicode" -W variants over -A APIs. However, recent releases have used the ANSI code page and -A APIs as a means to introduce UTF-8 support to apps. If the ANSI code page is configured for UTF-8, then -A APIs typically operate in UTF-8. This model has the benefit of supporting existing code built with -A APIs without any code changes.
>>100175979Who gives a shit. Opening the file itself is magnitudes slower than a heap allocation
>>100176171C strings are objectively brain rot, I'd understand if they hid string length behind the pointer somewhere but they didn't bother to do even that.>run program with strace>grep strlen | wc -l>99999999999999999999997mfw
>>100176171>I've come to the conclusion that HRT rots the brainThat explains null-terminated strings.https://en.wikipedia.org/wiki/Mary_Ann_Horton>Mary Ann Horton (born Mark R. Horton, on November 21, 1955), is a Usenet and Internet pioneer. Horton contributed to Berkeley UNIX (BSD), including the vi editor and terminfo database,[1][2] created the first email binary attachment tool uuencode, and led the growth of Usenet in the 1980s.[3]>In 1981, Horton became a Member of Technical Staff of Bell Labs in Columbus, Ohio. At Bell Labs she brought parts of Berkeley UNIX to UNIX System V, including vi and curses; as part of the work on curses, she developed terminfo as a replacement for termcap (most of this work shipped as part of SVR2).[7] In 1987 she joined the Bell Labs Computation Center to bring official support for Usenet and Email to Bell Labs.>Horton's 1990 book, Portable C Software[18] became a popular reference for programming in C.[citation needed] It outlined functions and programming techniques that could be reliably used on many different types of computer systems, and which methods were unportable.>Horton is a transgender woman. Adopting the name Mary Ann in 1987, Horton founded Columbus' first transgender support group, the Crystal Club,[20] in 1989. In 1997, she joined EQUAL,[21] Lucent's LGBT employee resource group, and saw the value of being "out" at work, supported by an Equal Opportunity (EO) nondiscrimination policy. At the time, no major company included transgender language in their EO policy. Horton asked for its inclusion in Lucent's policy, and recommended the language "gender identity, characteristics, or expression". As a result, Lucent became the first large company to add transgender-inclusive language to its EO policy in 1997.[4]
>>100176303gem
>>100175979It makes me think Rust is retarded for reinventing the wheel with its """"zero cost"""" abstractions.it can't even alloca(), it has to go to the heap? What a fucking joke.
>>100176351>allocaworthless function>DSTLLVM doesn't even support this since it's a toy and real men use GNU Compiler Collection so you can't even blame rustroons for this because LLVM is the only troon backend that exists.
>>100176216cope
>>100176351dumb retardhttps://web.archive.org/web/20230220014755/https://blog.joren.ga/vla-pitfalls
>>100175979Skill issue.Only allocates if path length >= MAX_STACK_ALLOCATION witch is 384 bytes. If somehow there is a use-case where this measurable (not a bottleneck, just measurable) before hitting open descriptor limits, you can compile custom std with a bigger MAX_STACK_ALLOCATION limit. Tooling actually exists to make this a trivial step.
>>100176453>So the programmer must ensure that aVLA size doesn't exceed some safe maximum, but in reality, if you know safe maximum, there is rarely any reason for not using it always.OH NO NO NO cnilesisters...
>>100176476>safe maximumyou mean like PATH_MAX? Even better, and even less reason to use the heap.
>>100176453try actually reading the articles you post instead of regurgitating what you have been told without applying critical thought
>>100176604PATH_MAX is gay and retarded and shouldn't exist albeit.
>>100176148You still have to copy the data if the string be used elsewhere.I would assume the Rust compiler is capable of optimizing it re-using the buffer if it not be used elsewhere and it's passed as ownership but I'm not sure how smart it's about that either. open takes an AsRef<Path>, I'm not sure whether if it be passed a String, the compiler is smart enough to be able to reuse the buffer or whether it still copies it.
>>100176216It's just an example of how many things need the entire buffer copied to interface with a Unix kernel for historical reasons.
>>100176676the only case I can think of is argv array in which case it's already nul terminated, but you have to remember that this only works in C
>>100176722Only in a shitty language like Rust whose abstractions don't match the underlying platform.
>>100176742>Only in a shitty language like Rust whose abstractions don't match the underlying platform.Null-terminated strings don't match the underlying platform.
>>100176763The platform is POSIX and POSIX uses null-terminated strings for everything.Not a problem for C or even C++. Just Rust.
>>100176763except there's no platform that isn't written in mindbroken C which always uses nul terminated strings so it matches every single underlying platform
>>100176742No anon, you need to constantly copy in C too for this reason.C constantly needs to make a copy of strings to pass string slices around.Rust is only as bad as C where it has to interact with it. C is his bad everywhere.
>>100176656It's not even a real limit. lmao.
>>100176790Yes, there should be no limit, I see no reason to prevent me from naming a file>my ancestry tree which contains descriptions about my ancestors whose names are <20GiB of string missing>
>>100175979The kernel will always make a copy of (security-relevant) user data like file names. Doesn't matter what format is used to store the strings. Windows kernel strings aren't even null terminated, they're pointer + length.
>>100176776>The platform is POSIX and POSIX uses null-terminated strings for everything.POSIX is not a platform. It's Unix brain damage forced on people by government mandates.>Not a problem for C or even C++. Just Rust.Just everything that is not C or C++. Most languages can have null characters in strings.>>100176777C is not the platform. C and POSIX ignore how the platform works.
>>100175979you have no idea what you are talking about lolol
>>100176835>rustranny doesn't understand that Rust's underlying platform is C
>>100176807I wasn't joking or saying it shouldn't exist. It's actually not an enforced hard limit. Paths that exceed it can be created. Look it up.
>>100176852So is everything's underlying platform. Any program will ultimately interact with its host environment through a C ABI and C function calls to a C standard runtimePretending it is otherwise is as credible as pretending you are a woman.
>>100176849They do actually, sans the always allocating part, as I explained in >>100176468.You can easily check that yourself jumping through definitions in a rust-analyzer enabled environment.
>>100176852>>100176913You don't need any C on your computer. It's not an underlying platform.
>>100176627>no argument
>>100176936they are put in data you ignorant fags, even my garbage compiler put together in a couple of days had that feature because it is much easier than pasting a block of code
>>100177007Not sure what you're on about. The open call chain ends up here:https://doc.rust-lang.org/nightly/src/std/sys/pal/common/small_c_string.rs.html#23
>>100177221retard
>>100176453This wouldn't be a problem if OS dev niggers woke the fuck up and noticed that we're on 64-bit systems with virtual memory now, and have been for twenty years.
>>100177355>OS dev niggers apparently didn't notice the thing they had to implementanon I...
>>100177479Explain to me why the default stack size on Linux is 8MB if it could as well be 8GB with no downsides.
>>100177528ulimit -s unlimited
>>100177528explain why your low IQ nigger problems cannot be solved with one ulimit command
>>100177547>>100177551>my code has no end users
>>100177616>I don't code anything except fizzbuzz
>>100177616my end users know how to use ulimit but even if they didn't it wouldn't be a problem because 8MiB is a bit too much for every single program I ever wrote and I am talking about total memory usage, not just stack.
>>100176852Sasuga brainlet. Ciniles are always ready for the most unhinged takes in programming.>>100176216This
>>100177688>something is slow>let's make it slowernever doubt trannies
>>100177741>>something is slow>>let's make it slower>never doubt tranniesThat's why C trannies have to read a whole string to the end to find its length. See >>100176303
>>100177741>>something is slow>>let's make it slowerAnd that's precisely how we got null terminated strings lmao.
>>100177783>>100177798and then rust trannies pretending it's ok to heap allocate for no reason on top of that because it wasn't slow enough
>>100177837>heap allocate>for no reasonOh no no no
>>100177837>for no reasonThe reason is that Rust has to deal with the shit brain damageg Unix weenies have produced.
>>100177853>>10017785699% of filenames in my C++ programs come from argv which is already nul terminated and I avoid using std::filesystem::path unless I need to modify it in some way and basicallly I actually never allocate for no reason while you cannot say the same because your trannylang is shit by design.
>>100177900>I don't write anything beyond 100 loccool
>>100177936>beyond 100 locin C++ code, main function is 100 loc just before you setup any error handling machinery, not that you would understand.
>>100177900>basicallly I actually never allocate for no reason while you cannot say the same because your trannylang is shit by design.Reading argv and opening files specified from it won't cause any heap allocations in Rust.
>>100177950NTA but yes I don't understand. Setting up error handling takes 10 lines in main in my rust project. Plus 20 lines helper function to display native error dialog box and print the backtrace to the stdout.
>>100177966reading argv by itself causes heal allocations because your language is that shit.>>100177990Rust doesn't have proper error handling, it's just C if err brainrot as usual.
>>100177966wronghttps://github.com/rust-lang/rust/blob/master/library/std/src/sys/pal/unix/args.rs#L135
>>100178005you don't need to read code, documentation admits that it's shit, there's literally 0 reason why they needed to make String instead of &str or whatever, the string length is calculated either way.
>>100178023>admitsdumb cnile, the reason Rust has to do this is to counter the Unix brain damage
>>100177998>reading argv by itself causes heal allocations because your language is that shit.It doesn't. Git gud.>Rust doesn't have proper error handling, it's just C if err brainrot as usual.Sasuga brainlet. Another unhinged take from a cinile.
>>100178033>counter brain damage by allocating memory for no reasonthat sure showed them, tranny
>>100178042Anon, C has to do this all the time too.C constantly has to allocate new memory to make a slice of a string and Rust doesn't have to with ownership either, in which case the null byte can be pushed to the end which may, like in C, require a reallocation.It's just one case where Rust is as bas as C is all the time, because it needs to interact with an insane interface originally specified in C.
>>100178121I don't allocate memory that already exists, argv is already nul terminated string, I can already pass it to syscall that will open the file or whatever, keep coping tranny, C++ is objectively superior, its abstractions are actually 0 cost if you pay cost of using your brain. Rustroons will forever only envy this.
>>100178155>C++ is objectively superior, its abstractions are actually 0 costC++ doesn't even have destructive moves, it can't even have zero cost shared pointers/Rc.
>>100178199>muh heckin moveseternal cope for subpar programmers, all of my code is written as if everything was Pin<T>.
>>100178218Sounds fine if all you are making is fizzbuzz.
>>100178277or maybe highly optimized code, not that you'd understand what it means to purify the problem and implement a specialized solution that allocates once, does all the work at once and then quits without hammering allocator or filesystem thousands of times at random the way your tranny projects do
>>100178291Nice, soon you will discover #[no_std]
ITT: Galaxy brain who is both pretending to write code that would be bottlenecked by *meh argv*, and doesn't know that Rustaceans can talk C (or syscall, or assembly) from within Rust if they want to.
>>100178303don't forget import libc because rust trannies cannot do anything without C
>>100178316#include <cformypeepee>
>>100178314>if they want toConsidering it requires giving up le safety, they don't, so it never happens, and their code is shit and unoptimal.
>>100178441>unoptimalYes. Crippled by argv cloning. IT'S OVER.
>>100178514rustrannies also cannot reorder argv manually so optimal argv parsing is also out of grasp
>>100178551>optimal argv parsing
>>100178560yes, for things like commandline tools where responsiveness is important, I hear rustrannies write a lot of those because their language isn't useful for anything else, it's sad to know that they have to allocate dozens of times before their program can do anything with data that's already alive for entirety of the process...
>>100178597>Never heard of .collect(), so it doesn't exist.
>>100178621>yes I want to put those allocations into yet another allocation which is as useless as other allocations because argv** was allocated before the process beganRust software engineering surely is amazing.
>>100178635>Lifecycle of CLI tools is spent reading argv
>>100178660it's the first thing every cli tool does, that's why in C++ I wrap argv in iterator that performs 0 allocations, most expensive part of checking if long option names are valid, and occasional strlen which is wrapped in c::string_view because if I need to reallocate for any reason I will do it where it's useful since I'm not a retarded rust tranny and every allocation matters
>>100176226Length prefixed strings are awful.
>>100178823you're literally more mentally ill than rust trannies if you believe this
>>100178155Yeah, in the rare case that you're passing the exact argument you're given, which isn't that common.Now try taking a slice of it which things in practice have to do. Like a path is passed and you want to navigate to the directory the file is in.How dirname in C is specified is hilarious, to be portable one has to copy twice in practice because conformant implementations are free to:>malloc the new string>use static memory and write to that for subsequent calls in the same thread>overwrite the original input pathThus, in the case of wanting keep using the input path and the output path after, portable code has to copy both input and output to be sure, and isn't allowed to free the original return value either which can cause leaks on impementations that use malloc. So literally best case scenario is 2 copies, worst case is 3.In Rust, it's a non-copy that shares memory with the original every time.
>>100178748>every allocation mattersIf what you write is even close to being relevant and this sensitive performance wise, you would be talking about arena allocators or some other custom solution. You probably don't realize it, but what you write sounds like a joke. You are either a full on pretender, or an autist who also suffers from grandiose delusions.
>>100178855>which isn't that common.speak for yourself, I talk directly to the OS, when I even have one.
>>100178155Yeah, in the rare case that you're passing the exact argument you're given, which isn't that common.Now try taking a slice of it which things in practice have to do. Like a path is passed and you want to navigate to the directory the file is in.How dirname in C is specified is hilarious, to be portable one has to copy twice in practice because conformant implementations are free to:>malloc the new string>use static memory and write to that for subsequent calls in the same thread>overwrite the original input pathThus, in the case of wanting keep using the input path and the output path after, portable code has to copy both input and output to be sure, and isn't allowed to free the original return value either which can cause leaks on impementations that use malloc. So literally best case scenario is 2 copies, worst case is 3.In Rust, it's a non-copy that shares memory with the original every time.>>100178848They're not as bad as null terminated, but they're still awful, the length of the string should clearly not be behind the pointer.Length-præfixed still means having to copy for a slice. In fact, null terminated does not have to copy for the special case of slicing till the end, whereas length-præfixed has to always copy.
>>100178874>arena allocators for argvnew level of rustranny insanity unlocked
>>100176055Are you claiming that Rust programs cannot run on Windows operating systems?
>>100178879>have to copymaybe in your mental illness programs, in mine I only copy when I deem necessary.
>>100178155>argv is already nul terminated stringOnly on Unix systems. The C runtime has to make a copy of the arguments on every other OS.
>>100179038>only on unix systemsLinux isn't unix but it's cool that my Linux-only code would work on unix too, couldn't care about OSes for trannies though.
>>100178894>Lifecycle of CLI tools is spent (re)reading argv. From scratch. Can't store the value and re-read it.>In my tools, EVERY ALLOCATION COUNTS. Cloning argv is totally a bottleneck. Yes, it is that special.>>Yeah, very special. Maybe you should use a custom allocation solution even.>new level of rustranny insanity unlocked
>>100179075>storewhy do I need to store argv anywhere, it's already stored by machinery that started my program, dumb tranny, you literally are too mindbroken to comprehend the fact that argv is already an array that was allocated and copying it is useless
>>100179057>Linux isn't unix but it's cool that my Linux-only code would work on unix tooLinux is a clone of Unix. Some Windows-only code works on ReactOS too.>couldn't care about OSes for trannies though.Unix is the only OS for trannies. See >>100176303
>>100179118Linux doesn't even adhere to posix properly, you literally are too mindbroken to get even one thing correct.
>>100179133>Linux doesn't even adhere to posix properly,ReactOS isn't a perfect clone of Windows either.>you literally are too mindbroken to get even one thing correct.You're defending null-terminated strings like someone insulted your religion and I'm the one who's mindbroken?
>>100178925Yeah, and this is a case where it is.>I only make completely trivial code so issues don't apply to me.The post.
>>100176969You do for every operating system that is used by more than 2 people.
>>100177783How did so many trannies get into programming? We know it's all men because how many women actually program.
>>100179228>argv is alive for entire program>you need to copy, you just have to, ok?lmao
>>100176189>If the ANSI code page is configured for UTF-8, then -A APIs typically operate in UTF-8. This model has the benefit of supporting existing code built with -A APIs without any code changes.A/W split is gay, but since it's already there why not just add -8. What's the overlap of people actively developing who'd prefer to use the new utf-8 support, but don't want to update their dev env to work with the new -8 api and would rather go through -A
>>100177900>I avoid using std::filesystem::pathYou avoid using these constructs for the same reason you have to avoid variants and optionals if you want to stay sane and have performant code: you have to because these features either feature fucked APIs that don't work well with anything else, they feature outright broken ABIs which are impossible to optimize, or they completely bend your RVO over a table and make sweet sweet nonconsensual love to it until you end up deciding it's actually become more performant to pass pointers in a "just fuck my shit up senpai" moment.We've all been there anon, this is a safe space where you too can share your trauma and be heard.
>>100176226>t. still hasn't accepted NT-strings are the lesser evil out of all of themThat's all I'm saying this thread 'round, faggots.
>>100179990NT strings are retarded and in practice cause many more allocations than whatever the fuck you are complaining about.Lmao
>>100176303Where does it say that he was responsible for the NT?I refuse to believe a tranny made a sensible decision.It's ironic you trannies have to resort to using trannies as an insult to shill your retarded opinions.Lol. Lmao. Faggots.
>>100179990They are the only kind of string that can't contain all characters, so they are the worst kind of string.
>>100179922I use std::filesystem::path when I need to modify the path, there's nothing wrong with it, when I need it, something you'd never understand.
>>100179570Anon, again, we're talking about the common case of needing a subslice of it.It's extremely common to only need a part of a filepath or part of a command line argument for some reason.
>>100180103That's actually unironicaly the least of their problems because who needs nul. All the other issues are far worse.They're simply slow and inefficient and require constant copies where other implementations do not.
>>100180030>Where does it say that he was responsible for the NT?He wasn't. PDP designers/programmers at DEC were responsible for it. Trannies just helped spread it to other systems with C many years after they were already obsolete. That's why they're associated with C.>It's ironic you trannies have to resort to using trannies as an insult to shill your retarded opinions."Trannies" means people who are transgender. It's not meant as an insult. Transgender people are overwhelmingly associated with C and Unix. Replace "trannies" with "transgender people" if that makes you feel better.
>>100180189And I'm telling you that argv lives for entirety of a program, it's also mutable and since I know my program requirements I can efficiently reorder positionals interleaved between options, process positionals with only options coming before them, and god forbid, allow people to pass passwords directly to argv because I am in full control and will securely overwrite it with zeroes so they don't have to worry about leaking it through process list showing command arguments
>>100175979>How does it make you feel that...I don't really give a shit. If I'm using Rust for some task, that task probably doesn't involve opening up a shitload of files, which is where those allocations *might* add up. If I do have to open a ton of files, I'm probably doing some I/O bound task for which a scripting language like Python or Ruby might be better suited. Guess what? Python and Ruby would have to do the same thing because they don't use null terminated strings internally either. >>100176776Protip: there are languages other than systems programming languages. Nearly everything other than C and C++ is using something other than null terminated strings.
>>100180276Yeah, that's a great idea>Need to insert null somewhere to pass it to some other function that wants a specific subsection>Of course, now I need to store the original value that was there again in another variable to swap it back later when another function needs another subsection>This is efficient>This creates remotely maintainable codeAnon no, this is retarded programming enforced onto you by the madness of null-terminated strings at best. In other languages you can simply take a slice without modifying the buffer and having to undo that modification.
>>100180379>store original valueI already know position and character I replaced, it's literally free, anyway not my problem, all of my code is written like this, not just argv parsing, that's why usually my C++ programs are faster than C, even when exceptions are thrown.
>>100180406>I... I just need to constantly allocate space everywhere to remember the original position and the character to put it back>This is not at all a massive issue in effort and readability to cope with not having sane string slices.Anon, programming like this is completely insane and isn't necessary in a sane language.
>>100180849>allocatespace is already allocated, seems like you're so mindbroken you cannot handle simplest of problems
>>100180951Anon, no, you don't normally allocate random stack space to swap out and store characters to revert them later.
>unironically using rustlol
i hate rust so much, basic rust programs will take 5x longer to compile than the linux kernel. yeah there's nothing wrong with pulling 60 crates for every fucking thingoh and a "hard" dependency on llvm fucking niggers get a working compiler already
>>100182386There is a GCC frontend for Rust now by the way.No idea how much it lags behind in features and performance behind the official one though.
>>100182400my guess: currently shit, will eventually become the better implementation by virtue of avoiding LLVM retardation
>>100182400The GCC backend for rustc is much closer to being usable, but it's still way behind the Cranelift backend
>>100182107Yes, I dont see the problem.
>null terminated strings breaks rust mindsYou know, I always thought null termination was a mistake. But now that I see it creating rage and seethe among rustrannies, I love it.
>>100182475>You know, I always thought open borders was a mistake. But now that I see it creating rage and seethe among Trump voters, I love it.ORANGE CRAB BAD!
>>100176742The underlying platform was designed by people who had no clue wtf they were doing. There will eventually come a point where rebuilding everything from the ground up becomes preferable than continuing on with layers upon layers of technical debt. The sooner that point comes the less painful it will be. If the foundations are unsound then everything built on top of them will be unsound.
Rust is bad for the environment. go green, use C
>>100175979I don't get the complaint. Why would a string not have a null byte at the end in the first place? Every string in the world has a null byte at the end, unless there's some real brain damage elsewhere in the code.Did somebody fuck up the allocation for the string and not include the final 8 bits for the trailer?Also>bite
>>100182475>You know, I always thought null termination was a mistake.How else would you signal this memory area is over? I guess you could include a length int in a struct with an int* for the start address, but you would take up to 7 extra bytes on a 64 bit ISA versus a single byte for "this string is done, stop reading".
>>100184596this post is full of brain damage. null terminated strings are objectively shit. pointer and a length, no need for a nul
>>100181775>random it's deterministically one byte, you braindead subhuman
>>100177741You don't write software, you're a worthless nigger
>rustranny who cannot even write his own compiler talking about worth
>>100178748Lol
>>100185007What does being able to write a compiler have to do with this?
>>100185042well until you write your own compiler, you're stuck with the fact that I contributed to LLVM and basically my code is in your compiler now and you're literally more worthless than my worthless controbution, which is C++ code by the way, the language that you're trying to replace but cannot compile your code without.
>>100185071This is so unbelievably stupid that I'm pretty sure it tells me who you are irl
>>100185088yes I'm white, but it wasn't a mystery to anyone
>>100185071I have no problem running your code, I don’t even know you. What does all these have to do with null termination?
>>100185091Does your name start with a J? What about an M?
>>100185098when doctor looks up your health history for any reason, your genitalia status only shows up as '\0'
>>100185106Yes my first name is "Judean" and my family name is "Merchant".
>>100185110Why are you getting so aggressively mad? What’s your problem? Are you mentally ill?
>>100185144What do you mean by "mad"? I only answered what nul has to do with this.
>>100185160Its clear you are frustrated and angry and you feel safe to vent on online strangers because you feel powerless against those who wronged you in real life. My only mistake was thinking you have anything of intelligent to offer since you like to say to others that you are an LLVM developer. But alas, you are not a real programmer. Fake it till you make it I guess.I’m gonna validate your feelings by letting you have the last word out of pity. You are angry, Im not. I guess Im happier than you.
>>100185193I actually don't feel safe when mentally ill faggots like you exist, though I can cope with the fact that I have concealed carry permit and so I always walk outside with my gun, safety is off by the way.
C opted for null termination because B did not have structs and it wanted to have string compatibility with B.The cnile cargo cult brainrot infected unix and thus its still here.
>>100185323you can do it in C, just need to rewrite string.h first because every algorithm that could be efficient instead computes strlen every time.
>>100185323Its a clear regression from ALGOL 60.
>>100185354>every language's name directly maps to A to F grading systemno wonder Ada won
http://0x80.pl/articles/simd-strfind.html>cnile brainrot from 50 years ago prevents this from working
>>100185323How fucking often are you taking a substring, anyway?
>>100185711nta but it's not exactly rare
>>100176226>strace>strlenstrlen is not a syscall
>>100177528Because Virtual Address space is 48 bits and not 64 bits. Only half is used for user space, so minus one bit. 8GB is 33 bits. We are left with 14 bits which means you can only create 16384 threads.You are complaining about your shitty program requiring gigantic stack size, but some other retard will be complaining about their shitty Java web server not being able to serve 16385 connections because he creates a thread per connection.
>>100177547This only affects the main threads, not threads created by libpthread. Those must set stack size with pthread_attr_setstacksize before creation. But it doesn't help if you are writing a library and don't know the context in which it executes.Windows puts stack size info in executable and created threads can use this info, so there is some control at executable level.
>nooooo my strings end in \0 I need to dilate now to feel better ACK-
>>100177900You can't pass argv to file function on Windows because Microsoft fucked up encodings. You should get arguments from GetCommandLineW() and or start in non-standard int wmain(int, wchar_t *argv[])and only use *W functions.
int wmain(int, wchar_t *argv[])
>>100185842cilators lmao
>>100177998And you'd rather prefer exception based error handling?>oh boy I sure hope this function doesn't unexpectedly blow up in my face cause I don't recursively search it for the exceptions it throws since C++ decided to backtrack Java style throwGo back to your unserious Python scriptsAlso enjoy your UB with noexcept
noexcept
>>100186002i hate rust but anyone complaining about its error handling is a retarded typelet
>>100186015Mommy know her big girl can do better :)))
>>100176303>Cniles were the original troonsWhat a twist.
>>100185842Null termination saves a small amount of space, but requires more code and more time for the length computation. An explicit length field costs one more word per string, butmakes the length computation take constant time. I didn't expect less a retarded cnile to understand such basic tradeoffs.
>>100188612SHURRAPP. no one can bit-fiddle argv more efficiently than me using my superior ceepeepee skills. this is what peak programming looks like. y'all are trannies anyway.
>>100185729NTA but when you use a string, you use the whole string, not just
>>100176189>flip this on>applications start thrashing wildly and corrupt everything because they use narrow page APIs and are completely oblivious to how locale/code pages worksthank you Windows.
Ironically, winapis usually have the helpful property of giving you feedback on explicit sizedness of your types, downside is if you want to keep your sanity, you have to have faith that your container types like std::vector or std::Vec (in rust) have the same layout and allow for arbitrary pointer writes.but whatever. colmputers are fucking gay and poorly specified ABIs is the number one reason C is pure shit and C++ makes it worse. Not that Rust even tries to define an ABI, last effort was CRABI, but honestly no one can get out under from Winshit x64 ABI or AMD64 ABI.
>>100187064explains a lot.
>>100177837just because your allocation is on the stack doesn't make it faster, just faster insofar as cleanup is basically free.
>>100178023isn't that what https://doc.rust-lang.org/std/env/struct.ArgsOs.html is for?either way, nothing stops you from reading environ/argv yourself.
>>100184596you are a retard nigger monkey>O(n) length is le good also> Every string in the world has a null byte at the endplease get off this board, you are mentally impaired
>>100185711No use-cases for substrings?
>>100189431>> Every string in the world has a null byte at the end>please get off this board, you are mentally impairedthe irony of this, is this idiotic belief is how some attacks, like text smuggling work by tricking shitty C software from recognizing data past the NUL.
>>100175979>How does it make you feel that every time you do something basic like>File::open(some_path_to_file)>Rust actually has to do a heap allocation and copy the entire string just to add a null bite at the end because C screwed you over 60 years back with it's null terminated string nonsense and Unix kernel apis still demand it?Not my problem.
>>100185711That's probably the most common operation for strings
>>100189492Allocating them and reading them end to end is much more common. What's the point of allocating memory you're not planning on accessing in the first place?Fix your damned inputs.
>>100188612> more codeNull terminated strings actually require less code in many cases. Having the end of string be a character rather than a completly seperate thing considerably simplifies a lot of string processing code.
>>100191679LMAO.You would make a good gopher.
>>100175979It makes me feel fucking nothing whatsoever
>>100175979Using strings is a sign that you are a mediocre programmer doing unimportant busy work.
>>100184957Anon, if the language you're using actually forces you to constantly swap in and out characters of a fucking command line argument as some optimization technique to have to deal with this it's a terrible language and your code is probably unreadable to the point that anyone would say that it's better to accept the performance hit and simply copy it.Are you actually using the micro-optimization where you're swapping in and out null bytes in command line arguments to avoid having to copy a string to make a slice? Please don't tell me your code actually looks like that?
>>100175979>every time>do a heap allocation Can rust not reuse memory buffers?And this is supposed to be a serious systems programming language?
>>100175979The null byte is not just for show. It has many other uses, but from my POV which is cyber security, it's a way to minimize the risk of buffer overflows. Also if you learn how computers work at a fundamental level, AKA study logic gates and ASM, you will realize that there is literally no other way. Co puters are dumb. Actually there are many ways but they are less efficient.
>>100175979More like your language doesn't have a standard library of its own and uses C ABIsGet rekt troon
>>100193012>It has many other uses, but from my POV which is cyber security, it's a way to minimize the risk of buffer overflows.Null terminated strings are the cause of buffer overflows. Normal strings can't have buffer overflows because you can compare the length and know how many bytes to copy. This is why C is the only language that uses null-terminated strings and the only language with buffer overflows. Any time another language has a buffer overflow, it's because it's using a null-terminated string to interface with C code.>Also if you learn how computers work at a fundamental level, AKA study logic gates and ASM, you will realize that there is literally no other way.Null terminated strings make no sense if you know how computers work. If you're using assembly, null-terminated strings are worse because you can't use the hardware's string instructions. The most efficient and easiest way is knowing how many bytes are in the string before you do anything with it. Normal strings can also have any byte so you can use them for any kind of data.
>>100193121Knowing how many bytes are in the string, means you have to store the length at another memory address. it is less optimal and has a cumulative effect that makes the program slower and bigger. Furthermore you have to have a bunch of instructions that take that length and a counter for each character.An alternative way is to use a pointer for the starting and ending memory addresses where the string is stored. but then you have other disadvantages such as the fact that you cannot have dynamic memory allocation & you would need to change the pointer every time you change the string. or in the previous case to change the length of the bytes that store the string's length.For example to store the length of what I just wrote (including what I am writing right now) you would need 0x321
>>100182560>comparing null terminated strings to millions of low iq thieving pieces of shit invading in preparation of the next totally organic Floyd riotsHoly fucking false analogies Batman!
>>100193313>pic related>implying Batman wouldn't have bulletproofed the batsuit
>>100193313Addendum.Storing the length of a string in some memory address also creates a security risk.remember that for optimization programs are compiled in such a way that data and instructions are not in separate blocks, but jumbled together. therefore if I make the string bigger and the program needs to change the memory address where the length is stored, it might leak into the next memory address that just so happens to contain an instruction...
>>100193329It's a perfect analogy. One is worse security for your computer because it makes people you don't like "rage and seethe." The other is worse security for your country because it makes people you don't like "rage and seethe."
>>100193394>Storing the length of a string in some memory address also creates a security risk.>remember that for optimization programs are compiled in such a way that data and instructions are not in separate blocks, but jumbled together. therefore if I make the string bigger and the program needs to change the memory address where the length is stored, it might leak into the next memory address that just so happens to contain an instruction...That's not how computers work. Storing a bigger number doesn't make it leak into another memory address. Lisp has bignums and that still doesn't happen.
>>100193349Agreed. This is from a story called "the innocent guy" It's a short story & you can check it here:/SBg4a3MmXI8It. was published in Batman: black and white originally, where many authors were given the liberty to write stories about Batman using their own style. They tend to be unconventional. This has other stories, such as Alfred being the joker and other wacky stuff. the color version was reprinted in The killing joke: Deluxe edition.
>>100193553I did not claim that it definitely will, but that it might. Also I touched upon some other points. You would need many instructions to pull such a thing off. A null byte is simple & efficient. I don't know where you got the idea that buffer overflows are the result of the null character.Tell me how would you design a function that knows where to stop without 0x00.Make a simple "print" instruction. Go on I'll wait. You will soon realize that you need many more instructions than you initially thought. And don't give me some high level abstraction BS..
>>100184620Make the size an explicit parameter, leave it up to the programmer to decide how to store/handle it. That would honestly be better than dealing with fucking nulls.Another issue is that it should be possible to query both the remaining bytes and the total size of a block of memory given a pointer into that block, regardless of allocation method used. This should be an OS requirement imposed on languages that deal with explicit memory management. Depending on the implementation it might require the language runtime checking its heap tables and then passing the pointer onto the OS if it doesn't find it. Or the language might always directly use the OS so the call just gets passed to the OS. (In Mac OS classic, for example, there were languages where you could use the language allocator or the OS allocator, but they weren't equivalent. Passing a language allocated pointer to a Toolbox call wouldn't work if the call expected a Mac OS allocated pointer. Same issue for any type of shared memory allocated outside of the process.)Since you can't expect the OS to always do this, portable C would only be able to guarantee the functions for pointers allocated within its runtime. Still, it should be there.It would make "memory safe" algorithms absolutely trivial if you could always reliably get remainingBytes and totalBytes with a pointer. The language could include convenience functions which take type size into account, i.e. remainingSize and totalSize given an int*. Nulls are gone and unless you're an idiot you can easily avoid buffer overruns.You would still often want to require an explicit size in functions, i.e. if the caller doesn't want the entire block to be processed. So if you had a string uppercase function you want a pointer and a size to process, but you can check the provided size against remainingSize and either stop short if size was too large, or throw an error so the developer knows he has a miscalculation somewhere.
>>100193012Yes, this is why we usually use sentinels to deal with literally any other arrays that aren't char arrays...... oh wait, we don't, you fucking retarded piece of shit clown.
>>100185711Ever heard of a tokenizer?Or does your toy compiler not handle string literals? Can it even correctly handle files with \0 in the middle of them?
>>100193012Holy shit this is stupid.Null terminated strings are what led to buffer overflows everywhere. They're a massive security riskAnd yes, there are many other ways. It's not like Rust code compiles down to null-terminated strings. It's only forced to use them when interfacing with kernel C code, but all your userland string processing is done without null termination.It was an ill thought out optimization back in the day when it would save space. This was back when memory memory was far more sparse than c.p.u. cycles while currently it's the opposite and software nowadays tends to throw at performance [lol, GNUware]. But it was a bad idea back then and it's even worse on modern hardware.
>>100194904>This was back when memory memory was far more sparse than c.p.u. cyclesTo put this in perspective for people who don't know:The "core dumped" message you get when your program segfaults refers to core memory, which was HAND-MADE by sewing tiny magnets together in a grid patternEach magnet held ONE BIT
>>100195017Oh wow, C was most likely actually developed on Core memory.I thought it came much later.But yeah, memory was a far bigger concern than cycles back then so they terminated strings with null because they could, they would've done it with arrays if not that they'd like to use 0 too there.
>>100184596sometimes you might want to have a string_view, and demanding that every string has a \0 makes string_view's impossible
>>100194904>>100195017>>100195055Even on older computers it was just fucking lazy. tl;dr of this post >>100193899 is that C should have totalBytes(), remainingBytes(), totalSize(), and remainingSize() for any pointer allocated via C functions, and ideally any pointer allocated (i.e. OS shit as well).Some functions would need to return a size because they wouldn't use the full buffer. But they could always make sure they don't overrun the buffer. Then the caller could do whatever they want.>ptr going in a struct with size and maxSize anyway>call a function to resize the buffer down, which should always succeed>copy to a correctly sized ptr because the buffer will be used over and overI love C but fuck null terminated strings.
>>100195017Most computers and languages still didn't use null-terminated strings. They used a 1 or 2 byte or whole word length (depending on the computer and language) or a fixed length as part of the type. Most languages had strings that can contain nulls like any other character.
>>100193121>Null terminated strings are the cause of buffer overflows.No, retards who do not sanitize input or manage memory are the cause of buffer overflows. Null termination is massively convenient when you've done the bog standard minimum to sanitize text input.>b-but i need null bytes in my text because.. i just do, ok!literally nothing stopping you from using a struct to define a pointer and length for your char array. you can put any bytes you want in it.
>>100176189Goddamn I love the Win32 API.
>>100193012Dumbest post itt? I remember keking when some retard wrote some code that ended up using a dangling c_str ref that got shitted on by the newer gnu libstdc++ ABI and the tool ended up reading over a gigabyte of junk because retards like you think nul is somehow. In this case, a sized string wouldn't matter since it would have been just as ridiculous, but if C wasn't pure shit, maybe people wouldn't accidentally liter c_str calls everywhere to dangle and they'd just copy or expose the underlying basic_str or whatever of c++ to C's proper strings (Pascal Strings).
>>100196402Don't use it. It will break a lot of legacy shit apps in hilariously bad ways.
>>100196281What makes NUL in a string invalid when it's defined as valid in UTF8? This is the ultimate problem with this shit. For argv? Sure whatever. List of values delimited by NUL is good enough. Same for environ, but for fuck sake. If I want to put nul bytes in my fucking email, just let me you nigger. http/1.1 solved this shit with content-length effectively being required for a reason, much like what anons want in their strings with some tag that indicates the length and a value after.
>>100196281>literally nothing stopping you from using a struct to define a pointer and length for your char array. you can put any bytes you want in it.Literally nothing stopping you from having to rewrite the fucking string library in all your programs.
>>100196281>Null termination is massively convenient when you've done the bog standard minimum to sanitize text input.>can't do string splicing in place>has to scan the whole string to figure out the sizeCome on, null termination sucks.Now I'll be the first to point out that if you need extremely fast string processing, you do it in C but you do it yourself and never use null termination. I've accelerated code this way, building libraries to be called from higher level languages, multiple times. And multiple high level languages are in fact implemented this way. Their runtimes and core libraries written in C, they just don't use null termination and don't use functions that require it. Or on the rare occasion that they do, they go ahead and copy or insert nulls.But having to deal with nulls if you want to use standard library functions sucks ass. This is one criticism I'll give to Rust trannies. It was dumb and I would by happy to see it die, replaced by a better method.
>>100196281>No, retards who do not sanitize input or manage memory are the cause of buffer overflows. Null termination is massively convenient when you've done the bog standard minimum to sanitize text input.Where is null termination remotely more convenient than simply knowing the length?We're talking about: s[i] == \'0' vs i == s.len to know whether we're at the end of the string. Neither is more convenient than the other but one gives you, oh I don't know:>Zero copy slices>Constant time length calculation>No chance at buffer overflow>Ability to put null bytes into strings.It's not even a contest which is better. The only disadvantage is slightly more space used.
s[i] == \'0'
i == s.len
>>100197031>The only disadvantage is slightly more space used.It wouldn't even be that if the C runtime let you query the size of a pointer allocated by the runtime. The size is already stored somewhere.
>>100176604PATH_MAX doesn't do what you think it does. It is the amount of path data kernel is willing to accept in a single syscall to prevent DOS attack. Paths themselves are unrestricted and you can try this by creating path 100MB+ long.
