News for hackers. Stuff that matters.
Re:A Tale of Two Libcs by buster on Saturday September 26, 2020 @05:59AM (#24597612)
I think one major point is the unreadable mess, though. Is there a reason for this?
Re:A Tale of Two Libcs by johannes1234321 on Saturday September 26, 2020 @08:15AM (#24598232)
There are a number of reasons:

- Support for weird compilers

- Focus on performance, thus playing "weird" tricks with macros, lookup tables etc.

- especially in headers: protect against users doing crazy sh*t

- standards sometimes change or see extensions

- certainly more :)

First two items can be re-evaluated form time to time, but especially GNU often aims to run "anywhere"

The third item comes from the fact that users can create macros for many things and only some names (leading _ and capital letter or __) are reserved for standards or C++ allowing to overload the comma operator, which can have weird effects. Thus to be conformant to the standards some ugliness is required.

The fourth point combined with different compatibility requirements requires tricks to switch between different implementations based on compiler flags/macros (for instance `#define _GNU_SOURCE` or `#define _POSIX_C_SOURCE=...`)

Re:A Tale of Two Libcs by rightbyte on Saturday September 26, 2020 @06:04AM (#24597631)
Any big standard lib I laid my eyes on (gcc, clang, MS headers) seems to be a mess. I too wonder if the complexity is really necessary, but I guess so? Macros in my experience is ofent to fool the compiler to generate better code. Maybe that is a legacy reason?
Re:A Tale of Two Libcs by ThreeFx on Saturday September 26, 2020 @08:04AM (#24598160)
99% of the time the answer is speed. It's just way faster to evaluate and build all of this at compile time than at runtime.

I understand both sides of the argument here - on one hand you have fast and unreadable code and on the other hand slower and more readable code. The problem here is 1. the leaky abstraction of characters and code points and 2. loss of type safety due to C's weak typing rules, which is a bit lost in the "hurr durr messy code."

Re:A Tale of Two Libcs by DaiPlusPlus on Saturday September 26, 2020 @08:09AM (#24598190)
Windows.h is still full of obsolete ancient macros that can’t be removed for compatibility. Things like references to near and far pointers (still!) and how every Win32 function with string params is a macro for the real A/W-suffixed functions, and all the A-suffixed functions now intentionally crash on post-98 systems.
Re:A Tale of Two Libcs by tjalfi on Monday September 28, 2020 @12:27AM (#24612954)
> all the A-suffixed functions now intentionally crash on post-98 systems.

Do you have a source for this claim?

I find it hard to believe that Microsoft would drop support for ANSI applications.