Since GCC 13 made the first page, it’s worth pointing out that 13 marks *-solaris2.11.3 obsolete and the backend will be removed entirely in 14. In order to get it in 13, you need to build GCC with --enable-obsolete. It’s always hard to judge who may still use or need this, but just throwing it out there.
edit: Sorry, didn't mean to say 11.4 was obsolete. If you know of 11.3 machines that still exist, upgrade them!
Citation? The 13.1 change notes [1] indicate Solaris 11.3 has been dropped, because it has some things in it that make supporting it and 11.4 hard. [2]
I don't see anything about sparc generally, let alone sparc-solaris specifically[1]
Not so soon. SPARC is still (somehow) alive and is produced as SPARC M8. The highest spec'd CPU (SPARC M8-8) comes with 256 CPU cores and 2048 threads in up to 8 CPU configurations.
All quite reasonable additions to the language, kudos to the GCC team.
I'm /very/ sad to see the unprototyped functions to go though -- that was my favourite way to catch newbies off-guard! Oh well ...
As for those who like to spend their Friday afternoon feeling sad about C++isms creeping into C: You are very late! You should have done that when GCC implemented ``__attribute__((cleanup))`` years^Wdecades ago.
It's unfortunate that a scope cleanup mechanism, like __attribute__((cleanup)), wasn't introduced. There was a proposal for one but it relied on lambda's which didn't make the cut for C23.
Standard Pascal did not store string length and had no notion of variable-length strings. This was such an egregious design failure that various dialects came up with non-standard, non-portable, compiler-specific work-arounds. In the 1980's, it was next to impossible to write a Pascal program that worked cross-platform and did anything with strings.
The first ISO standard to address this wasn't until 1990, with yet a new dialect called Extended Pascal, which of course wasn't compatible with the various earlier system-specific dialects, and anyway was way too late for Pascal to "win" over C.
See Wikipedia for confirmation: "Brian Kernighan, who popularized the C language, outlined his most notable criticisms of Pascal as early as 1981 in his article "Why Pascal is Not My Favorite Programming Language". The most serious problem Kernighan described was that array sizes and string lengths were part of the type, so it was not possible to write a function that would accept variable-length arrays or even strings as parameters."
> Pascal had the correct format for strings, the one you mentioned and the one used by all modern languages.
Not really. The most crucial insight is that your string references should be fat pointers, which is not what Pascal does. Look at Rust's &str for the state of the art. Other choices are less important, but having string references be fat pointers is a huge boon. It would probably have seemed profligate in the 1980s, but it was the right choice.
Gotta love the Str255 used everywhere on Macs before OS X came around. That was how Pascal did things on Macs in the 1980s, and it’s not exactly modern—if you want something longer than 255 characters, it’s going to be cumbersome.
Been digging through old newsgroups, and it sounds like one of the big reasons C won out over Pascal was because it was easier to find good C compilers in the 1980s compared to good Pascal compilers.
You can use them, but if you have two pieces of independently developed code, chances are good they're not going to use the same kinds of data structures. Unless they are arrays of 0-terminated strings.
C (unlike e.g. Zig) doesn't have any builtin 'struct types' (not sure about VLAs though, but those had been a dead end anyway). Adding such types into the language would be quite a change in philosophy.
VLA are exactly an array type that knows its length, i.e. a dependent type. VLAs on the stack had some issues, but pointers to VLAs, i.e. variably modified types are quite powerful. Language and compiler support is still evolving though.
> I think that if you want that, you're working with the wrong language.
Maybe yes, maybe no. Walter Bright, the creator of D, has a nice article on the subject [1]. I think Zig's approach which allows slices to decay to pointers and pointers+lengths to create slices is ideal. The real benefit of slices is the implicit bounds checking which some C folks might object to since one of the appeals of C is no "hidden magic".
One could say that for any feature that a language got later on and everybody feels fine with it added.
Go/Java and generics for example. C++ and auto or closures. Javascript and async/await ("just learn regular Javascript async patterns").
The thing is C could have had a string type that knows its length since day one, with known performance tradeoffs, and also allow for everybody to build their own type in the more rare cases where it's needed.
And most of buffer overflow and string handling bugs would have been avoid, as most of the programs using them don't need the performance or special handling of C strings (or don't need them where the bugs occur, e.g. when reading some configuration file).
I am not that against most of these. However, I don't think I ever will be for using 'auto' in C. Good C is about being extremely clear about what you want to happen at every step. Type inference goes against that imo. If you complain about writing a few more characters I don't think C is the language you are looking for. And I try to not use the "then C is not for you" line very often - I promise.
> [T]hey keep adding features to C, such as type inference [...].
The thing about typeof (and its close cousin auto) is that it exposes information that the compiler’s frontend has to know anyway for type checking. That’s why GCC has had typeof for many years, even back when it only spoke pure C. So while it’s a new feature, it doesn’t really have a lot of implications for the rest of the language.
As far as ISO is concerned, each edition of the C standard is made obsolete by its successor, but that doesn't impose any obligation on you or on compiler writers. If you have gcc, you can still use `gcc -std=c90 -pedantic-errors` (or c99, or c11, or ...).
I don't write C / C++ so I'm not too aware of what's going on there, but wouldn't someone that wants those features just switch to C++? Is there any reason to change C at this point?
Switching to C++ gets you lots of things that aren’t “C-like” (that, of course, is a vague term that, as this thread shows, people will disagree about, but I think there’s consensus that C++ has many features that aren’t C-like), and may get you subtle bugs because of small incompatibilities between C and C++. For example, sizeof('x') is 1 in C++, but >1 in C because 'x' is a char in C++ and an int in C.
Many things that C++ added on top of C aren't actually improvements (I guess the most charitable thing that can be said about C++ is that it identifies and weeds out all the stupid ideas before they can make it into C).
A usual programmer doesn’t need most features of C++ but there are many important:
Generic-programming with templates, a usable std::string, smart-pointers, references, the howl standard-library (streams, file access, containers, threads).
The controversial ones seem to be exceptions and classes. Exceptions affect programming flow, exception safety is very hard and the runtime costs are an issue depending on the environment. Class and inheritance are complicated feature, operator overloading is one of the best stuff I’ve seen. But I can understand why many programmers don’t want handle all the special rules involving classes.
Especially when there's Go, Rust, etc. these days. There is so much legacy with C++ the language that it's pretty easy do do stuff subtly wrong if you're not rigidly careful and adhering to a style guide that forces you to only use the safer bits.
Maybe. But by reading the article one does get the impression that GCC devs (and C2X proposal authors) really like C++: the language is mentioned 16 times, and easily half of the features are lifted more or less as-is from there.
I wish the C Standard Committe stopped smearing all C++ bullshit in to C. Now that many of the C++ people who promoted those features are abandoning the ship.
It's what you get when your C compilers are implemented in C++.
Why "bullshit"? I looked at the article, and everything looks extremely reasonable, and desirable in C.
* nullptr: fixes problems with eg, va_arg
* better enums: Who doesn't want that? C is a systems language, dealing with stuff like file formats, no? So why shouldn't it be comfortable to define an enum of the right type?
* constexpr is good, an improvement on the macro hell some projects have
* unprototyped functions removed: FINALLY! That's a glaring source of security issues.
Really I don't see what's there to complain about, all good stuff.
A lot of these ARE relevant and useful improvements to the C language itself; constexpr reduces the need for macro-constants (which is nice), ability to specify the enum storage type is often helpful and clean keywords for static_assert etc. are a good idea too.
And getting rid of the "void" for function arguments is basically the best thing since sliced bread.
I don’t understand why anyone would use the “auto” variable type thing. In my experience it makes it impossible to read and understand code you aren’t familiar with.
I miss the simple days of just regular K&R and a decent lint. c was suppose to be a nice small simple language, but each standard adds more and more complexity.
Oh come on, pure K&R-C is a pain to read and write even for old-school C enthusiasts, and C99 brought some really nice improvements (like compound literals and designated initialization) while not overloading the language with bells and whistles, it's mostly just logical extensions of existing syntax that should have worked to begin with.
And C-isms like '= { 0 };' instead of '= { };' never really made a lot of sense.
I used to think like this. Then I had to use `thread_local` where it was so much more convenient and portable (and likely faster) than pthread_getspecific. I think it's good quality of life features get added and standardized.
Even Linux kernel uses lot of GNU extensions. Computers are there to abstract stuff for us.
> I think the loop iterators are the biggest user-visible thing, but
> there might be others.
Also interesting:
> Of course, the C standard being the bunch of incompetents they are,
> they in the process apparently made left-shifts undefined (rather than
> implementation-defined). Christ, they keep on making the same mistakes
> over and over. What was the definition of insanity again?
C syntax is already too rich and complex. What it needs is not more but less and some fixing:
Only sized primitive types (u8/s8...u64/s64, f32/f64); typedef, enum, switch, all but one loop keyword (loop{}) should go away; No more integer promotion, only compile-time/runtime explicit casts (except for literals, and maybe void * pointers); explicit compile-time constants; no anonymous code block; etc.
That said, if risc-v is successful, many components will be written directly in assembly, and trash-abl code will be written in very high-level languages with risc-v assembly written interpreters (python/perl5/lua/javascript/ruby/php/haskell/tintin/milou).
IMHO C should remain a language that is easy to write a compiler for (and there have been many examples of individuals doing it, some of which have appeared on HN in the past), i.e. one should be able to "bootstrap" from it.
A "nice small simple" thing implies that someone has the power to say "that's it, we're freezing it the way it is". Instead, usually there is pressure to add, change, 'improve', keep up with the Joneses.
Not enough, if you ask me. It's treated mostly like a museum language, like classical music, with some polishing and quality of life improvements (that came 50 years too late, like checked arithmetic).
I am starting to see value in fixing a language when you hit 1.0. No more language changes at that point. If you want to change something, it has to be in a library.
Everyone is so angry in the comments about c adopting c++ traits. I do not see it that way. This is not the language standard this is just GCC. Clang and GCC have always had compiler specific features which could only be described as wizardry to a regular c user. GCC has always kept the c standard at arms length, clang is a bit better but using compiler specific features has always been reserved for mavericks. Conversely, C23 has some great additions, none that remind me of C++? [1]. I don't think the standards enthusiasts that hang out on #c in freenode would be happy to think this many people see c going in the direction of C++.
Readit News
If you wonder why:
https://open-std.org/JTC1/SC22/WG14/www/docs/n2927.htm#exist...
https://www.scs.stanford.edu/~dm/blog/decltype.html
The real question to ask is why decltype(value) is int.
edit: Sorry, didn't mean to say 11.4 was obsolete. If you know of 11.3 machines that still exist, upgrade them!
I don't see anything about sparc generally, let alone sparc-solaris specifically[1]
[1] https://gcc.gnu.org/gcc-13/changes.html
[2] https://gcc.gnu.org/pipermail/gcc/2022-December/240322.html
https://www.oracle.com/a/ocom/docs/sparc-t8-m8-server-archit...
Deleted Comment
I'm /very/ sad to see the unprototyped functions to go though -- that was my favourite way to catch newbies off-guard! Oh well ...
As for those who like to spend their Friday afternoon feeling sad about C++isms creeping into C: You are very late! You should have done that when GCC implemented ``__attribute__((cleanup))`` years^Wdecades ago.
edit: https://gcc.gnu.org/legacy-ml/gcc/2003-05/msg00528.html
https://www.godbolt.org/z/KaWzsc6qT
...in GCC it's still just a warning though.
Imagine the humble pie C would have to eat.
C beat out Pascal in the 80s for a lot of reasons, many of them not technical.
Pascal had the correct format for strings, the one you mentioned and the one used by all modern languages.
Imagine if after 40 years C would start using Pascal strings :-))
The first ISO standard to address this wasn't until 1990, with yet a new dialect called Extended Pascal, which of course wasn't compatible with the various earlier system-specific dialects, and anyway was way too late for Pascal to "win" over C.
See Wikipedia for confirmation: "Brian Kernighan, who popularized the C language, outlined his most notable criticisms of Pascal as early as 1981 in his article "Why Pascal is Not My Favorite Programming Language". The most serious problem Kernighan described was that array sizes and string lengths were part of the type, so it was not possible to write a function that would accept variable-length arrays or even strings as parameters."
Not really. The most crucial insight is that your string references should be fat pointers, which is not what Pascal does. Look at Rust's &str for the state of the art. Other choices are less important, but having string references be fat pointers is a huge boon. It would probably have seemed profligate in the 1980s, but it was the right choice.
Been digging through old newsgroups, and it sounds like one of the big reasons C won out over Pascal was because it was easier to find good C compilers in the 1980s compared to good Pascal compilers.
https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas...
But you can get run-time bounds checking already: https://godbolt.org/z/jhcavobYj
Support for statically detecting problems is also (slowely) improving.
Apparently you mean something by "struct types" other than the well known C feature. Can you elaborate?
Maybe yes, maybe no. Walter Bright, the creator of D, has a nice article on the subject [1]. I think Zig's approach which allows slices to decay to pointers and pointers+lengths to create slices is ideal. The real benefit of slices is the implicit bounds checking which some C folks might object to since one of the appeals of C is no "hidden magic".
[1] https://digitalmars.com/articles/C-biggest-mistake.html
Go/Java and generics for example. C++ and auto or closures. Javascript and async/await ("just learn regular Javascript async patterns").
The thing is C could have had a string type that knows its length since day one, with known performance tradeoffs, and also allow for everybody to build their own type in the more rare cases where it's needed.
And most of buffer overflow and string handling bugs would have been avoid, as most of the programs using them don't need the performance or special handling of C strings (or don't need them where the bugs occur, e.g. when reading some configuration file).
So working with C or C++, it is.
https://digitalmars.com/articles/C-biggest-mistake.htmlhttps://dlang.org/articles/d-array-article.html
They could call the language "Stone", and then we'd get to say "such and such program is written in Stone", "not written in Stone", etc.
If they keep adding features to C, such as type inference, won't C just ultimately become as feature-laden as C++, albeit on a much longer timescale?
What's the point of that?
The thing about typeof (and its close cousin auto) is that it exposes information that the compiler’s frontend has to know anyway for type checking. That’s why GCC has had typeof for many years, even back when it only spoke pure C. So while it’s a new feature, it doesn’t really have a lot of implications for the rest of the language.
As far as ISO is concerned, each edition of the C standard is made obsolete by its successor, but that doesn't impose any obligation on you or on compiler writers. If you have gcc, you can still use `gcc -std=c90 -pedantic-errors` (or c99, or c11, or ...).
https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B
Generic-programming with templates, a usable std::string, smart-pointers, references, the howl standard-library (streams, file access, containers, threads).
The controversial ones seem to be exceptions and classes. Exceptions affect programming flow, exception safety is very hard and the runtime costs are an issue depending on the environment. Class and inheritance are complicated feature, operator overloading is one of the best stuff I’ve seen. But I can understand why many programmers don’t want handle all the special rules involving classes.
Meanwhile, WG14, "not our problem ".
Deleted Comment
I get people don't like classes / templates / .. but there isn't any reason one has to use those.
It's what you get when your C compilers are implemented in C++.
* nullptr: fixes problems with eg, va_arg
* better enums: Who doesn't want that? C is a systems language, dealing with stuff like file formats, no? So why shouldn't it be comfortable to define an enum of the right type?
* constexpr is good, an improvement on the macro hell some projects have
* unprototyped functions removed: FINALLY! That's a glaring source of security issues.
Really I don't see what's there to complain about, all good stuff.
A lot of these ARE relevant and useful improvements to the C language itself; constexpr reduces the need for macro-constants (which is nice), ability to specify the enum storage type is often helpful and clean keywords for static_assert etc. are a good idea too.
And getting rid of the "void" for function arguments is basically the best thing since sliced bread.
And C-isms like '= { 0 };' instead of '= { };' never really made a lot of sense.
Even Linux kernel uses lot of GNU extensions. Computers are there to abstract stuff for us.
C++ is becoming more complex and bloated over time.
C, on the other hand, is becoming more convenient with almost no bloat or confusing features.
C is aging slowly but graciously, in my opinion.
Most of the good stuff is written in it: sqlite, curl, STB libraries, zlib, OS kernels etc.
Many are, but Linux moved to C11 (well gnu11 I guess) since v5.18
Summary of discussion: https://lwn.net/Articles/885941/
Actual move https://git.kernel.org/linus/e8c07082a810fbb9db303a2b66b66b8...
Being able to replace
with makes it already worthwhile.Linus thinks so too:
Also interesting: -- https://lwn.net/ml/linux-kernel/CAHk-=wicJ0VxEmnpb8=TJfkSDyt...That said, if risc-v is successful, many components will be written directly in assembly, and trash-abl code will be written in very high-level languages with risc-v assembly written interpreters (python/perl5/lua/javascript/ruby/php/haskell/tintin/milou).
[1] https://open-std.org/JTC1/SC22/WG14/www/docs/n3054.pdf