How do people still use this garbage.
>>108973005skill issue. stick to GC languages if your brain is too small. p.s. properly written C programs have an order of magnitude less copying, and especially string copying, than average implementations in other languages
>>108973005I would go further and say that C doesn't have strings and you should avoid using the C library, and specially the C library functions for strings.
>>108973005C strings are stupid simple.It's disasters like strings in python that are batshit insane.Unicode and UTF-8 are fucking memes when it comes to builtin functionality and source code. Use or write a library for that shit.
>>108973005I'd rather my program seg fault than silently fail.Bruised egos have no place in correct programming.
>>108973005Smart people don't use C strings except to interface with stdlib functions / the kernel. Even when writing C.Retards think they are "smart enough to use them right and never make mistakes" and since MANY C developers are fucking retards, we're in the situation we're in where every time a C developer starts a line with "char buf[", you just KNOW there's an exploit there.
They're kinda lame, but I got really used to them. I actually started looking at alternatives after watching tsoding's video on string slicing, lol. One scheme I came up with is basically just that: Pre-allocate a string memory pool, (a linear array), and every string struct contains the string length and the index of the string in the array. Kinda simple but I can build on it pretty easily. I mean strings are already a solved problem so I could technically just pull in a string library, but who needs that? Building stuff is fun, right? >>108973021>skill issue.r*ddit post.
they say null pointer is the million dollar mistake.I think not. it is the null-terminated strings.
>>108973101use a struct if you have a problem with null terminated strings
>>108973076that's the exact same shit as keeping pointers to heap allocated memory, except MUCH worse. you don't understand memory. I mean the array thing, keeping length is fine and very common
>>108973120Stop turning everything into a VLA.
>>108973120Making a custom fat string type has always come back to bite me in the ass. C doesn't have strings so a char pointer has numerous interpretations depending on the library/API/use case
>>108973005They are literally the most portable option.
>>108973135Who said anything about VLAs?Also, those are legit warts on the language that never should have been introduced.
>>108973152The strategy with strings is to turn them into a VLA and skin walk class memory allocation with macros.
>>108973224for (You)
>working with win32>takes utf16le buffer>windows literally tells you the written length >windows STILL NULL TERMINATES it anyway I just don't understand it.
>>108973046>Unicode and UTF-8 are fucking memes when it comes to builtin functionality and source code. Use or write a library for that shit.I'm pro-C and C23 literally has proper support for UTF8
>>108973254Windows hates C
>>108973254every design decision in windows is based on taking/buying a previously existing mostly well thought out use and then making baffling modifications to cause incompatiblities
>>108973067>I'd rather my program seg fault than silently fail.LARP alert.
>>108973005types are an abstraction, C should get rid of types and just let you manipulate raw registers and bytes
Use case for strings?
>>108973300Install a signal handler if you absolutely must keep your program alive after it's known to be in an inconsistent state.
>>108973305I *NEED* human-readable text in my program. I'm *SCARED* and *FILTERED* by manually decoding raw bits of data.
>>108973303You absolutely can manipulate bytes in C. And registers make no sense, the entire point is for code to compile on multiple architectures. And new extensions and instructions are constantly being added with each new generation, particularly SIMD. By writing C code, you benefit from the occasional free performance boost from new SIMD instructions that the compiler may automatically optimize your code into.If you want to use registers, write assembly. I don't think you know what registers really are or how they're used if your suggestion is to add registers to C.
>>108973331>he thinks segmentation faults guarantee memory safety
>>108973068how do I write CLI programs in cli without them?
>>108973391>except to interface with stdlib functions / the kernel
>>108973391You use a proper string library instead of c strings. Easy. Maybe even ropes instead of strings.
>>108973005ITS ZOZZIN TIME!
>>108973374C compilers notoriously suck ass at vectorization, which is why multimedia software commonly write all the routines that can be accelerated with vectorization by hand in inline asm or in a separate assembly subroutine file to be assembled into an object to be linked with the main C program.
>>108973374What I'm suggesting is to get rid of int, long, short, char, float, double, ...etc and replace them with a byte or bit type, something like thisbyte2 var = 204;to put 204 into the variable var of size 2 bytes, the reasoning for this is that it gets rid of a lot of casting nonsense.Another advantage is that there is now no confusion about the size of a variable (think about how int, long and short are different sizes depending on the architecture and operating system)
byte2 var = 204;
>>108973448This is slightly insufficient. For example, floats sometimes get loaded on fpu's which are different register sets, and need to be moved back and forth between units (so you can't just declare a float2, let's say, and start doing things that are not available on your arch's fpu but only on its alu).Anyway, learn forth and assembly language.
>>108973448this would force you to specify manually the overflow/underflow intent for all operators, like whether 3 - 4 is -1 or unsigned underflow (well defined behavior in C).The reason for unsized int in C is compatibility reasons, as older machines had various sized integers, like 16-bit ints on the PDP11. The reasoning is that int should be a fast, natively supported, signed integral value.You could definitely force 64-bit integers to be used on 32-bit machines, most compiles will happily emulate 64-bit integers, but you would lose performances when you don't need your integers to occupy 64 bits.Also, float and double aren't specific to C, they're standardized types (IEEE754). On most processors, they occupy separate registers (st1-8 and xmm/ymm/zmm) from integers and every major OS has a special calling convention for floats because of that.
>>108973135Null terminated strings are by definition VLA with a sentinel.You unironically need a struct to avoid it.>>108973101It's not actually sin of C, because as anon pointed out, you can just use a struct instead.It's actually a sin of UNIX.Null terminated strings are "difficult to avoid" because the UNIX API is built around it, by design, for pipes and streaming.C made it the default because C was made for UNIX. But nothing stops you from making a struct instead.
>>108973076This is just arenas. EVERYONE who uses C strings needs to just read up on Arenas because your segmentation fault problems stop existing if the entire pool of memory is yours.
>>108973486This, every system programming language needs to support 0-terminated strings at one point. Not just to interface with C libraries, but because UNIX system calls require 0-terminated strings. In practice that means that non-owning containers, like slices in rust, or spans in C++ cannot be used for making system calls.
>>108973501based retard
>>108973005Every kernel and library interface uses them. There is no escape.
>>108973415that's propaganda if I'm honest with you. they're pretty fucking good at vectorization nowadays considering how messy real world CPU code often is. in release builds there's a very high chance many parts of a program will be vectorized by the compiler. in practice perfect auto vectorization is impossible because of assumptions the compiler has to make, but it is good enough to be extremely useful stillcodecs, and video codecs in particular, are one of the exceptional niche scenarios where manual assembly is worth the effort anymore. but regardless, the point I tried to make is that you can abandon your code for decades and it'll still be fast and up to date with new simd instructions in places where it matters the most, aka tight loops. you can disappear for 30 years and maybe by that time ARM or some other ISA overtakes x86 and it'll still be fast with a single portable implementation. you get the ideaif a library that's not video related says it contains custom simd code it's a red flag, it's literally snake oil and you should probably avoid it. im not joking. see: google's hash table alternative thingy, it did not age well
>>108973584It's ok to be clueless about these topics, few people understand them. But then why the fuck would you think it's fine to post about them? Read a book and stay in your lane, junior.
I'm too retarded to use a language that doesn't have strong type safety, but I refuse to learn the fucking borrow checker and it's implications for the type system that Rust has. And also, the compiler and runtime should take care of all that autistic memory safety shit. Therefore, I love Scala.
>>108973448just use stdint.h?There you have things like int8_t, uint32_t etc
>>108973448ever heard of fixed width integer types or are you trolling? https://en.cppreference.com/c/types/integer>inb4 this and that typedef are not guaranteed to existyes because C is, for better or for worse, designed to be neutral or "portable" to an autistic degree, in practice this never really matters, nothing can save you from rewriting some code when platform differences are too big. basically if one wants to be pedantic, the C standard in theory allows exotic architectures that don't exist anymore that any modern language would never supportthere is very little casting required if you do things properly, idk what youre talking about, just be careful with unaligned pointers, those are UB
>>108973135>Stop turning everything into a VLA.Yet another case of skill issue.VLAs are great, especially as they make c++fags and rustroons seethe. It's glorious to see!
>>108973686>>108973675Clinically retarded or merely pretending?
>>108973139why would a char pointer not be pointing to a char? Im not a C dev but isn't this just pure incompetence?
>>108973005ha, ha! c strings go brrrrvoid strcpy(char *dst, char *src) { while ( *dst++ = *src++ );}do you see how concise and elegant it is, kiddo?
void strcpy(char *dst, char *src) { while ( *dst++ = *src++ );}
well, guess what.. they dont exist!"strings in C" is an outdated bait for retards, those times when char'acter arrays were thought enough and even those those times when they planned to have "char" type of variable size.. the meaning of "char" type became a nonsense long long time ago. its not a character!and guess what, retard, its all got back to byte sequences, because that char experiment has failed>>108973101the dude who said that does social statistics (Alan Kay), i watched his video. i also use 0, because.. guess what, retard, zero is what they call NULL, hehehe. though it can be of different size.determine me this NULL retard: {}, kek, you cannot, hehehe>>108973224you dont even know what VLA is, retard. VLA is for stack allocations, its not about "strings". its a stack allocator, retard, it allocates uint32_t four[4];// 4x4 bytes, not four as it says, retard. have to know things before talking.
>>108973610What's your argument? Are you aware that for example a naive hash table in C without any explicit SIMD intrinsics is currently faster than google's absl::flat_hash_map? See at https://github.com/abseil/abseil-cpp/blob/master/absl/hash/internal/hash.cc they try too hard to be cute. It's overengineered. I have not done in-depth profiling to tell you exactly why, but I bet the compiler is smart enough to autovectorize C code and possibly even use *better* newer SIMD instructions because there are a gazillion SIMD instructions, the newer ones tend to be faster. If you don't babysit your SIMD intrinsics everywhere and update your code accordingly with #ifdefs for each possible set of supported extensions, you may end up with a slower program after some time has passed if the user has a newer CPU.Maybe you are just projecting? Idk
>>108973280You say that but in C++, I'd just take the buffer of "widechars" and the length and just pass it into the string constructor and move on. Windows made concessions literally to cater to C ABI, probably because C as an ABI is dead ass simple than expecting everyone to interop with C++isms.
>>108973715A pointer to a character doesn't always mean there's an array of characters after it.
>>108973005>C strings are terriblethey cheap
>>108973855> interop with C++ismsIts not even possible to interop with c++. C++ ABI is not stable or portable.
>>108973518based retard
>>108973828based retard
>>108973518he's right>>108973610he's right/g/ has become a bunch of nocoders from the sharty
>>108973382not at all. but if you do seg fault and aren't programming something that expects seg faults, then you know for sure you fucked up.
>>108973501yeah but have you considered that sharing is caring, huh? doubt you can form a cohesive argument against that idiot
>>108973873Then there should be different types for the 2 cases
>>108973989sharing is caring but when I try to share memory it segfaults.
>>108973139Sounds like your working memory is not good enough to infer from context which strings are owned and which ones are not. That's ok anon, not everybody is equally as bright.Maybe have two separate structs, one containing a const char* instead of a char*. Name the const one something like string view, and the other one string or counted string or something. This is pretty similar to how C++ and other languages do it anyway, std::string is mutable and owns its data while std::string_view does not, and both store the length regardless. Not storing the length is pretty stupid because strlen() is O(n) by itself so it's problematic. The length is used too often and it's too useful to not be stored directly. Assume owned strings are null terminated, while views to a string are not guaranteed to be. Simple as.
>>108973486>Null terminated strings are by definition VLA with a sentinel.where the fuck did you get that retarded idea?
>>108974003then you're not good at sharing, try being more empathetic about the other processes's personal space
>>108973952At least you know who you are. So help this place get better by never coming back.
>>108974062what's the problem with the gif , goldson?
>>108973989Here's an excellent write-up on memory arenas explaining why using a string memory pool as a linear array is the same as just allocating an arena on the stack: https://medium.com/@sgn00/high-performance-memory-management-arena-allocators-c685c81ee338 except the arena automatically frees itself once it leaves scope reducing the chances of memory leaks. I also had one that explained the differences in types of memory allocators. As there are instances where you would want to use an arena vs individually tracking objects on the heap. I don't have it right now, but it explains how your idea of setting a linear array is already handled if you use arenas, as you can use this memory space for safety as well, you can find examples of this anywhere if you want to use 'safe' string libraries:https://github.com/mainak55512/CString
>>108973005I tried to store my genitalia as a C string and now I'm a girl.
it's super simple, in fact I will write it all in binary to show you, brb
>>108973875this
>>108973973You might actually be the most retarded person on this board. You clearly have no idea what you're talking about. Go ask Claude what a segmentation fault is.
what if a string contains multibyte characters?
>>108973699>no argument
>>108974211If you need UTF-8 your project is too complex for C.
>>108974217>unironically clinically retardedHO LEE SHITMY SIDES
>>108974080*overflows your buffers* :3
>>108974203when a program accesses a page that the MPU hasn't granted access toseg faults have granulatity of pages, so yes, you can still make bad access, but short of buffer overruns, the chances that you access a page you have been granted access to is smalli don't use ai for anything because i have a brain and choose to use it
>>108974203He's right, though. A bug that causes a segfault would just silently produce a wrong result in allocated memory.
>>108974211then you start running plan9, it's libc has utf-8 runes baked in
>>108973568>Every kernel and library interface uses them. There is no escape.Exactly. C is not the problem, the problem is that UNIX is shitty. C is actually a superior alternative to assembly language.
>>108974103The line:“it’s super simple, in fact I will write it all in binary to show you, brb”is basically sarcastic or meme-like.What they likely mean is:They’re claiming something is very simpleThen immediately contradicting that by saying they’ll explain it in binary“brb” = be right back, implying they’re about to do something overly nerdy or exaggeratedSo the joke is usually one of these:Ironic overcomplication: “It’s simple” proceeds to make it ridiculously complicated (binary)Tech/hacker stereotype humor: acting like converting everything to binary makes it clearerSometimes also a troll/bit where they pretend to be about to post something but just leave insteadIn short: it’s not meant literally—it’s a playful way of saying “this is simple, but I’m going to act like a fucking retard for humor.”
>>108973505Slices/Spans should be fine if they are bag of bytes that end in \0. There are also special string types meant for exactly this.
>>108974370chat, is this true?
>>108974073I was arguing in bad faith, but that's interesting, if you remember how the other one was called please lmk
>>108974385can do, I'll look for it
>>108974226If you're right and everyone else is wrong, surely you'd be able to tell us whyThough doing everything to avoid that is also an answer in a way
>>108974379If AI says it then it must be true.
>>108974016from arena gladiators and string memory pool. read my incomprehensible wall of text btw
>>108974370This is like explaining why the chicken crossed the road
>>108974379Instead of saying fucking retard it said tech genius but pretty much
>>108974220use the "i hate Unicode" script
>>108974211use the "i hate Unicode" script >>108974776
>>108973005>How do people still use this garbage.No one uses C
>>108975138>No one uses Ceverybody use tcc.exe cose it memory safehttps://desuarchive.org/g/thread/108770946
>>108973005>nooo i can't grab the knife by the blade it cuts my handget a job at the circus, nocoder.
>>108973129>that's the exact same shit as keeping pointers to heap allocated memoryAnd? Heap bad, pointers bad? You're dumb.
>>108973698Yet another case of r*ddit post. But yes, VLAs are good.
>>108973005skill issue.\n\0
>>108975138>he doesn't do low level programmingpeople like me bend over backwards to provide stupid fucks like you C bindings in pyshit
>>108973135how is VLA implemented, anyway? i assume it's sub from SP following func prologue, so located on top of locals/temporaries, but then how are the compile-time offsets those locals/tmps on frame adjusted at runtimeor is VLA data just located on the frame below locals?
>>108973005c doesn't have strings
>>108975474it's not hard to set up the stack at runtime, it just takes knowing what size the arrays are and doing some arithmetic
>>108974113>jealous, white boy?
>>108975487>but then how are the compile-time offsets those locals/tmps on frame adjusted at runtime>is VLA data just located on the frame below locals
>>108975639the compile time stuff is certainly firstthe run time stuff likely has offsets/pointers on the stack to the appropriate stack offsets/addresses, although i've never examined the assembly generated for VLAs personally (since i don't use VLAs)if you are familiar with assembly, it's not hard to come up with ways to implement it
Nah, they're literally fine thanks to C99.If you're dealing with strings enough for their annoyance to bother you, then you're using the wrong language anyway and you should tinkertroon with something else.
>>108973021copeUNIX strings just plan suck
>>108973046Actually, you need a library to use strings because there is no such thing as a C string.
>>108975737ascii is the white man's encoding for building systemseverything else is extraneous
>>108975742"this is a string literal in C"you can safely stop parroting whichever youtube eceleb you fellate
>>108975744here, i'll even link you to the standard's definitionhttps://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf
>>108975742oops, off by one error and the anchor wasn't includedhttps://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf#subsection.6.4.5
>>108975742>there is no such thing as a C stringhttps://doc.rust-lang.org/std/ffi/struct.CString.htmlHeh, checkmate, atheist.
>>108973005
>>108974523Have you tried...... reading?>apples are fruits>have you considered eating tomatoes? You didn't know about tomatoes did you? What about tomatoes huh?Great """argument""", cletus.
>>108973483how can i learn more about this and know it from the top of my head like you
>>108976505program Cread the old unix booksrtfms
>>108973005Just use C++ retard.
>>108973005Bro is scared by arrays.
>>108976788to be fair, arrays are the most tricky part of C, odd as that sounds
>>108973699certified clinical
>>108976123kek, FFI is abomination. rustrooners didnt figure out strings in C yet. here they will find an education, hehehe. ye, sorry, no strings in C today! only string primitives left.what are primitives? like "literals">>108976731c++ have strings neither. wow
