C Is Not A Language Anymore

ASN.1 - the lingua-franca of data - that is all...
"Your language has problems interfacing with the local C implementation? Your language finds it uncomforable running on that hardware.
Why do you want to link to C? because it interfaces properly with the hardware for drivers and high performance data.
Why doesn't your language do that? because it is designed around a pseudo-platform.
Why doesn't C link between platforms? ASN.1 was invented for just that.
What about my big buffer of binary/media data that I don't want to copy? Pointer to a buffer of ASN.1 parameters + optionally a pointer buffer to ASN.1 encoded metadata + optionally a pointer to a big buffer(s) of data = happy interface
I don't know enough C or ASN.1... I can't help you with that. But if someone defines the ASN.1 at least the people on either side can implement it separately using the extensive tools and libraries available."

C is great because it works the way the CPU works, including with the types that the CPU natively supports. It makes it easy to write programs that will run efficiently on your target platform. With most other languages, code that looks tight could compile into pages of machine code, or waste memory and CPU cycles by making redundant copies of data.

>be language dev
>too lazy to implement a proper interop layer between your lang and the OS
>decide to just reimplement C's types
>"Wtf why does this suck"
Many such cases

C is almost a real programming language. Assembly is the real programming language, except that assembly language is a collection of hundreds of wildly different languages. Z80 assembly is very different from PIC16 or DSP56k or S08 or S12X, ARM, IBM 370, RGP30… all different. That’s the source of the type/size issues in C. I’m lucky enough to program embedded systems but even then, C isn’t the same between different processor platforms.

Long holds exactly 1 pointer on the current platform. On i386, long is 32bits. On x64, long is 64bits.

"I want to write a language that compiles and runs without talking to the hardware"
Skill issue of skill issues.

This article is just someone bitching that software has to run on physical hardware.

These guys know nothing about the history and power of the C language. It is a hard watch.

Programming is like a lake, a very old untouched lake with no fish in it. The surface is all nice and clear but deep down there's mud and decaying plant matter. I like diving deep in there cuz I like rolling around in that mud but it sure feels icky every time lol.

intmaxxednocap_t

Yep they are crying because the Teenagers are not in-charge and don't like it when the parents say 'because I said so'.

Isn't this like the Teenagers complaining about their parents being out of touch?

This is not C, this is messy ABI standards.

Hell, why not have intxnnn, where nnn is any string of hex digits? intx10 would be int16. Might as well specify alignment, too: intx40a20 for a 64bit integer aligned to 32 bit boundaries.
Oh, wait, old C programmers like octal.

I've been programming for money for more than 40 years. Still do. So. Punching IBM cards sucks. Punched tape sucks. Machine language sucks. Assembler sucks. C doesn't suck so much. Actually, in the day & age of Kerrigan & Richie, C was like hallelujah! I bet small electronics, like thermometers, smartcards, or maybe even microwaves, is still programmed in C.

No, int is always 32bit even on 64bit system. It's an assumption.. hmm.. I'd call it a gentleman agreement with the older generations.

Also, there's Godel's theorem - there's no type of system that can solve every problem. C is the king on pedestal because the people demands it - not that he's the best king, but he's a functional one.

Instead of wasting so much time designing and learning these new fangled languages, just take the time to learn C/C++ properly

XKCD 927 was published in July 2011 and I am gratified to see the cycle continues unabated.

Objective-C++ is basically to deal with C++, and Objective-C is quite a decent language better than C++ in some areas in general, what’s needed is C++ & Objective-C to merge to take the whole C to the next level as Objective-C has some really nice features as well as C++, both have their bad parts.

Why Prime , why this click baita baite OMG>....

can confirm England has no desire to improve itself. Go America, fuck the past

Wait, so i haven't learnt a single programming language so far??

The main problem with that: The solution is BLOAT
You have only 2 options to really fix this problem:
1) Use a proper C protocol ABI, agree with major compiler teams and FORCE everyone to use that (would bloat because it would be a huuuuuge stdlib)
2) Implement a direct call to the system at binary level for every version

if you squint, every language is C and SQL in disguise.

Ik what long is - my D ;)

If i remember correctly Long is either a name of a float or a longer int. long long is a double length float i think.
Unsigned means it will not loop to opposing highest number after exceeding the max number, thought I might confuse that.

Oooohhh... somebody realized that C still rules all and is be all, and all, and their feelings are hurt... NOW BEND OVER!

The person who wrote this article should write a bootloader, kernel, terminal and then interfacing with a programming language. Most used OS's used C to program the OS, so it makes sense it would be C. I'm sure there are some new OS projects going with Rust.

If you want the natively sized integer, use (s)size_t or (u)intptr_t. I think of "int" as the smallest "efficient" type. For serialization, use fixed sized integers, and remember to consider padding.

"size_t" is supposed to be the maximum size a structure could possibly be on the given architecture. Though by now this basically assumes it is uint32_t on 32 bit systems and uint64_t on 64 bit systems because of how memory access works. However there could theoretically be systems that have native support for 64bit integers and might be seen as a 64bit architecture but have a 32bit or 128bit address space, which would lead to issues since in that case size_t would need to be uint32_t or uint128_t (which does not exist)

Though technically the correct type to index a container doesn't have to always be size_t. It is officially defined to be std::<container_name>::size_type which just happens to be size_t most of the time

Why C does not have a single defined ABI: Because when you call a function in C, some args go in registers, and some on the stack. Which ones are CPU-dependent. But at least any two C compilers on the system should theoretically be able to link to that system's standard C and other libraries. THAT IS NOT TRUE FOR C++. In fact literally two versions of the gcc compiler generate completely incompatible versions of everything so that you have to recompile everything linked against anything.

This is why, in 2024, Haiku still has support for gcc 2.95. The OS was originally trying to be compatible with BeOS using gcc 2.95 and any later version's C++ is not compatible with that ABI interface anymore. This just is something Bjarne doesn't give a flying crap about.

I find it hilarious how much rust fanbois complain about C abis and apis, while rust in itself is an unstable, constantly breaking mess.

There are two compatibility issues here: hooks and assembly. They are complaining about JNI issues. These are mostly just translation concerns in the compartmentalization layer. (Performance loss is possible here.)

Hooks:
Network protocol/proxy is basically the answer. Compatibility issues are usually self inflicted here. One exception is endianness, C and C++ cannot escape this. (Usually JNI hides this as this comes from assembly.)

Assembly:
C was originally created for abstracting assembly. Many people use C APIs for compatibility from assembly ABI! We are mostly attacking compilers and C extensions here. This argument is outside the original scope of C and we can thank most of modern hardware for that.

C is a letter

In all honesty, types like intmax_t should be used at most intenally, not exported outside of library nor serialized at all. For all public purposes I'd never use anything that doesn't specify explicitly the bit length. Even if under the hood it is typedef'd to long, long long or a dwarf, but I know someone made sure that it's the right size for platform.

"C doesn't have an ABI" is just way too funny. He should try to find registers named RAX to RDX on a MIPS device. I'd give him a million dollars if he found one. 😂

but is it __cdecl, __pascal or __stdcall? ;-)

here it is a rare footage of a ThePrimeagen wearing a t-shirt instead of a hoodie

C is basically a high level version of assembly language. Because of that it lends itself well to being a low level system language.

There are some guarantees. But they aren't the ones you want. An int is at least as long as a char. A long is at least as long as an int. That sort of thing. Floats are easier since there is IEEE-754. If you want well defined integer type sizes, you're going to have to define them. I would use a uint64_t over a long long. As for size_t, I think that works out to the same length as a pointer. That is, sizeof(size_t) == sizeof(void*). When C was growing up, there were many architectures about. It only started with the PDP-11.

"I haven't reached the disgusting layer"

uses Lua

Why are a bunch of scriptoids bitching about C? Go write you javagoy and your html bozo

I program in C daily. My only comment here is - fucking Furry problems, i mean really...

long_uint_max would solve everything

size t is an address on the machine sized uint.

Int max is not the max lolllll 😂 I feel the pain. Long long supposed to be 128 bit, to my knowledge a long time ago.
Long long long is 256 bit but only works on computers that have dual channel DDR setup.

Just a grumpy old embedded engineer here. The question is what your job is. If your job is to make software that must work on a CPU that has less than 256 pins or operating voltage more than 1.5V, you are most probaly left with only C/C++ toolchains. Assuming you want to avoid assembly. The hardware mentioned above is basically everything your world is operated by. Want something working above 80 degC? Something that should work on a wide voltage range? If one does not want to learn new assembly for each of the targets at hand, C is the language of the cheap hardware. To my surprise, the most vocal people against C is the ones who use joe, vi, emacs or some other vintage exotic editors.

Yeah, I can see this. We really are at the point where C is more of a protocol than anything else.

which is future language ?