char *strncpy( char *dest, const char *src, size_t count );.?

char *strncpy( char *dest, const char *src, size_t count );

/*
*1) Copies at most count characters of the *character array pointed to by src (including the *terminating null character, but not any of the *characters that follow the null character) to *character array pointed to by dest.
*If count is reached before the entire array src was copied, the resulting character array is not null-terminated.
*/

Shopping Cart Returner Shirt $21.68

UFOs Are A Psyop Shirt $21.68

Shopping Cart Returner Shirt $21.68

  1. 1 month ago
    Anonymous

    nooooo you're just holding it wrong

  2. 1 month ago
    Anonymous

    Wow, that's a lot of special cases in what probably is the most used function in the entire C language.

    Just imagine how many poor bastards were struggling with debugging their code when all they wanted to do is get a simple substring...

  3. 1 month ago
    Anonymous

    Miss me with that boomer shit

  4. 1 month ago
    Anonymous

    strncpy is designed for initializing null padded strings like one might find in various file formats. There is nothing wrong with the function, people just misunderstand its purpose.

    • 1 month ago
      Anonymous

      >>>>>>>>>>>>>>

      nooooo you're just holding it wrong

      • 1 month ago
        Anonymous

        That was me but I consneed
        >strncpy was initially introduced into the C library to deal with fixed-length name fields in structures such as directory entries. Such fields are not used in the same way as strings: the trailing null is unnecessary for a maximum-length field, and setting trailing bytes for shorter names to null assures efficient field-wise comparisons. strncpy is not by origin a "bounded strcpy," and the Committee has preferred to recognize existing practice rather than alter the function to better suit it to such use.
        Still a terrible name though

    • 1 month ago
      Anonymous

      it really has no fricking purpose. zero init your dest and use memcpy instead. I'd argue all the str* functions in C stdlib to be garbage.

      • 1 month ago
        Anonymous

        >I'd argue all the str* functions in C stdlib to be garbage
        What do you mean? The libc is perfectly reasonable!

        • 1 month ago
          Anonymous

          >strxfrm
          what the absolute frick? c locale string function? fricking glibc.

        • 1 month ago
          Anonymous

          >perfectly reasonable
          I understand that what you wrote is sarcasm. I just wanted to say that it is in fact reasonable, but only if you're dealing printable ascii characters or character sets close to ascii.

        • 1 month ago
          Anonymous

          >strxfrm
          what the absolute frick? c locale string function? fricking glibc.

          Oh, and who could forget zustr2ustp and friends?

          • 1 month ago
            Anonymous

            thus spake zustr2ustp

        • 1 month ago
          Anonymous

          [...]
          Oh, and who could forget zustr2ustp and friends?

          >providing functionality is.... le BAD

          • 1 month ago
            Anonymous

            It's not functionality because it doesn't work. This is why C programmers complain about languages that have a lot of features. They think everything is broken like C is.

          • 1 month ago
            Anonymous

            did you even read what half of these do and their caveats? I'm still waiting for someone to tell me why strncpy instead of 0-initing your dest and using memcpy?
            I'm legitimately floored. Like I cannot understand why half these garbage functions exist.
            even strfry was broken for a long time because it didn't implement fisher-yates correctly.

          • 1 month ago
            Anonymous

            caveat, this is glibc and it isn't a standard function, but still.

        • 1 month ago
          Anonymous

          >strfry
          heh

        • 1 month ago
          Anonymous

          strcasecmp is actually pretty useful, otherwise memcmp is good enough

    • 1 month ago
      Anonymous

      cniles are incapable of designing even one (1) good API lmao

      that's cope tho

      [...]
      Oh, and who could forget zustr2ustp and friends?

      >Oh, and who could forget zustr2ustp and friends?
      JUST ONE MORE FUNCTION and copying strings will work decently. JUST. ONE. MORE.

      [...]
      >providing functionality is.... le BAD

      strkys(you *you)

    • 1 month ago
      Anonymous

      there is something horribly wrong with strncpt. the name implies that it is to be used with strings, but it doesn't produce a valid C-style NUL-terminated string. it's beyond madness that this useless crap is part of the C standard and there is no real alternative to it.

      • 1 month ago
        Anonymous

        >there is no real alternative to it.
        wtf
        you just write your own

        you rustrannies are easily amused

        • 1 month ago
          Anonymous

          >you just write your own
          i would rather use std::string than suffer this language for the mentally handicapped

          • 1 month ago
            Anonymous

            >venom
            imagine getting filtered by c
            but yeah, if you cannot be trusted with putting a 0 at the end of a memory space, i guess you go for rust...

          • 1 month ago
            Anonymous

            why are you so obsessed with trannies? i already told you i use c++.
            imagine being filtered by two plus signs.

          • 1 month ago
            Anonymous

            im not
            its just that you dont pass
            the bile is a dead giveaway

          • 1 month ago
            Anonymous

            i don't think that's a troony. she is right anyway, new programmers shouldn't damage their brain with a language designed by morons winging it in the 70s

          • 1 month ago
            Anonymous

            >brain damage
            explain then how C is C++ raw pointer operations.
            or how not knowing half of a language is actually a good thing

          • 1 month ago
            Anonymous

            C++ beginners don't need to deal with raw pointers to the extent it is necessary in C. you can do 99% of what you need with std::vector and the occasional std::unique ptr. no pointer arithmetic necessary, no braindead casts to and from void* necessary, no moronic typedef struct bullshit necessary, no moronic lack of static initializers, no moronic fixed size array for everything because containers are too annoying to use in C, etc etc.
            as I said, there is no need to cause brain damage to new programmers by making them learn all the crap that C forces you to deal with.

          • 1 month ago
            Anonymous

            >dont learn the underlying mechanisms of the language, its gonna be fiiine
            behold, this is how a Black person is born

          • 1 month ago
            Anonymous

            >that pic
            >that incoherent moronic question
            Holy shit. This idiot actually thinks pointers are good and not just an implementation detail.

          • 1 month ago
            Anonymous

            >thinks pointers are good
            imagine being btfod by pointers
            its an address you idiot
            how can you be angry at an address?

          • 1 month ago
            Anonymous

            IQfy has been overrun by morons who fail to understand "advanced" topics like pointers.

          • 1 month ago
            Anonymous

            corporate wants rust so the usual suspects push for it without even understanding a iota of the subject
            it used to be way worse tho

          • 1 month ago
            Anonymous

            >pointers are addresses
            holy shit. peak midwit answer.

          • 1 month ago
            Anonymous

            >holy shit. peak midwit answer.
            and this is why you need iterators.

            your autismo ass just can comprehend stuff if it isnt made complicated enough

          • 1 month ago
            Anonymous

            Your compiler (and the standard) makes pointers very complicated is what I think she's trying to say
            Unless you're using TCC or -O0 or something they're not just addresses

          • 1 month ago
            Anonymous

            huh. ok.
            doesnt really impact the code side of things tho

          • 1 month ago
            Anonymous

            It can because this stuff affects compiler optimizations most of all. There are certain things that look reasonable enough but that the standard says are invalid and that the compiler may therefore turn into garbage.
            Strict aliasing is a fun one, in the Linux kernel they actually add a compiler flag to disable optimizations related to that. Here's an example:
            #include <stdint.h>
            #include <stdio.h>

            int foo(float *f, int *i) {
            *i = 1;
            *f = 0.0;

            return *i;
            }

            int main (void) {
            int x = 0;
            printf("%dn", x);
            x = foo((float *)&x, &x);
            printf("%dn", x);
            }
            It should print "0 0" since the last value written to the pointer is 0. (Even for a float all bits are 0.)
            But an optimized build with clang or GCC will print "0 1".
            The standard says you can't access an int through a float pointer. So the compiler assumes that f and i can't have the same address. So it optimizes "return *i" into "return 1".
            The pointers have invisible compile-time junk. And it's not just strict aliasing, there's a lot more. If you're lucky you get a warning but you don't always.
            Originally pointers were just addresses more or less. But it's hard to keep that up if you want to make things run fast. They made pointers complicated.

          • 1 month ago
            Anonymous

            The anon that called it out. I honestly just meant that some platforms like arm literally give you pointers that are actually hardware checked. The checks range from shit like pointer authentication to cheri's capabilities system. Assuming pointers are literal addresses in memory is fricking stupid and wrong.
            Hell M$ research pushed out a C lang that bans pointers and returns pure capability tokens in their place even.

          • 1 month ago
            Anonymous

            you think you know, but you don't actually know.

            https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html

          • 1 month ago
            Anonymous

            >First of all, it is not allowed to perform pointer arithmetic (like &x[i] does) that goes beyond either end of the array it started in.
            >omagad, how comes that when i break something, it breaks???

            It can because this stuff affects compiler optimizations most of all. There are certain things that look reasonable enough but that the standard says are invalid and that the compiler may therefore turn into garbage.
            Strict aliasing is a fun one, in the Linux kernel they actually add a compiler flag to disable optimizations related to that. Here's an example:
            #include <stdint.h>
            #include <stdio.h>

            int foo(float *f, int *i) {
            *i = 1;
            *f = 0.0;

            return *i;
            }

            int main (void) {
            int x = 0;
            printf("%dn", x);
            x = foo((float *)&x, &x);
            printf("%dn", x);
            }
            It should print "0 0" since the last value written to the pointer is 0. (Even for a float all bits are 0.)
            But an optimized build with clang or GCC will print "0 1".
            The standard says you can't access an int through a float pointer. So the compiler assumes that f and i can't have the same address. So it optimizes "return *i" into "return 1".
            The pointers have invisible compile-time junk. And it's not just strict aliasing, there's a lot more. If you're lucky you get a warning but you don't always.
            Originally pointers were just addresses more or less. But it's hard to keep that up if you want to make things run fast. They made pointers complicated.

            >https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html
            you took the contrivest of examples, and youre doing something that is an ub based on a logical assumption

            yes, -03 does funky things to your code to make it faster.
            it is part of the deal, it is written on the tin

          • 1 month ago
            Anonymous

            , how comes that when i break something, it breaks???
            What's stupid here is that you're not even allowed to calculate the pointer. Obviously accessing the memory is haram but you're not allowed to so much as take its address.
            >yes, -03 does funky things to your code to make it faster.
            This one happens on -O1 with clang and -O2 with GCC.

          • 1 month ago
            Anonymous

            >What's stupid here is that you're not even allowed to calculate the pointer. Obviously accessing the memory is haram but you're not allowed to so much as take its address.
            100% on the os memory model, not on the language
            but ok, point half taken.
            only half bc functionally it does act as a number unless you try to make it do something contrived you would never use in a sane program.
            like multiplying it by 2. (as opposed to working on a difference of offsets)

          • 1 month ago
            Anonymous

            >100% on the os memory model, not on the language
            The hardware and the OS don't give a shit (on typical modern systems with nice flat address spaces) but the language standard says you can't do it and compilers may or may not optimize based on that.
            I remember digging through the CPython source code and finding a place where pointers are compared to see if an object is part of a particular allocation. This is a pretty understandable thing to do. But the standard says it's UB to use the < operator on two pointers that belong to different allocations. Does that cause problems now? Could it cause problems in the future when compilers get smarter? Frick if I know.
            That ralfj blog post example is pretty close to being something you might realistically do. If two pointers compare equal then you expect them to be interchangeable. A lot of concurrent algorithms actually rely on this. The blog post has an example where x == y but *x behaves very differently from *y.
            >multiplying it by 2
            This is just a compile-time error, there's no multiplication operator for pointers (and the addition operator takes exactly one pointer and one integer operand).

          • 1 month ago
            Anonymous

            >The hardware and the OS don't give a shit
            the hardware doesnt but the os does. it needs to know what can have access to what resource
            and thats why the standard is minimalistic on what you can do with pointers.
            if you code on bare metal a pointer is a number.
            >Frick if I know.
            dont use UB if thats a problem for you.
            its literally what ub means: it not covered by the standard so you cant rely on it.
            > The blog post has an example where x == y but *x behaves very differently from *y.
            it ont and float example?
            arent you supposed to use void * in that case to make your intentions known to the compiler?

          • 1 month ago
            Anonymous

            >it ont and float example?
            *its the int and float example?

          • 1 month ago
            Anonymous

            It's calculating the address itself that's invalid. You don't have to dereference it. You don't have to access any resources. You don't have to involve the OS. int *q = p + 100; might in itself be undefined behavior if p's allocation is too small. Because the standard says so. (And all of this applies on bare metal.)
            The blog post explains this.
            >it ont and float example?
            No, that's a totally unrelated problem.
            >dont use UB if thats a problem for you.
            Point is that pointers aren't just addresses. If they were just addresses then you'd be allowed to do p < q without worrying. (This is yet a third problem.)

          • 1 month ago
            Anonymous

            this is such a complete non issue
            >might in itself be undefined behavior

            theres two key elements here:
            MIGHT

            and
            UNDEFINED BEHAVIOR

            >to do p < q without worrying. (This is yet a third problem.)

            you want a system to describe things OUTSIDE of that system
            i know youre autistic so you dont realize this
            but this is not how systems work
            or rather there is one that describes phenomena at a level you might rather see:
            fricking asm. but that isnt c anymore, is it?

            you expect a system to provide a representation to cover things that are considered explicitly outside of that system
            its totally asinine
            yes the concept of pointer doesnt cover the intimate reality of what a pointer is in the end
            but it doesnt matter in C, thats what languages are for, to abstract shit you absolute tard autismo

            what a complete and utter non issue

          • 1 month ago
            Anonymous

            >YOU GUYS ARE STUPID AND SHOULD STOP ARGUING BECAUSE I DONT UNDERSTAND THE TOPIC

          • 1 month ago
            Anonymous

            no i understand it very well.
            youre autistic so you dont see its completely barren
            and that in the end you want everyone else to cater to your lack of comprehension bc pointers confuse you

            welp, youre gonna have to accept we dont all have the same mental representation of a pointer
            autism is a netto loss for humanity

          • 1 month ago
            Anonymous

            >MIGHT
            Meaning that it's not UB if p's allocation is big enough.
            It feels like you're just skimming.
            >you want a system to describe things OUTSIDE of that system
            This one could very easily be inside the system and most people who haven't read the fine print would expect it to be inside the system.
            And "undefined behavior" doesn't just cover things that are left undecided by the standard, it also covers things that the standard explicitly bans (e.g. anywhere it says "shall not"). It's weird like that. Undefined behavior is typically best treated as bad news, it's different from unspecified behavior or implementation-defined behavior.
            >but it doesnt matter in C, thats what languages are for, to abstract shit you absolute tard autismo
            This kind of shit does in fact cause bugs

          • 1 month ago
            Anonymous

            >This one could very easily be inside the system and most people who haven't read the fine print would expect it to be inside the system.
            to do so you enter into platform dependent pov.
            thats fundamentally incompatible with what c is
            >This kind of shit does in fact cause bugs
            skill issue

            and all of this is subjective.
            fricking hell you autists are annoying to talk with

          • 1 month ago
            Anonymous

            >Meaning that it's not UB if p's allocation is big enough.
            I personally do it the chromium way and allocate an enormous share of virtual memory, far excess of what I need. No UB there, as every suballocation of that is part of the original array, so I can do pointer arithmetic all I want.

          • 1 month ago
            Anonymous

            you miss the point. whether or not this is ub, or how contrived the examples are is irrelevant. The model of pointers being just addresses is not enough

          • 1 month ago
            Anonymous

            it is important bc once you go ub youre not really operating within the context of the language anymore
            which kinda matters bc pointers do act like numbers when operated within the standard

          • 1 month ago
            Anonymous

            >gets angry at numbers
            >calls others braindamged
            such is the power of OOP

          • 1 month ago
            Anonymous

            this is one of the most moronic takes i’ve ever seen

          • 1 month ago
            Anonymous

            your post could be understood in a variety of ways

      • 1 month ago
        Anonymous

        >it's beyond madness that this useless crap is part of the C standard and there is no real alternative to it.
        For anything else, that's beyond madness. For C, useless crap is normal. It would be surprising if something in C wasn't useless crap.

  5. 1 month ago
    Anonymous

    honestly, I just use memcpy. if I don't have memcpy, I can just write the asm by hand since ERMS makes it really, really easy.

  6. 1 month ago
    Anonymous

    OMG

  7. 1 month ago
    Anonymous

    this is why length prefix strings are superior to null termination strings

    • 1 month ago
      Anonymous

      no shit. any nonshit c project has a len prefix string anyhow, otherwise you're probably vulnerable to smuggling data behind a NUL or simply can't handle NUL containing strings at all.
      reminder NUL is a valid UTF-8 codepoint if your software can't support it, it's shitware.

      • 1 month ago
        Anonymous

        cniles are worse than battered housewives holy shit

        • 1 month ago
          Anonymous

          yes. C++ is pretty close, but it's feature rich enough and made correct(ish) choices in regards to not having a completely worthless stdlib.

      • 1 month ago
        Anonymous

        >NUL is a valid UTF-8 codepoint if your software can't support it, it's shitware
        There really isn't any reason to have NUL codepoints in a piece of text. All the languages I regularly use have counted strings so I'll still pass them through of course but if there's a NUL in there then I feel it must be something other or more than actual text

        • 1 month ago
          Anonymous

          >There really isn't any reason to have NUL codepoints in a piece of text.
          Because you assert that strings are only ever text? That's... one position, even if not one supported by reality.

          • 1 month ago
            Anonymous

            >Because you assert that strings are only ever text?
            Yes, otherwise it's a character or byte array, not a string

      • 1 month ago
        Anonymous

        if you wanna be a fricktard why don't you come here and say it to my face so i can answer you with a swift fist to the nose
        you think your the hot shit but your just another idiot like the rest of them i bet the only pussy your getting is the type that says woof you stupid frick by which i mean you get no pussy at all you ignorant c**t how about you get with the times and stop trying to pretend your something your not maybe then people wont hate you you stupid prink if i ever see you strolling in my neighbourhood ill fricking jump out the window with my brick and youll be pummelled into the sidewalk son like a motherfricker who thinks he knows what hes doing the police wont even care theyll take one look at you and theyll see your stupid clothes and decided you fricking deserved it.

    • 1 month ago
      Anonymous

      For me it's fat pointers

      • 1 month ago
        Anonymous

        what are fat pointers

        • 1 month ago
          Anonymous

          You store the pointer and the length together, like struct { char *loc, size_t len }. Takes more registers/stack space but it's more flexible than prefixing the content with the length, you can take substrings without copying any content.

          • 1 month ago
            Anonymous

            nta.
            out of curiosity, how would you initialize this from const char* without providing length, without strlen?
            example:
            typedef struct { char* loc, size_t len} string_t;

            string_t init_string(const char*);
            // or
            void init_string(string_t*, const char*);

          • 1 month ago
            Anonymous

            In the general case that's logically impossible. But string literals support sizeof to get the actual size, and you can wrap that in a macro. So something like #define init_string(s) ((string_t){s, (sizeof s) - 1})? (I almost never write C, I might be getting the details wrong.)
            You'll probably also want a growable version with a capacity field, a la git: https://github.com/git/git/blob/master/strbuf.h
            Or you might decide that such a growable version is all you need. You can't take zero-copy substrings then but those are dangerous without a GC or borrow checker. I really don't know what it's like to write lots of C code with these.
            Fat pointers + growable buffers works out beautifully in Rust and mediocrely in C++ (std::string_view seems to be considered useful but a footgun). IIRC Go somehow manages to do both using a single type but that only works thanks to the GC.

          • 1 month ago
            Anonymous

            >string literals support sizeof
            yes, this was the first thing I thought. there's no issue with this at compile time, but at runtime you don't have this luxury, especially if such string comes from user or network.
            hence why I started discussion, it's an interesting problem.

          • 1 month ago
            Anonymous

            >if such string comes from user or network
            If all they give you is a pointer then any contained null byte is already irretrievably lost, right?

          • 1 month ago
            Anonymous

            not sure what you mean, but consider recv network function.
            it has following signature.
            ssize_t recv(int sockfd, void buf[.len], size_t len, int flags);

            you pass socket, pointer to your buffer, and len of bytes to read.
            now if you read strings with proposed string_t struct you can't really stop reading at NULL, because maybe it's utf-8 codepoint.
            of course if your string_t implementation is not allowed to grow, there might not be a problem, there's MAX_CHAR or something of how much you can store and you read that amount of bytes.

          • 1 month ago
            Anonymous

            recv tells you how many bytes it read, so if you want to just read everything sent through the socket you can use that.
            If you don't want to read everything but only a certain amount of data, determined by the other side, then the other side can send you the length up front. Or it can send you a terminator that it guarantees never occurs in the content, which is what multipart HTTP messages do. (A long enough random terminator is usually suitable for this.)

            really?
            so NULL ('') in both ascii and utf-8 is a string terminator?

            A null byte indicates the NUL codepoint. Any UTF-8 bytes that look like ASCII actually are ASCII, non-ASCII codepoints only use bytes that have their high bit set. (This is one of the nice properties of UTF-8, you can search for ASCII characters without decoding the string.)
            But a NUL codepoint may or may not be a string terminator. Most languages allow NUL codepoints to occur in the middle of strings and treat them just like any other codepoint. So they'll disagree with naïve C code about how to interpret such a string.

          • 1 month ago
            Anonymous

            ok, thanks for clarifying, I always found utf-8 confusing.
            and my null by confusion mostly comes from dealing with windows wide chars,
            which are utf-16 if I'm not being mistaken and are very weird about null bytes.

          • 1 month ago
            Anonymous

            Yeah, UTF-16 is pretty different. For that you ideally shouldn't even be thinking in terms of bytes but in terms of 16-bit numbers.

          • 1 month ago
            Anonymous

            thanks again for your insight, anon.

          • 1 month ago
            Anonymous

            The length is set to 1 because a pointer to a character is a pointer to 1 character.

          • 1 month ago
            Anonymous

            forgot to mention that this (

            nta.
            out of curiosity, how would you initialize this from const char* without providing length, without strlen?
            example:
            typedef struct { char* loc, size_t len} string_t;

            string_t init_string(const char*);
            // or
            void init_string(string_t*, const char*);

            ) question arise from the fact that utf-8 can have nul codepoint and therefore strlen cannot be reliably used here.

          • 1 month ago
            Anonymous

            not sure what you mean, but consider recv network function.
            it has following signature.
            ssize_t recv(int sockfd, void buf[.len], size_t len, int flags);

            you pass socket, pointer to your buffer, and len of bytes to read.
            now if you read strings with proposed string_t struct you can't really stop reading at NULL, because maybe it's utf-8 codepoint.
            of course if your string_t implementation is not allowed to grow, there might not be a problem, there's MAX_CHAR or something of how much you can store and you read that amount of bytes.

            ASCII characters, including 0x00, never appear as part of UTF-8 multi byte sequences.

          • 1 month ago
            Anonymous

            really?
            so NULL ('') in both ascii and utf-8 is a string terminator?

          • 1 month ago
            Anonymous

            >You store the pointer and the length together
            You do a bunch of different things, depending on whether the string is intended to be easy to append to or not. For non-modifiable strings, you can use struct { size_t len; char data[]; }, whereas for modifable strings you have the data in a separately-allocated buffer and also keep a note of the capacity somewhere.
            Sometimes you also keep a record of the encoding the string is in and other "fun" things like that.

  8. 1 month ago
    Anonymous

    Just use snprintf.

    >always null terminates no matter what
    >if you pass a NULL in the buffer argument, it will return the size of the buffer needed (minus the NULL byte)
    >can use stack or heap buffers equally
    >can easily concatenate strings, can use pointer arithmetic to concatenate in a loop.

    The only stdlib string functions I use now are strcmp and strlen.

  9. 1 month ago
    Anonymous

    >the year of our lord two thousand twenty four
    >IQfy still complaining about the simplest C function

  10. 1 month ago
    Frosch

    I always use it for

    char buffer[64]
    const char* str = "hi";
    strncpy(buffer, str, 64);

    So I don't see the problem.

    • 1 month ago
      Anonymous

      because if you pass buffer to a function that accepts a cstring, its a CVE

  11. 1 month ago
    Anonymous

    good thing I'm a C++chad with my std::string

  12. 1 month ago
    Anonymous

    i can't believe to this day, the best way to copy a string with bounds checking of the destination buffer in C is to use snprintf

  13. 1 month ago
    Anonymous

    Skill issue

  14. 1 month ago
    Anonymous

    hey guys just letting you know i'm going to keep using C and Rust exclusively

    seppleBlack personhomosexuals can cope all they like, but i'll be over here in my programming socks writing code for the kernel and spaceships

    stay mad chuds

  15. 1 month ago
    Anonymous

    This caused a possible bug in my program recently. I had to go back and check all of my programs that uses this garbage function and replace it with memcpy and setting nul manually.

    • 1 month ago
      Anonymous

      Why not use strncpy and setting the nul manually. It has it's advantages like not overflowong src.

  16. 1 month ago
    Anonymous

    strlcpy works well, idk why it's not in standard.

  17. 1 month ago
    Anonymous

    null termination was designed for 80s processors which could only move 4 bits at a time,in the current year length is a must.

  18. 1 month ago
    Anonymous

    why is IQfy too moronic to realize C was designed in an era where the way people coded was entirely different? Null-terminated strings were the best way to handle strings in the old days, and that this function was specifically designed for arrays of characters in memory with a fixed size.

    • 1 month ago
      Anonymous

      >Null-terminated strings were the best way to handle strings in the old days
      No, ALGOL had proper strings but C wanted to remain compatible with B which had no structs.

  19. 1 month ago
    Anonymous

    DEATH TO CNILES

Your email address will not be published. Required fields are marked *