Rust GCC Code Generator "rustc_codegen_gcc" Can Now Bootstrap Rustc

[oiaohm]

This is not true.

Ipv6 address is not expressed as a 128-bit integer, thus it is not a problem here.

Looking athttps://man7.org/linux/man-pages/man7/ipv6.7.html, the ipv6 address is expressed using `struct in6_addr`, further investigation into the kernel API https://docs.huihoo.com/doxygen/linu...in6__addr.html, it shows that the Linux kernel treats it as a union, it can be interpreted as 16 u8, or 8 u16, or 4 u32.

When looking at the source code of glibc implementation of `inet_pton6` https://code.woboq.org/userspace/gli...tml#inet_pton6, a function to convert IPv4 and IPv6 addresses from text to binary form, it does not use any 128-bit integer at all.

In fact, the RFC for ipv6 does not involve 128-bit integer at all.

The ipv6 address is essentially 8 `u16` integers that are encoded separately, so there is absolutely no 128-bit integer involved for ipv6 socket.

This is what happens when you only look at the Linux kernel FFI.

https://www.spinics.net/lists/netdev/msg544476.html

Sorry the reality is in the rapid processing the ipv6 address is converted to 128 bit integer by the Linux kernel. Yes BPF has had to had 128bit support to prevent conversion back. Yes due to the 128bit being binary different between clang/gcc its not allowed in the direct to userspace interfaces.

So basically what you just wrote about does not disprove my statement about ipv6 and 128 bit integer usage. The binary issue here is a true pain. Yes this has resulted in structure for export to userspace and internal usage of the Linux kernel being two different things.

Yes the glibc example is not hot path code. Hot path code for firewalls and other things you will find 128bit integer used. Yes games validating IP of packets to make sure user should be allowed to connect to server this is a hot path and is a form of a firewall just done as user code.

So this 128bit integer problem is a true headache. Not exposed as 128bit integer does not mean not processed as 128bit integer. Yes if you are processing stuff as 128 bit integer its helpful to have 128bit integer support.

Yes Linux kernel BPF solution for 128bit integer its format is what ever compiler built the kernel choice.

[NobodyXu]

This is what happens when you only look at the Linux kernel FFI.

https://www.spinics.net/lists/netdev/msg544476.html

Sorry the reality is in the rapid processing the ipv6 address is converted to 128 bit integer by the Linux kernel. Yes BPF has had to had 128bit support to prevent conversion back. Yes due to the 128bit being binary different between clang/gcc its not allowed in the direct to userspace interfaces.

So basically what you just wrote about does not disprove my statement about ipv6 and 128 bit integer usage. The binary issue here is a true pain. Yes this has resulted in structure for export to userspace and internal usage of the Linux kernel being two different things.

Yes the glibc example is not hot path code. Hot path code for firewalls and other things you will find 128bit integer used. Yes games validating IP of packets to make sure user should be allowed to connect to server this is a hot path and is a form of a firewall just done as user code.

So this 128bit integer problem is a true headache. Not exposed as 128bit integer does not mean not processed as 128bit integer. Yes if you are processing stuff as 128 bit integer its helpful to have 128bit integer support.

Yes Linux kernel BPF solution for 128bit integer its format is what ever compiler built the kernel choice.

Ok thanks, I didn't know that for sure.

[oiaohm]

Ok thanks, I didn't know that for sure.

This is why doing foreign function interfaces is so hard as well. The things you don't know come back and hurt in this case.

The idea that all the languages can form a workable agreement end up things don't know for sure ruining the idea. For performance the result is compiler validation but that depend on each compiler doing the validation the same. Runtime validation is slower as the validation is done on the fly and you are still depending on every compiler to write the information the same.

Programming languages have issues of define types that don't exist in other languages. Yes this is kind of the same as the gcc/clang 128 bit int with this being the compilers don't always define types the same.w

Yes some of this comes from the hardware itself where there is more than 1 machine code/assembly to perform the same task. Yes x86 has 4 different ways to doing 128 bit and arm64 has 3. Yes there are performance differences with each choice.

This is why these problems are simply cursed. No matter what way you pick for someone you are going to be wrong if you do not have hardware support. Even with hardware support some are still going to think your choice is wrong.

[arQon]

The fact that we see Rust gaining interest from FAANG among other groups

I meant to comment on this a while ago, but you're reading way too much into that. By the time you have tens of thousands of developers anywhere, many of them just jerking off all day, looking to pad their resumes, bored, or burned out, and groups in the same state, they'll jump on *anything* like a hungry lioness on a wounded gazelle. I've seen people go on crusades to use garbage like *Vala*, ffs - and this was *after* even GNOME had given up on it - just because the alternative was "actually doing their job".

The proof of the pudding is in the eating. For all that the Rust team has made huge strides by relentlessly pushing to hitch their wagon to the kernel, there's still no more "real" code written in it than in any of the other fad languages so far this century. While I agree it's managed to save itself from obscurity, it hasn't done so on its own merits, and it'll be years still before we find out what its fate really is.

> He's pointing out that, when LED traffic lights came in, they were superior to previous models in every way except that, in some locations, on some snowy days, they didn't melt the snow that built up in front of the lens.

Ah. I live in one of those locations, and the incandescents often didn't either - so that argument was even weaker than you thought.
(IIRC the transition was also only the red lights originally, which I think is more interesting, but less relevant).

> "But sometimes!" is his term for when people cling to the status quo they're familiar with rather than trying to figure out how to improve or otherwise make use of the new thing that's better in 95%+ of the cases.

meh, not impressed. I've had to fight those battles for as long as I can remember, and IME that's almost never been the line. I generally hear "What if..." followed by some imaginary case that not only never had happened and never credibly would, but probably wouldn't have worked in the current setup even if it did show up one day.
Fanboying for change for change's sake though, especially when doing so introduces substantial risk and/or cost, is at least as bad as the frightened paralysis of the gutless and the fakers. People pushing stupid ideas for the sake of their own ego or benefit at the expense of the team are not people I want to work with. Even for the - frankly, very rare - *good* large-scale changes there's an opportunity cost to the transition, and it's my job to consider *all* the aspects, not just what I want or what this month's fad is (especially "according to people who stand to profit from said fad". :P)

> I'm saying that this is a broader-scope version of "If language A and language B both use count-prefixed strings, is it reasonable to demand that they convert to and back from null-terminated strings just so they can pass what is a bag of bytes anyway through the intervening C?"

You know this literally happened, right? That's exactly (albeit in the opposite direction) what BSTR is. And the answer is yes, it *is* reasonable, despite what you think, because that's the tradeoff you make for having that ABI be available to everything in the first place. If you want to go around it, that's *by definition* on you to deal with, whether that's by shimming them as a binary type or whatever floats your boat, but you can't have your cake and eat it too.
I'm not going to re-read the article in question, but my recollection is that what was really being pushed for was along the lines of "Can someone else please deal with the O(n) cost of duplicating thousands of API calls, because I'm special and I don't want to do [a tiny fraction of] that work myself". That's obviously not even a viable approach, let alone a maintainable one - and that's *before* you get into the sort of hackery that OO languages have.

> I think we'll have to disagree on that. From the examples I've read about, it's easy to write "a C" but much more difficult to write the same C that someone else has.

Apparently I misunderstood you then: I thought you were just talking about the language in general, not aiming for bitwise compatibility with some specific compiler.
If you do just mean "C" though, there are plenty of compilers written by a single individual. (C++ I think we can agree is *well* into "yeah, no chance" territory).

[ssokolow]

I meant to comment on this a while ago, but you're reading way too much into that. By the time you have tens of thousands of developers anywhere, many of them just jerking off all day, looking to pad their resumes, bored, or burned out, and groups in the same state, they'll jump on *anything* like a hungry lioness on a wounded gazelle. I've seen people go on crusades to use garbage like *Vala*, ffs - and this was *after* even GNOME had given up on it - just because the alternative was "actually doing their job".

I don't disagree with that statement, but I think we'll have to agree to disagree on how applicable it is to this specific case. My perception is that you're letting your own biases skew your perception of the situation.

While I enjoy using Rust for my own purposes, I don't have a huge emotional stake in its popularity... but I do notice that, after compensating for as many variables as I can, its rise looks more like that of Java or C# than of Vala or Haskell.

(Heck, the main reason I care about Rust as much as I do for my own use is that it's a nice intersection of "ecosystem that isn't eager to break APIs in the name of R&D", "PyO3 exists for easily writing memory-safe Python extensions", not being pure functional, not having an uncomfortable currying-based syntax, and producing self-contained binaries that start quickly. Otherwise, I'd probably be using Haskell.)

The proof of the pudding is in the eating. For all that the Rust team has made huge strides by relentlessly pushing to hitch their wagon to the kernel

[citation needed]

If anyone on the Rust team has been actively pushing for that, it's certainly been insignificant enough that I didn't notice it, despite being subscribed to the RSS feed for /r/rust/ since before v1.0 in 2015, following This Week in Rust since the first issue, and contributing to the RFC discussions when I felt I had something useful to say despite not being a Programming Language Theorist.

meh, not impressed. I've had to fight those battles for as long as I can remember, and IME that's almost never been the line. I generally hear "What if..." followed by some imaginary case that not only never had happened and never credibly would, but probably wouldn't have worked in the current setup even if it did show up one day.

He was drawing the "but sometimes..." from how the media reacts after the changeover has occurred in some locales. I don't think he felt the "what if..." was worth dignifying with a response.

You know this literally happened, right? That's exactly (albeit in the opposite direction) what BSTR is. And the answer is yes, it *is* reasonable, despite what you think, because that's the tradeoff you make for having that ABI be available to everything in the first place. If you want to go around it, that's *by definition* on you to deal with, whether that's by shimming them as a binary type or whatever floats your boat, but you can't have your cake and eat it too.

I doubt you're getting much out of "having that ABI be available to everything" in cases where you're marshalling down through C for two higher-level languages and any attempt to actually use the C interface directly for other languages will be met with "WONTFIX: Not a supported use case". (I'm reminded of how Go had to backpedal on bypassing NTDLL and libSystem to make direct kernel syscalls because, what a shock, Microsoft and Apple weren't lying when they said their kernel syscall ABIs were unstable.)

Regardless of what people like to believe, just because you can interface directly with the C ABI doesn't mean you can force the hand of developers who see it as an unsupported implementation detail. (Especially in situations where they're also relying on some kind of higher-level interface description to generate C glue for them, like how Windows and macOS syscall numbers are unstable because they're just a C enum that gets #included by both the kernel and the userland library without worrying about the stability of the numbers the actual identifiers map to.)

I'm not going to re-read the article in question, but my recollection is that what was really being pushed for was along the lines of "Can someone else please deal with the O(n) cost of duplicating thousands of API calls, because I'm special and I don't want to do [a tiny fraction of] that work myself". That's obviously not even a viable approach, let alone a maintainable one - and that's *before* you get into the sort of hackery that OO languages have.

I don't remember that being an accurate description of it, but I'm tired of pouring effort into this conversation so I won't go back and re-read it to formulate a detailed rebuttal.

Apparently I misunderstood you then: I thought you were just talking about the language in general, not aiming for bitwise compatibility with some specific compiler.
If you do just mean "C" though, there are plenty of compilers written by a single individual. (C++ I think we can agree is *well* into "yeah, no chance" territory).

Yeah. I found some interesting little hobby C compilers when I was identifying novel variants of what the file command outputs for a given hello_world.c to build a test corpus for "identify the type of .exe" code.

[oiaohm]

Apparently I misunderstood you then: I thought you were just talking about the language in general, not aiming for bitwise compatibility with some specific compiler.
If you do just mean "C" though, there are plenty of compilers written by a single individual. (C++ I think we can agree is *well* into "yeah, no chance" territory).

Depends on what version of C standard. It is getting very possible that the latest C standard is past what any single individual can code. We have not see any individual written compilers doing the full current C standard for a decade now. C compilers written by individuals all stop at C99 support no C11 or C17 support. Please note C11 and C17 feature wise is basically the same thing with C17 being errors in standard wording fixed that could have lead to defective implementations.

There are 24 compilers marked as include C99 support this does include TCC that was a single individual.

C11 or C17 that takes you straight down to only 4 compilers none done by individuals.

https://en.wikipedia.org/wiki/C2x

Yes next C standard thing could get even lighter with only GCC, Clang and Pelles C markdown for support it.

arQon yes over the history of C there are tones of C compilers written by individuals reality is majority of current day application code bases in C are not build-able at all with those C compilers.

Hard reality is the latest versions of the C standard may have already crossed into "no chance" for individual to implement alone. Of course if current C standard is "no chance" for individual current C++ with more features is closer to "hell will freeze over first" for individual to code the compiler. Remember from the currently made C compilers we have to presume that current C standard may have moved to "No chance" for individual because no Individual has made a current C standard compiler and this is most likely due to the growing complexity. Also is not only individual that have stopped making C compilers past C99 there are many parties that use to make closed source commercial compilers who don't any more so its getting harder even for teams to make C compilers. Yes scary right C standard might be too complex now for team of 6 to make compiler fully to current day C standard.

Please note coding up the early versions of C++ was not that hard for individual to code up. Thinking the first version of C++ was just a preprocess-or that spat out C with very few checks it was basically to make doing OOP code simpler.

[NobodyXu]

oiaohm I have no doubt that a production-ready compiler would take many people's effort, but for these hobbyists' homebrew compiler, I suspect it is more that they don't want to spend time on their little compiler project anymore.

[oiaohm]

oiaohm I have no doubt that a production-ready compiler would take many people's effort, but for these hobbyists' homebrew compiler, I suspect it is more that they don't want to spend time on their little compiler project anymore.

https://en.wikipedia.org/wiki/C11_(C_standard_revision)
There is a very massive increase in complexity implementing C11. Yes bound checking and threading added to C standard in C11.

Do note for course work and other things people still do make C compilers that match up to standards C99 and before as part of course work and other things.

Hobbyists making C compilers still happen. These new hobbyist C compilers you are not going to be able to use them with modern production code because that don't support modern C standards.

So its not that they are not willing to spend X amount of time making a C compiler. Problem here is the C standard has expanded in size and complexity and those making C compilers for some hobby reason have basically the same max X amount of time to make the C compiler. C99 is basically the upper edge before they run out of time they are willing to put in or appears to be.

https://norasandler.com/2017/11/29/Write-a-Compiler.html

The reality here is like the above link there are people who do attempt to write a C compiler as a individual after C11 comes into existence. They have not been getting past C99 functionality and lot of cases not even getting to C99.

Sorry the idea that people don't want to spend time making a C compiler is false because if you did around there is example after example of people making their own C compiler. The problem is the amount of time to make functionally useful C compiler as standard features increase this time value increases but the amount of time a individual will be able to put into creating a new compiler has a fixed upper limit.

[NobodyXu]

oiaohm No, the compiler author don't have to implement the C std lib, that can be mostly leaved to glibc/musl libc.

Even stuff like _start can be provided by libc, the compiler does not have much concern for the C stdlib.

It just need to implement the C language spec, excluding any C stdlib.

[oiaohm]

oiaohm No, the compiler author don't have to implement the C std lib, that can be mostly leaved to glibc/musl libc.

Even stuff like _start can be provided by libc, the compiler does not have much concern for the C stdlib.

It just need to implement the C language spec, excluding any C stdlib.

C standard does not just define the standard library. You need to read C11 carefully.

https://en.wikipedia.org/wiki/C11_(C_standard_revision)

Hopefully not a broken link this time.

https://en.cppreference.com/w/c/language/analyzability

Features like the new analyzability in C11 are not C stdlib features but compiler features by the C language specifications. Yes analyzability is optional in C11. But there are other bits like Alignment, Type-generic, Static assertions and all the new macro processing stuff that in C11 are required to be there that are also compiler features not C stdlib.

NobodyXu there is quite a step up in what someone making a C compiler needs to implement going from C99 to C11.

I was not talking about the compiler developer having to implement the C library I was really talking about what the C standard mandates the compiler developer has to implement. We are not seeing individual developers making a C compiler in recent years(this is over 10 years now) exceeding C99 requirements for the compiler. This is not that developers are not making C compilers as individuals any more because individuals are still making C compilers in the past 10 years. This instead appears to be a hard limit on how far individuals making a C compiler can get before something happens. Something happens could be they run out of time to put into the compiler or get beaten by the complexity of the features or something else I am not even thinking of.

Most people have seen C compilers still been made and have not looked closer at what C standard they are to so have not noticed what I have noticed..