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

The C23 edition of Modern C

gustedt.wordpress.com

Post reply on HN
Print view View original

321–330 of 360 posts

Re: The C23 edition of Modern C

#321

Post by WalterBright »

sdk77 wrote: post #242
WalterBright wrote: post #60

Earlier quoted context omitted.

Modern C still promptly decays an array to a pointer, so no array bounds checking is possible. D does not decay arrays, so D has array bounds checking. Note that array overflow bugs are consistently the #1 problem with shipped C code, by a wide margin.

The thing is though that even with array bounds checking built into the language, out of bounds access due to programming error can still be attempted. Only this time it's safer because an attacker can't use the bug (which still exists) to access memory outside of bounds. In any case, the program still doesn't work as intended (has bugs) because the programmer has attempted, or allowed the attempt, to access out of b…

In practice in C, that does not work because array overflow bugs are still the #1 bug in shipped C code, by a wide margin.

Re: The C23 edition of Modern C

#322

Post by neonsunset »

uvas_pasas_per wrote: post #316
fluoridation wrote: post #295

Earlier quoted context omitted.

I've been using C++ for the longest time, and I would never give up destructors to switch to C. For your particular use case, have you considered C#? VS works much more nicely with it.

Yeah, I did. I want something low level and cross platform, including mobile. I think when I tried the C# for iOS stuff, nothing worked. But it's probably too much VM/runtime for me anyway, for this project.

iOS C# is more or less fine, there is quite a bit of work done in .NET to make this better still. .NET 9 gains native Swift Library Evolution ABI support even - you can literally declare DllImports against public Swift APIs by simply annotating them with [typeof(CallConvSwift)], it's not as convenient as it sounds but it's only a matter of time when the tools like https://github.com/royalapplications/beyondnet adopt this. It's going to get much better once MonoAOT is replaced with NativeAOT for all major publish modes for iOS.

Re: The C23 edition of Modern C

#323

Post by 3836293648 »

unscaled wrote: post #311
legends2k wrote: post #301

Earlier quoted context omitted.

Arm is bi-endian and is alive in most phones. I agree with another GP's comment that modern doesn't mean popular/widely used.

The book does say "Both orders are commonly used by modern processor types". I'd say this sentence is quite misleading, since it would lead you to believe two falsehoods: 1. That both byte orders are equally prevalent in the wild, particularly in systems that are expected to run modern C code. 2. That both byte orders are equally likely to be found in "modern" (new or updated) processor design. It's not entirely inco…

Don't a bunch of web protocols use big endian?

Re: The C23 edition of Modern C

#324

Post by zifpanachr23 »

School-Cotton wrote: post #258
eqvinox wrote: post #253

> The storage order, the endianness, as given for my machine, is called little-endian. A system that has high-order representation digits first is called big-endian. Both orders are commonly used by modern processor types. Some processors are even able to switch between the two orders on the fly. Calling big endian "commonly used by modern processor types" when s390x is really the only one left is a bit of a stretch…

Isn't Sparc big-endian?

Is SPARC still seeing serious hardware development like s390x? I know it's still around but I can't recall the last time I heard of any new hardware.

Re: The C23 edition of Modern C

#325

Post by AntoniusBlock »

tonetegeatinst wrote: post #300
ondra wrote: post #256

Earlier quoted context omitted.

MIPS is still quite alive in consumer networking hardware.

Learning MIPS assembly currently using mars and QtSpim. Any recommended hardware I should use for bare metal development messing around? Hopefully priced like a SBC like the raspberry pi. Want to move from making basic programs like adding, messing with functions, etc and bring my MIPS assembly up to a real hardware environment.

Many routers use the MIPS ISA and they can be rooted to get shell access. That's what I did with an old Netgear router, which was like a very low spec SBC. If you have a PS2 lying around, you could try that.

Re: The C23 edition of Modern C

#326

Post by RantyDave »

Wait, C programmers now put the star on the left hand side?

char* thing; // good

char *thing; // bad

This ... is awesome. As a C++ "native" I've always found the "star on the right" thing to be really horribly confusing.

Re: The C23 edition of Modern C

#327

Post by bloppe »

RantyDave wrote: post #326

Wait, C programmers now put the star on the left hand side? char* thing; // good char *thing; // bad This ... is awesome. As a C++ "native" I've always found the "star on the right" thing to be really horribly confusing.

Ofc this has always been an option. In my C heyday I used to put a space on both sides of the star. It makes for a more consistent syntax when you have multi layer pointers with const at various layers. For example:

// mutable pointer to mutable data:

char * str;

// Immutable pointer to immutable data:

char const*const str;

// Mutable pointer to an immutable pointer to a mutable pointer to immutable data:

char const**const* strs;

Re: The C23 edition of Modern C

#328

Post by wpollock »

zabzonk wrote: post #163
wpollock wrote: post #131

Earlier quoted context omitted.

The PDP-11 that C originally targeted had address modes to support the stack. Pre-increment and post-decrement therefore did not require a separate instruction; they were free. After the PDP-11 went the way of the dodo, both forms took a machine cycle so it (mostly) became a stylistic issue. (The two operators have different semantics, but the trend to avoid side-effects in expressions means that both are most often…

Please explain what you mean by "a separate instruction".

A MOV and an INC, as opposed to just the MOV.

Re: The C23 edition of Modern C

#329

Post by swells34 »

consteval wrote: post #292
johnisgood wrote: post #156

Personally this[1] just makes C much more complicated for me, and I choose C when I want simplicity. If I want complicated, I would just pick C++ which I typically would never want. I would just pick Go (or Elixir if I want a server). "_BitInt(N)" is also ugly, reminds me of "_Bool" which is thankfully "bool" now. [1] guard, defer, auto, constexpr, nullptr (what is wrong with NULL?), etc. On top of that "constexpr" a…

> If I want complicated, I would just pick C++ which I typically would never want In my opinion, complexity doesn't scale linearly like this. Sometimes, in fact often times, having more complex tools means a simpler process and end result. It's like building a house. A hammer and screwdriver are very simple. A crane is extremely complex. But which simplifies building a house? A crane. If I wanted to build a house wit…

In my experience, complex tools encourage fluffy programming. You mention a generic container; if I were using C, I just wouldn't use a generic container; instead, I'd specify a few container types that handle what needs handled. If there seem to be too many types, then I immediately start thinking that I'm going down a bad architecture path, using too many, or too mixed, abstraction layers, or that I haven't broken down the problem correctly or fully.

The constraints of the tool are inherited in the program; if the constraints encourage better design, then the program will have a better design. You benefit from the language providing a path of least resistance that forces intentionality. That intentionality makes the code easier to reason about, and less likely to contain bugs.

You do pay for this by writing more boilerplate, and by occasionally having to do some dirty things with void pointers; but these will be the exception to the rule, and you'll focus on them more since they are so odd.

Re: The C23 edition of Modern C

#330

Post by nineteen999 »

3836293648 wrote: post #323
unscaled wrote: post #311

Earlier quoted context omitted.

The book does say "Both orders are commonly used by modern processor types". I'd say this sentence is quite misleading, since it would lead you to believe two falsehoods: 1. That both byte orders are equally prevalent in the wild, particularly in systems that are expected to run modern C code. 2. That both byte orders are equally likely to be found in "modern" (new or updated) processor design. It's not entirely inco…

Don't a bunch of web protocols use big endian?

You can go lower than that, TCP/IP itself is big-endian (see RFC 1700).
Post reply on HN