Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Carbon’s most exciting feature is its calling convention

foonathan.net

Post reply on HN
Print view View original

71–80 of 223 posts

Re: Carbon’s most exciting feature is its calling convention

#71

Post by staticassertion »

__float wrote: post #65
staticassertion wrote: post #41

Earlier quoted context omitted.

> The other safe languages have explicitly taken the view the interop with C++ is bad I think it's more that interop with C++ is hard and ultimately a lot less valuable than interop with C, which is what the vast majority of languages use for FFI. > It doesn’t matter how “safe” your language is if the first thing you have to do is make a pure C (even losing potential for automatic lifetime management the C++ would al…

If you consider the context of Carbon (Google having a _lot_ of C++), solving for "interop with C++ is hard" might be considered worth the price. Whether that's true in practice...? I guess we'll need a few more years to tell.

Of course, that's why they're building it. They're solving a very specific, niche, hard problem. It would make no sense for other languages, which want to solve more general problems, to tackle C++ interop over C.

Re: Carbon’s most exciting feature is its calling convention

#72

Post by tialaramex »

josephcsible wrote: post #57
hedora wrote: post #55

Earlier quoted context omitted.

That's a buffer overflow. The optimizer doesn't need to reason about changing the behavior of such things.

The point is that on systems where that code returns 42, `p` has the exact same value it would if I did `int *p = &x;` instead, but not the same provenance.

And because C++ says "one past the end" pointers are a thing, both these pointers can exist.

As written p is a one-past-the-end pointer into object arr, but the address one past the end of arr may well be the address of x. If pointers are just addresses, these pointers are the same... right?

Neither C nor C++ currently actually explain how this works for their "abstract machine" in the standards documents. The reality is that your C++ compilers (and any non-toy C compilers) have pointer provenance because it's a nightmare to optimise C programs without, but since it isn't documented anywhere (my understanding is that C23 might fix this for C by taking a TS and an equivalent fix via P2318 could land in C++ 26) it's difficult to say if you ever find bugs in their behaviour.

Re: Carbon’s most exciting feature is its calling convention

#74

Post by josephcsible »

tialaramex wrote: post #72
josephcsible wrote: post #57

Earlier quoted context omitted.

The point is that on systems where that code returns 42, `p` has the exact same value it would if I did `int *p = &x;` instead, but not the same provenance.

And because C++ says "one past the end" pointers are a thing, both these pointers can exist. As written p is a one-past-the-end pointer into object arr, but the address one past the end of arr may well be the address of x. If pointers are just addresses, these pointers are the same... right? Neither C nor C++ currently actually explain how this works for their "abstract machine" in the standards documents. The realit…

> And because C++ says "one past the end" pointers are a thing, both these pointers can exist.

While one-past-the-end pointers are allowed to exist, they are not allowed to be dereferenced.

> these pointers are the same... right

The entire point of provenance is that even though their numerical values are the same, they are not the same.

> Neither C nor C++ currently actually explain how this works for their "abstract machine" in the standards documents.

While it isn't mentioned explicitly, it can be inferred from other things that the standard does say. The compiler authors didn't just make it up.

Re: Carbon’s most exciting feature is its calling convention

#75

Post by tialaramex »

TylerGlaiel wrote: post #62
tialaramex wrote: post #25

C++ also pays a price for insisting not only that objects have addresses, but those addresses are distinct. If you've got a 1.6 billion empty tuples in variable A, 1.4 billion in variable B and 1.8 billion in variable C, C++ can't see a way to do that on a 32-bit operating system. It needs to give each empty tuple an address, so it must think of 4.8 billion integers between 0 and 2^32 and it can't do that, so your pr…

since C++20 you can get around this https://en.cppreference.com/w/cpp/language/attributes/no_uni...

comex mentions this above. It's a nice hack, but it doesn't actually fix the problem I was talking about, you can give this attribute to a data member, which allows you to do the ZST marker type trick that is available in other languages, but you can't apply the attribute (at least, not as documented) to a type itself, those empty tuples are obliged to take up one byte each.

Re: Carbon’s most exciting feature is its calling convention

#76

Post by nathanlied »

serial_dev wrote: post #64
labrador wrote: post #46

Earlier quoted context omitted.

Google engineers: "Let's make our languages hard to Google!" Google managers: "Whatever floats your boat. How about Go, Dart and Carbon?"

I've been a Dart developer for three years and had zero issues finding anything Dart related. I also had to write some Go, that was actually pretty bad in terms of searchability.

For me it has helped to write it as "golang"; usually Google seems to understand what I want and show me relevant results.

Re: Carbon’s most exciting feature is its calling convention

#77

Post by TillE »

axegon_ wrote: post #67

Dunno about the most exciting but the most irritating so far is seeing it up. Admittedly I didn't spent a lot of time trying(I didn't have all that much time today) but in the 40 minutes or so, I was unable to get it going. I'll go back to attempting tomorrow and make sense of the errors.

I mean there's not even a toolchain yet, it's just an interpreter to play with, and you can use it on godbolt.org

I'd only worry about compiling it yourself if you intend to participate in Carbon's development in the near future.

Re: Carbon’s most exciting feature is its calling convention

#79

Post by bsder »

zeusk wrote: post #29
tialaramex wrote: post #25

C++ also pays a price for insisting not only that objects have addresses, but those addresses are distinct. If you've got a 1.6 billion empty tuples in variable A, 1.4 billion in variable B and 1.8 billion in variable C, C++ can't see a way to do that on a 32-bit operating system. It needs to give each empty tuple an address, so it must think of 4.8 billion integers between 0 and 2^32 and it can't do that, so your pr…

Maybe the right question to ask is, why you have 4.8 billion empty tuples? And why you're still on a 32-bit system?

Gamedev, presumably. It's not unusual to have a LOT of triangles and coordinates flying around and GameDev is basically locked to C++ (for many good reasons even if I find C++ distasteful).

Admittedly, those probably aren't running on 32-bit systems, nowadays ...

Re: Carbon’s most exciting feature is its calling convention

#80

Post by moonchild »

bsder wrote: post #79
zeusk wrote: post #29

Earlier quoted context omitted.

Maybe the right question to ask is, why you have 4.8 billion empty tuples? And why you're still on a 32-bit system?

Gamedev, presumably. It's not unusual to have a LOT of triangles and coordinates flying around and GameDev is basically locked to C++ (for many good reasons even if I find C++ distasteful). Admittedly, those probably aren't running on 32-bit systems, nowadays ...

Presumably, your triangles have 3 sides, and your coordinates exist in at least one dimension?
Post reply on HN