OwO what's this in the latest draft of the C standard?
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf
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
I can not believe that these people both have a sense of humor and that it isn't outdated by 30 years.
who wrote this?
someone who wasn't paid enough to behave like a professional
I wish it was me, shitposting in a major language standard specification would be an achievement of a lifetime
A furry
>#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?
what
>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
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)
Java solved this decades ago with jars and resource loading lmao
Java is not a machine code compiled language.
Sure they did.
Explain this bloated instance-requiring homosexualry then
Oh shit nagger.
Don't leave us hanging
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.
Me when include_bytes!
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;
}
i am pretty sure rust can do this with include_bytes macro?
The only thing rust is doing with "bytes" is castration.
An STD.
ha
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..
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.
>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.
>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???
>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.
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?
>this language is just in active development
nah this shit is just not production ready
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".
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.
I use Rust and never once found a need to use nightly nor did i have issues with understanding what the stable build offered.
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.
>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.
>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".
cope
lmao, peak cnility
feels good to be a rustchad
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.
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]
That's a nice step forward, thanks Anon.
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.
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.
>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.
>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.
>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.
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?
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
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.
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.
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.
>It's not even mature nor usable in any serious context.
reading this as rustc is emerging
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
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.
>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
And what would you consider missing from it?
Oh, and I forgot to mention one more thing: I'm trans btw.
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.
>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.
kek
>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
It's not ad-hominem, you're using the wrong phallusy.
It's ad homomen.
>just open your mind bro
So Rust doesn't have bugs?
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.
>N2393 _Bool Definitions For true and false.
kek, better late than never.
Time to remove the
#define True (0==0)
#define False (0==1)
Why 0==0 and not 1?
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.
>ctrl+f
>"trojan" not found
>"malware" not found
Start investing in anti-virus companies.
>int main()
Shouldn't it be int main(void)?
Not a Cnile btw.
>Not a Cnile btw.
given your stupid comment, you're a hello worlder at best
I just looked it up
§ 5.1.2.2.1
main takes either no arguments, or two. Everything else is implementation defined.
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.
>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;
}
What's the importance of embed?
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.
Why is this better than having the file read from disk at runtime?
Because you don't have to open and read the file? hello?
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.
I imagine its main use is for embedded dev.
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.
>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
Disgusting. Nobody takes anything serious anymore.
>#embed
And just like that, in one single swoop, C put all other languages in their place
>thread about C
>filled with anal seething by rust trannies
Why are they like this?
I still use C99 anyway