OwO what's this in the latest draft of the C standard?

OwO what's this in the latest draft of the C standard?

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf

  1. 3 months ago
    Anonymous

    I can not believe that these people both have a sense of humor and that it isn't outdated by 30 years.

  2. 3 months ago
    Anonymous

    who wrote this?

    • 3 months ago
      Anonymous

      someone who wasn't paid enough to behave like a professional

    • 3 months ago
      Anonymous

      I wish it was me, shitposting in a major language standard specification would be an achievement of a lifetime

    • 3 months ago
      Anonymous

      A furry

  3. 3 months ago
    Anonymous

    >#embed
    Holy fucking shit is that what I tjink it is???
    Did C just manage to do what 99% of modern languages simply CANNOT do?

    • 3 months ago
      Anonymous

      what

      • 3 months ago
        Anonymous

        Don't leave us hanging

        >what
        Embedding files in the binary? Like resources? No more scripts to generate char arrays from files? Oh joy!
        God, I love C. It just keeps getting better and better

        • 3 months ago
          Anonymous

          yes, it's pretty amazing. I heard about this a couple months ago, the guy who pushed it spent the last decade? fighting with the standards committee and compiler vendors to get it in (not just Microsoft, but Apple and GCC too)

        • 3 months ago
          Anonymous

          >#embed
          Holy fucking shit is that what I tjink it is???
          Did C just manage to do what 99% of modern languages simply CANNOT do?

          Java solved this decades ago with jars and resource loading lmao

          • 3 months ago
            Anonymous

            Java is not a machine code compiled language.

          • 3 months ago
            Anonymous

            Sure they did.
            Explain this bloated instance-requiring homosexualry then

        • 3 months ago
          Anonymous

          Oh shit nagger.

    • 3 months ago
      Anonymous

      Don't leave us hanging

    • 3 months ago
      Anonymous

      [...]
      >what
      Embedding files in the binary? Like resources? No more scripts to generate char arrays from files? Oh joy!
      God, I love C. It just keeps getting better and better

      It is, yes
      https://thephd.dev/finally-embed-in-c23
      I was kinda surprised this wasn't already a feature tbh. Rust has had include_bytes! for a long while now, just seems like the kind of thing you'd include.

      yes, it's pretty amazing. I heard about this a couple months ago, the guy who pushed it spent the last decade? fighting with the standards committee and compiler vendors to get it in (not just Microsoft, but Apple and GCC too)

      It's pretty insane how hard this guy had to fight for this.

    • 3 months ago
      Anonymous

      Me when include_bytes!

    • 3 months ago
      Anonymous

      We won cnaggers.
      include <stddef.h>

      void have_you_any_wool(const unsigned char*, size_t);

      int main (int, char*[]) {

      static const unsigned char baa_baa[] = {
      #embed "black_sheep.ico"
      };

      have_you_any_wool(baa_baa, sizeof(baa_baa));

      return 0;
      }

    • 3 months ago
      Anonymous

      i am pretty sure rust can do this with include_bytes macro?

      • 3 months ago
        Anonymous

        The only thing rust is doing with "bytes" is castration.

  4. 3 months ago
    Anonymous

    An STD.

    • 3 months ago
      Anonymous

      ha

  5. 3 months ago
    Anonymous

    I'd just like to point out that the lack of a borrow checker and the innate un-safeness of this legacy language makes it unsuitable to develop modern applications. All of these problems are solved, however, by the Rust programming language.
    Find out more at https://doc.rust-lang.org/book/
    Also, pic related..

    • 3 months ago
      Anonymous

      Thanks, wasn't aware of this. I'll tell my coworkers tomorrow.

    • 3 months ago
      Anonymous

      [...]
      It is, yes
      https://thephd.dev/finally-embed-in-c23
      I was kinda surprised this wasn't already a feature tbh. Rust has had include_bytes! for a long while now, just seems like the kind of thing you'd include.
      [...]
      It's pretty insane how hard this guy had to fight for this.

      Thanks, wasn't aware of this. I'll tell my coworkers tomorrow.

      Sweet, I didn't know this programming language, is it new?
      Also, is there any specifications somewhere, so I can fiddle and make my own compiler?
      I did multiple (very simple) fantasy machine and it's dev tools, but using a new language would be nice.

      • 3 months ago
        Anonymous

        >is it new?
        Yeah, quite new. It only reached V1 about 5 years ago, maybe a little longer.
        >Also, is there any specifications somewhere
        No. There's not much reason for it to have a spec at the moment, the only reason C got a spec was because of the proliferation of different C compilers. Instead there's a reference implementation in rustc.

        Have fun hacking around anon, I'm sure it'll be a lot of fun, although it's quite a daunting project.

        • 3 months ago
          Anonymous

          >5years
          Oh, okay.

          >no spec
          I beg you pardon?
          If I want to make my own compiler I have to retro-engine the "rustc" compiler!?
          How the hell am I supposed to learn the language it it's described nowhere???

          I start reading https://doc.rust-lang.org/rustc/lints/index.html and I don't understand "Future-incompatible lints".
          You mean the code I wrote can be deprecated in the next compiler version "just because it evolved"!?
          Can I at least use something like #version yada_M.m.r???

          • 3 months ago
            Anonymous

            >If I want to make my own compiler I have to retro-engine the "rustc" compiler!?
            Yes. Is that really an issue? I mean, it's pretty well commented. It also has a lot of unit tests, so they should be enough for you to guarantee that your implantation produces the same output.
            >just because it evolved"!?
            No, they're mostly about compiler bugs.
            >Can I at least use something like
            Yes, you can specify the minimum supported rust version in your cargo.toml.

            • 3 months ago
              Anonymous

              Whaaat!?
              You can't first say "Just copy the compiler bro, it werks" and the line after say "ho don't worry, deprecated functions are just compiler bugs".
              How am I supposed to know what is a good function and a buggy function in the rusc then!?
              I won't be able to make my own compiler for rust, all I could is do something that produce the same output as "that now deprecated version of rustc because it takes time to code and they found bugs".

              Or, you are playing on me.
              I will search more info I get it, no spoonfeed.
              It's a shame cause it looks like a nice language from whatever I read in rustc and cargo pages.

              >Minimal version
              It's nice, but useless for that particular problem.
              If, say, function "printUnicorns()" is added to 1.2.3 and removed because it have nothing to do with core language on 1.2.4, I can say #minversion 1.2.3 as much as I want, it won't help.
              And if it's deprecated, that's the least of the problems, the linter will probably tel it, but imagine that rustc decide that unicorns are now green, scaly and breath fire and change it in 1.2.4, it's even worst.
              The linter will say nothing because the function is there, it's meeting the V>=1.2.3 requirement, but it prints dragon looking "unicorns" now!
              WTF?

              • 3 months ago
                Anonymous

                >this language is just in active development
                nah this shit is just not production ready

          • 3 months ago
            Anonymous

            Code can be deprecated because it's impossible to compile correctly. Your link has the example of taking a pointer to a packed field, which may not have correct alignment—how would you prefer it to be handled? Is there a better solution?
            These compatibility breaks are a tool of last resort, only used for code that never was correct in the first place. Almost all other changes are backwards-compatible, and the few that aren't (like introducing new keywords) are handled through an edition system, much like your "#version".

      • 3 months ago
        Anonymous

        Rustfag mode one:

        Yes there is totes some of spec that some academic guy has once written about a subset of Rust that could maybe prove some sort of properties about Rust in certain conditions.

        Here's your spec bro.

        Rust does not have a spec, you're supposed to use the nightly compiler, which is sometimes so retarded that even the fucking Javascript people are not doing.

        • 3 months ago
          Anonymous

          I use Rust and never once found a need to use nightly nor did i have issues with understanding what the stable build offered.

        • 3 months ago
          Anonymous

          Yeah, I did my research and find out that there is no specs.
          Even the language reference "https://doc.rust-lang.org/reference/" is just a reference, not a set and complete spec.

          I mean, you can use it to code, yes.
          You can make programs using rustc, yes.
          But that's about it.
          In 10 years, nothing prove that the code I wrote will still compile or whatever.

          >this language is just in active development
          nah this shit is just not production ready

          >not production ready
          That's a far cry from it's state.
          It's not even mature nor usable in any serious context.

          I won't lose my time with this language.
          I prefer to lose my time writing an emulator for whatever console, or trying my luck with webassembly.

          Thanks for the tips tho, but Rust is not a language, it's a toy experiment by now.
          And it's a shame, it have some retarded conceptions (like the r###"This is a raw string!"### or the var = 8i8; or the "Hey, let's use [right-to-left mark] UTF_8 glyph as a totaly valid way of separating our tokens!"), but some really good ideas too.
          I hope it will mature and not turn to shit.

          • 3 months ago
            Anonymous

            >muh spec
            Only cniles care about a spec. No other programmer says "I wrote this brain damaged bullshit, according to Section 3.2.4.2.1 paragraph 7 it is valid, yet this compiler doesn't do what it's supposed to do".

            • 3 months ago
              Anonymous

              cope

            • 3 months ago
              Anonymous

              I just looked it up
              § 5.1.2.2.1
              main takes either no arguments, or two. Everything else is implementation defined.

              lmao, peak cnility
              feels good to be a rustchad

            • 3 months ago
              Anonymous

              Did you just assume my language!?
              Where in hay did I said that I was a C programmer? Nowhere, because that's not the point.
              Spec are important if you want your language (or whatever in fact) to be future proof.
              When in a decade or two someone want to compile Rust, I sincerely hope he will have some spec to write his new compiler, because if not, virtually all rust code is lost to sand of time.
              Look at how fucking much effort goes to retro engineering to free some closed source / old undoccumented format.
              Take Game Boy CPU, 20 years of retro engineering, and the community still don't know everything about it.

              A language without spec is nothing more than a toy.
              Play with it a bit, enjoy while it last.

              >It's not even mature nor usable in any serious context.
              reading this as rustc is emerging

              rustc is a compiler.
              The only working one.
              And without spec, it's literally the only thing that makes Rust something beside a wet dream.
              mrust is not mature enough to be used as stated in it's own docs [https://github.com/thepowersgang/mrustc]

              Even Rust coders know that it's a problem [https://users.rust-lang.org/t/how-many-rust-compilers-are-out-there/28590]

              The language spec can be found at
              https://spec.ferrocene.dev/

              It's still a draft, but it should be sufficient for writing whatever toy compiler you're planning on implementing.

              That's a nice step forward, thanks Anon.

              saw this bs programming language on https://habr.com/ru/company/timeweb/blog/673176/

              code looks like this bs
              print(str) := {
              %{
              printf("%s", static_cast<const char *>($str)); /* Пpямoй вызoв C фyнкции */
              %}
              };

              homosexual developed this said
              >its easier for beginners to understand, less keywourds, much symbols

              Yeah, the Tokenisations and prefix system is a bit messy.
              For simple things, it's nice, but too close to C for real beginners. Python would be an easier syntax I think.

              Code can be deprecated because it's impossible to compile correctly. Your link has the example of taking a pointer to a packed field, which may not have correct alignment—how would you prefer it to be handled? Is there a better solution?
              These compatibility breaks are a tool of last resort, only used for code that never was correct in the first place. Almost all other changes are backwards-compatible, and the few that aren't (like introducing new keywords) are handled through an edition system, much like your "#version".

              Well, specifying a fixed version of the compiler at very least.
              Because one can't fix a language version other than 2015, 2018 and 2021.
              Still a #version 2015 would be better than nothing.
              Not from a functional point of view (because it would be close to useless), but because it's a more sane way of doing it to future proof code.
              The fact that specifying Rust 2021 can still lead to uncompilable code or unstable code because sub revisions break things is not future proof.
              You can execute Python 3.7 code on a 3.9 interpreter.
              And for big changes, even if it was a pain, Python2 and Python3 could be clearly separated.

              • 3 months ago
                Anonymous

                >Look at how fucking much effort goes to retro engineering to free some closed source / old undoccumented format.
                This has nothing to do with formal specifications
                Didn't read the rest of your schizo ramblings, take your meds.

              • 3 months ago
                Anonymous

                >There! I found something I don't agree with so I stop reading. I win and you lose, I really am the best.
                Just imagine in ten years, some linux drivers written in Rust need to be updated for whatever reason.
                What will happen when there is no way to compile Rust?
                How do you understand what the programmers meant to do with their code?
                Well, if you don't have specs, you will never be 100% sure.
                And recovering the original meaning of something you don't have access to a way to make run is retro engineering.
                But that won't happen, and you know why?
                Because Rustc is witten in... C.
                Which have specifications and will be compilable any time in the future.

                And if you look at really early C, before normalization, you know what I mean.
                Obscure forgotten compiler flags, edge case unclear and treated differently depending on compiler, it was a mess.
                Try to compile DOS area code with modern GCC. Beside unavailable libs and platform specific behavior, C code from a compiler wasn't compileable on an other.
                And you still have this problem with "flavor of C" on very low end microcontrolers like Paduk or Microchip back in the day.

                Tl,Dr:
                Be more mature yourself, and try to argue instead of just being a stupid dick.

              • 3 months ago
                Anonymous

                >even more schizo ramblings
                >What will happen when there is no way to compile Rust?
                How would that happen? Somehow all copies of the binaries and sources of rustc are gone? Take your meds.
                >How do you understand what the programmers meant to do with their code?
                ummm... shit. Rust has no spec therefore nobody can know what happens if you write 1 + 2 in Rust.
                >Because Rustc is witten in... C.
                Actually, it's written in Rust. Since quite a while actually. Before thta it was written in OCaml (or Standard ML, idk).
                The LLVM backend is written in C++, same as the WIP GCC backend. There is also a WIP backend written in Rust though.

                Tl,Dr:
                I obviously was memeing about the schizo stuff in my previous post, but now I'm serious. Take your meds.

              • 3 months ago
                Anonymous

                You probably never coded for decade old projects, nor for very special and forgotten or low volume targets.
                If I had to take medicine, you should get in touch with reality.
                How do you younglings say? Touch grass or something?

                Again, what do you want to happen when you take a reference to a field of a packed struct? That's just plain incorrect, why should it compile? It's not well-formed. C is not future-proof either if your program has UB, the compiler is allowed to fuck your shit up any time. And using a misaligned pointer is clearly ill-formed no matter how little of a spec there is.
                But as a matter of fact it is very easy to build your project with a specific compiler release, IIRC there's even a config field for it. I test my libraries on multiple compiler versions and it's a breeze, rustup and cargo are designed to make it easy.
                >When in a decade or two someone want to compile Rust, I sincerely hope he will have some spec to write his new compiler, because if not, virtually all rust code is lost to sand of time.
                Specs are good and a Rust spec is in progress (ferrocene), but this is overstating it. There are other ways to define behavior. Rust is in large part defined by its test suite and its body of existing code, and compilers like GCC-rs successfully target that.
                Let's also not forget that for almost two decades C was de facto defined by the K&R book, much less rigorous than what Rust has after seven years.

                Well, if your compiler mess things up, you don't publish it.
                The problem with the compiler defining your language is that at any bug in the compiler, it become a de facto standard for the language.
                It's mitigated by the fact that one can stick to "Rust 2015" "Rust 2018" or "Rust 2021", but that's still not a desirable thing to do.

                Yeah, between 1978 and 1989, the C language was like Rust today.
                Well, almost, because at least, back in the day, the language was "finished" even if not standardized.
                And again, I don't say that Rust is bad, I say that it's not mature yet, like C was.
                But

                The language spec can be found at
                https://spec.ferrocene.dev/

                It's still a draft, but it should be sufficient for writing whatever toy compiler you're planning on implementing.

                stated that Ferrocene was a specification draft. And it's truly is nice (and even inspire itself from Ada, which is even better), but finishing it should be the top priority, and not working on the compiler.
                I mean, other languages made mistakes, don't repeat it.
                Don't wait 20+ years like C to have specifications, or like Python which added libs without coherency and was constrained to break compatibility from V2 to V3..
                Do things right from the start, it will greatly improve Rust's view by others and will make it really useful.
                Because you will make mistakes, everyone make some. But if you learn what other did, you will make less mistakes.

              • 3 months ago
                Anonymous

                A spec was much more important back in the day when every platform had its own hard to obtain compiler and digital communication was in its infancy.
                Now you have a gigantic public test suite, the reference compiler can run on your phone, language design takes place on the public web, and if you have a question you can ask and get an answer in a matter of hours—assuming you can't get one by googling. To ensure backward compatibility they build and test several hundred thousand(!) public Rust codebases for regressions before each release.
                The world has changed. An ALGOL spec was vital, a Rust spec is nice to have. I don't think it should be top priority, the set of problems it solves is actually rather small because the old problems are solved in new ways.

              • 3 months ago
                Anonymous

                Again, what do you want to happen when you take a reference to a field of a packed struct? That's just plain incorrect, why should it compile? It's not well-formed. C is not future-proof either if your program has UB, the compiler is allowed to fuck your shit up any time. And using a misaligned pointer is clearly ill-formed no matter how little of a spec there is.
                But as a matter of fact it is very easy to build your project with a specific compiler release, IIRC there's even a config field for it. I test my libraries on multiple compiler versions and it's a breeze, rustup and cargo are designed to make it easy.
                >When in a decade or two someone want to compile Rust, I sincerely hope he will have some spec to write his new compiler, because if not, virtually all rust code is lost to sand of time.
                Specs are good and a Rust spec is in progress (ferrocene), but this is overstating it. There are other ways to define behavior. Rust is in large part defined by its test suite and its body of existing code, and compilers like GCC-rs successfully target that.
                Let's also not forget that for almost two decades C was de facto defined by the K&R book, much less rigorous than what Rust has after seven years.

          • 3 months ago
            Anonymous

            >It's not even mature nor usable in any serious context.
            reading this as rustc is emerging

          • 3 months ago
            Anonymous

            saw this bs programming language on https://habr.com/ru/company/timeweb/blog/673176/

            code looks like this bs
            print(str) := {
            %{
            printf("%s", static_cast<const char *>($str)); /* Пpямoй вызoв C фyнкции */
            %}
            };

            homosexual developed this said
            >its easier for beginners to understand, less keywourds, much symbols

      • 3 months ago
        Anonymous

        The language spec can be found at
        https://spec.ferrocene.dev/

        It's still a draft, but it should be sufficient for writing whatever toy compiler you're planning on implementing.

        • 3 months ago
          Anonymous

          >https://spec.ferrocene.dev/
          Not him but I've seen this; it's rather an outline than a draft. Admit that your language is far from mature and come back when it has at least a complete specification

          • 3 months ago
            Anonymous

            And what would you consider missing from it?

    • 3 months ago
      Anonymous

      Oh, and I forgot to mention one more thing: I'm trans btw.

      • 3 months ago
        Anonymous

        Yes, AND???
        Notice how most criticism of the Rust programming language is made by ad-hominem attacks by programmers refusing to let go of a legacy language. If you'd learn Rust with an open mind, you'd most certainly be impressed.

        • 3 months ago
          Anonymous

          >Notice how most criticism of homosexuality is made of ad-hominem attacks by heterosexuals refusing to let go of a legacy sexuality. If you'd transition with an open mind, you'd most certainly be impressed.

          • 3 months ago
            Anonymous

            kek

            Yes, AND???
            Notice how most criticism of the Rust programming language is made by ad-hominem attacks by programmers refusing to let go of a legacy language. If you'd learn Rust with an open mind, you'd most certainly be impressed.

            >If you'd learn Rust
            why would I when there is no incentive to do so? is there a high demand in the industry for rust programmers? no. can it do anything other languages can't? no. is it easily picked up and appealing as a hobby language? no. is it specialized for a certain task that is interesting for average programmer? no. what is it good for? and I know this has been said gazillion times already but the tranny community is really a huge turn-off

        • 3 months ago
          Anonymous

          It's not ad-hominem, you're using the wrong phallusy.
          It's ad homomen.

          • 3 months ago
            Anonymous

            >just open your mind bro

        • 3 months ago
          Anonymous

          >just open your mind bro

    • 3 months ago
      Anonymous

      So Rust doesn't have bugs?

    • 3 months ago
      Anonymous

      I'd like to remind you that Pust by design is, and will always be considerably more slow than C or C++. If you want retard friendliness in exchange for speed, use C# or Java-based languages instead.

  6. 3 months ago
    Anonymous

    >N2393 _Bool Definitions For true and false.
    kek, better late than never.
    Time to remove the
    #define True (0==0)
    #define False (0==1)

    • 3 months ago
      Anonymous

      Why 0==0 and not 1?

      • 3 months ago
        Anonymous

        To allow the compiler to be type aware that your booleans are not integers but... booleans.

        This way, with pedantic and --Wall options, the compiler would tell you if you mix integers and booleans.
        I mean, one don't care if under the hood the compiler uses integer to represent booleans.
        In the code you have a new type, and it allows for better segregation and sanity check at compile time.
        So more maintainable code.
        Like, unfortunately, you should use:
        typedef struct s_myType
        {
        float r;
        float i;
        } t_myStruct;

        To tell the compiler that a new type exists, and that a new structure exists too.
        It's painful, but on the other hand, you really harden your code against mistyping and wild castings.
        Very useful in critical code.

  7. 3 months ago
    Anonymous

    >ctrl+f
    >"trojan" not found
    >"malware" not found
    Start investing in anti-virus companies.

  8. 3 months ago
    Anonymous

    >int main()
    Shouldn't it be int main(void)?
    Not a Cnile btw.

    • 3 months ago
      Anonymous

      >Not a Cnile btw.
      given your stupid comment, you're a hello worlder at best

      • 3 months ago
        Anonymous

        I just looked it up
        § 5.1.2.2.1
        main takes either no arguments, or two. Everything else is implementation defined.

  9. 3 months ago
    Anonymous

    This is a pretty nice feature. Before you would either have to generate an array literal and include that file inside an array (not ideal because it has to be parsed which is slow if it's large) or generate an object file with a symbol where your embedded data bytes start and it's size.

  10. 3 months ago
    Anonymous

    >C committee did something based
    int main () {

    struct s {
    double a, b, c;
    struct { double e, f, g; };
    double h, i, j;
    };

    struct s x = {
    #embed "s.dat"
    };

    return 0;
    }

  11. 3 months ago
    Anonymous

    What's the importance of embed?

    • 3 months ago
      Anonymous

      there is finally a canonical way to take a file on disk (or elsewhere) and copy it into the program rdata section (with a compile time symbol name) that doesn't rely on shitty manual parser hacks that work differently on each OS, linker, compiler, and CPU architecture combination.

      • 3 months ago
        Anonymous

        Why is this better than having the file read from disk at runtime?

        • 3 months ago
          Anonymous

          Because you don't have to open and read the file? hello?

          • 3 months ago
            Anonymous

            Also it allows for compile time optimisations to happen.
            For example, if you're compiling a static neural network for inference on edge devices, and you embed the weights, the compiler can see the 0 weights and remove the unnecessary multiplications.

        • 3 months ago
          Anonymous

          I imagine its main use is for embedded dev.

        • 3 months ago
          Anonymous

          You don't have to ship the file separately. You don't have to spend time allocating and reading it. There's no possibility of runtime I/O errors. There's no realistic possibility of getting the wrong file contents. Since it's fully available at compile time it can be optimized better.

        • 3 months ago
          Anonymous

          >why is something thats baked in better that something that has to be manually fetched, loaded, and will has to have extra error handling if its not found?
          it is a mystery

  12. 3 months ago
    Anonymous

    Disgusting. Nobody takes anything serious anymore.

  13. 3 months ago
    Anonymous

    >#embed

    And just like that, in one single swoop, C put all other languages in their place

  14. 3 months ago
    Anonymous

    >thread about C
    >filled with anal seething by rust trannies
    Why are they like this?

  15. 3 months ago
    Anonymous

    I still use C99 anyway

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