>>108973005
skill 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

>>108973005
I 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.

>>108973005
C 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.

>>108973005
I'd rather my program seg fault than silently fail.
Bruised egos have no place in correct programming.

>>108973005
Smart 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.

>>108973101
use a struct if you have a problem with null terminated strings

>>108973076
that'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

>>108973120
Stop turning everything into a VLA.

>>108973120
Making 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

>>108973005
They are literally the most portable option.

>>108973135
Who said anything about VLAs?
Also, those are legit warts on the language that never should have been introduced.

>>108973152
The strategy with strings is to turn them into a VLA and skin walk class memory allocation with macros.

>>108973224
for (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

>>108973254
Windows hates C

>>108973254
every 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.

>>108973005
types are an abstraction, C should get rid of types and just let you manipulate raw registers and bytes

Use case for strings?

>>108973300
Install a signal handler if you absolutely must keep your program alive after it's known to be in an inconsistent state.

>>108973305
I *NEED* human-readable text in my program. I'm *SCARED* and *FILTERED* by manually decoding raw bits of data.

>>108973303
You 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.

File: 1780488254001637.png (551 KB, 636x800)

551 KB PNG

>>108973331
>he thinks segmentation faults guarantee memory safety

>>108973068
how do I write CLI programs in cli without them?

>>108973391
>except to interface with stdlib functions / the kernel

>>108973391
You use a proper string library instead of c strings. Easy. Maybe even ropes instead of strings.

>>108973005
ITS ZOZZIN TIME!

>>108973374
C 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.

>>108973374
What 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 this

byte2 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)

>>108973448
This 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.

>>108973448
this 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.

>>108973135
Null terminated strings are by definition VLA with a sentinel.
You unironically need a struct to avoid it.
>>108973101
It'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.

>>108973076
This 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.

>>108973486
This, 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.

>>108973501
based retard

>>108973005
Every kernel and library interface uses them. There is no escape.

>>108973415
that'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 still

codecs, 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 idea

if 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

>>108973584
It'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.

>>108973448
just use stdint.h?
There you have things like int8_t, uint32_t etc

>>108973448
ever 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 exist
yes 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 support

there 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
>>108973675
Clinically retarded or merely pretending?

>>108973139
why would a char pointer not be pointing to a char? Im not a C dev but isn't this just pure incompetence?

File: chad.png (308 KB, 1200x848)

308 KB PNG

>>108973005
ha, ha! c strings go brrrr

void strcpy(char *dst, char *src) {
  while ( *dst++ = *src++ );
}

do you see how concise and elegant it is, kiddo?

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

>>108973101
the 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

>>108973224
you 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.

>>108973610
What'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

>>108973280
You 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.

>>108973715
A pointer to a character doesn't always mean there's an array of characters after it.

>>108973005
>C strings are terrible
they cheap

>>108973855
> interop with C++isms
Its not even possible to interop with c++. C++ ABI is not stable or portable.

>>108973518
based retard

>>108973828
based retard

>>108973518
he's right
>>108973610
he's right

/g/ has become a bunch of nocoders from the sharty

>>108973382
not 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.

>>108973501
yeah but have you considered that sharing is caring, huh? doubt you can form a cohesive argument against that idiot

>>108973873
Then there should be different types for the 2 cases

>>108973989
sharing is caring but when I try to share memory it segfaults.

>>108973139
Sounds 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?

>>108974003
then you're not good at sharing, try being more empathetic about the other processes's personal space

>>108973952
At least you know who you are. So help this place get better by never coming back.

>>108974062
what's the problem with the gif , goldson?

>>108973989
Here'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

File: IMG_3096.jpg (54 KB, 1280x720)

54 KB JPG

>>108973005
I 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

File: Drew-Barrymore-Signed-8x1(...).jpg (1.57 MB, 2400x3000)

1.57 MB JPG

>>108973875
this

>>108973973
You 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

>>108974211
If you need UTF-8 your project is too complex for C.

>>108974217
>unironically clinically retarded
HO LEE SHIT
MY SIDES

>>108974080
*overflows your buffers* :3

>>108974203
when a program accesses a page that the MPU hasn't granted access to
seg 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 small
i don't use ai for anything because i have a brain and choose to use it

>>108974203
He's right, though. A bug that causes a segfault would just silently produce a wrong result in allocated memory.

>>108974211
then 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.

>>108974103
The 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 simple
Then 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 exaggerated

So 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 clearer
Sometimes also a troll/bit where they pretend to be about to post something but just leave instead

In 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.”

>>108973505
Slices/Spans should be fine if they are bag of bytes that end in \0. There are also special string types meant for exactly this.

>>108974370
chat, is this true?

>>108974073
I was arguing in bad faith, but that's interesting, if you remember how the other one was called please lmk

>>108974385
can do, I'll look for it

>>108974226
If you're right and everyone else is wrong, surely you'd be able to tell us why
Though doing everything to avoid that is also an answer in a way

>>108974379
If AI says it then it must be true.

>>108974016
from arena gladiators and string memory pool. read my incomprehensible wall of text btw

>>108974370
This is like explaining why the chicken crossed the road

>>108974379
Instead of saying fucking retard it said tech genius but pretty much

File: Untitled.png (29 KB, 555x652)

29 KB PNG

>>108974220
use the "i hate Unicode" script

>>108974211
use the "i hate Unicode" script >>108974776

>>108973005
>How do people still use this garbage.
No one uses C

File: Annotation 2026-04-18.png (19 KB, 514x349)

19 KB PNG

>>108975138
>No one uses C

everybody use tcc.exe cose it memory safe
https://desuarchive.org/g/thread/108770946

>>108973005
>nooo i can't grab the knife by the blade it cuts my hand
get a job at the circus, nocoder.

>>108973129
>that's the exact same shit as keeping pointers to heap allocated memory
And? Heap bad, pointers bad? You're dumb.

>>108973698
Yet another case of r*ddit post.

But yes, VLAs are good.

>>108973005
skill issue.\n\0

>>108975138
>he doesn't do low level programming
people like me bend over backwards to provide stupid fucks like you C bindings in pyshit

>>108973135
how 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 runtime
or is VLA data just located on the frame below locals?

>>108973005
c doesn't have strings

>>108975474
it'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

>>108975639
the compile time stuff is certainly first
the 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.

>>108973021
cope
UNIX strings just plan suck

>>108973046
Actually, you need a library to use strings because there is no such thing as a C string.

>>108975737
ascii is the white man's encoding for building systems
everything else is extraneous

>>108975742
"this is a string literal in C"
you can safely stop parroting whichever youtube eceleb you fellate

>>108975744
here, i'll even link you to the standard's definition
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf

>>108975742
oops, off by one error and the anchor wasn't included
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf#subsection.6.4.5

>>108975742
>there is no such thing as a C string

https://doc.rust-lang.org/std/ffi/struct.CString.html
Heh, checkmate, atheist.

File: cstring.jpg (30 KB, 375x500)

30 KB JPG

>>108973005

>>108974523
Have 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.

>>108973483
how can i learn more about this and know it from the top of my head like you

>>108976505
program C
read the old unix books
rtfms

>>108973005
Just use C++ retard.

>>108973005
Bro is scared by arrays.

>>108976788
to be fair, arrays are the most tricky part of C, odd as that sounds

>>108973699
certified clinical