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

ISO C is increasingly moronic

varnish-cache.org

Post reply on HN
Print view View original

81–90 of 175 posts

Re: ISO C is increasingly moronic

#81

Post by tedunangst »

teyc wrote: post #49
phkamp wrote: post #17

Earlier quoted context omitted.

First of all: You're wrong, the compatibility is the other way around: The old code will have to include if they used the "noreturn" compiler-specific keyword, while waiting for the glacial ISO WG progress. Second: There are two kinds of compatibility: Forwards compatbility and backwards compatibilty. There is a finite number of existing programs whereas the number of future programs to be written is unbounded and ve…

The "Backwards compatibility, no matter the cost" mentaility is costing us dearly in the quality of the tools we have work with in the future, while providing us no relevant new benefits. That is only because you don't have a vested interest in old code bases. (Taking a rough guess here: you're under 30?)

phk under 30? hahaha. Does freebsd count as an old code base?

If you direct your remarks at what's being said instead of who (you think) is saying it, you wouldn't miss so wildly.

Re: ISO C is increasingly moronic

#82

Post by to3m »

phkamp wrote: post #62
bhurt wrote: post #58

The C standards committee has been broken since C99 introduced long long, thus silently breaking conforming code. How do you print out a size_t, portably, without losing information? The standard says size_t is an unsigned integer type, but doesn't say way size. However, the C89 spec explicitly stated that there are no integers sizes longer than long- so the conforming way to do this is to explicitly cast the size_t…

You overlook the %z printf specifier which attempts, but not quite solves the problem, because size_t comes in both a signed (ssize_t) and unsigned (size_t) variant. I usually end up doing printf("%j", (intmax_t)foo);

Won't "%zu" vs "%zd" do the trick? `z' is a modifier, like `l'.

(That said, I've only ever used %zu myself... don't think I've ever used ssize_t. I'm pretty sure it's non-ISO.)

Re: ISO C is increasingly moronic

#83

Post by tedunangst »

The deal with underscores isn't anything new, that was there in C99 for sure. Maybe C89 but I don't know. In any case, I think getting upset about a more than decade old change is a little late and detracts from the main point.

Re: ISO C is increasingly moronic

#84

Post by pmr_ »

reacweb wrote: post #47
ajross wrote: post #41

Earlier quoted context omitted.

That's not what C1X is for. It's a straightforward evolution of ISO C99 which adds features without breaking anything. If you want a similar low level language which is not compatible with legacy C you don't have to look far: history is littered with their carcasses .

Think about C++: not only legacy C++ was broken by each standard, it was also broken by each compiler releases. The change of compiler release was always a journey. It is normal that introduction of a new keyword breaks legacy C. A new standard is compatible with legacy code if the only adaptation required is to rename identifiers that collides with new keywords. There is no excuse for producing such a crap.

The issue always confuses me. The committee puts in a lot of effort to avoid introducing new keywords or repurposing obsolete keywords. This introduces some horribly overloaded keywords and awful syntax. Of course, new keywords break old code but what is so difficult about a grep-replace on your code base? The only reason I can come up with are the few corner cases where turning an identifier into a keyword can produce well-formed code with a different meaning but I have a hard time imagining such a thing. Can someone shed some light on this?

Re: ISO C is increasingly moronic

#85

Post by comex »

phkamp wrote: post #17
ajross wrote: post #9

Doesn't seem like the author really thought some of this through: FTA: " The file according to the standard shall have exactly this content: "#define noreturn _Noreturn" Are you crying or laughing yet ? " It's a compatibility constraint. They can't simply add new reserved words to the language because it will break preexisting code (c.f. all the old C headers with idenfiers like "bool" or "class" or "virtual" that do…

First of all: You're wrong, the compatibility is the other way around: The old code will have to include if they used the "noreturn" compiler-specific keyword, while waiting for the glacial ISO WG progress. Second: There are two kinds of compatibility: Forwards compatbility and backwards compatibilty. There is a finite number of existing programs whereas the number of future programs to be written is unbounded and ve…

> The old code will have to include if they used the "noreturn" compiler-specific keyword, while waiting for the glacial ISO WG progress.

Huh? stdnoreturn.h only makes sense with the new _Noreturn keyword. The old code can keep using __attribute__((noreturn)) or (if it was portable code) nothing at all, without including any headers.

> Crap like is just pointless ornamentation, cluttering our source code.

I think C's "add seemingly randomly named include files to the top of your code to use different parts of the standard library" is pointless, and I'd like to see the whole standard library included by default (using some yet-to-be-invented more flexible PCH magic to ensure it doesn't slow down compilation). But in lieu of that, it's hardly a big jump from library to syntax - and if keeping backward compatibility isn't hard, why not do it?

Re: ISO C is increasingly moronic

#86

Post by wmobit »

kenjackson wrote: post #29
pantaloons wrote: post #8

Earlier quoted context omitted.

Do you mind elaborating on the supposed political quibbles that would prevent a pthreads-like API from being adopted? Are you are implying that vendors of competing API's would oppose anything pthread-like making its way into the standard?

If you read the minutes they borrow generously from PThreads. But I can imagine some major vendors, like Microsoft, may say, "We have a threading library where PThreads conflicts with how we do threading. Rather than just taking PThreads as a whole, lets look at these issues and come up with a solution that will work reasonably for everyone." Otherwise you end up with C1x coming out and MS just saying, "This is broke…

As if MS will implement C1X. They haven't caught up to the last C standard from 12 years ago

Re: ISO C is increasingly moronic

#87

Post by tkahn6 »

comex wrote: post #13

I don't see this as particularly monstrous - it's reasonably succinct, and in this case a macro implementation does the job just as well as a built-in linked list would, and with much more flexibility. #define VTAILQ_INSERT_BEFORE(listelm, elm, field) do { \ (elm)->field.vtqe_prev = (listelm)->field.vtqe_prev; \ VTAILQ_NEXT((elm), field) = (listelm); \ *(listelm)->field.vtqe_prev = (elm); \ (listelm)->field.vtqe_prev…

Can anyone explain why this needs to be a macro? What does this get you over a plain function?

Re: ISO C is increasingly moronic

#88

Post by scott_s »

pmr_ wrote: post #84
reacweb wrote: post #47

Earlier quoted context omitted.

Think about C++: not only legacy C++ was broken by each standard, it was also broken by each compiler releases. The change of compiler release was always a journey. It is normal that introduction of a new keyword breaks legacy C. A new standard is compatible with legacy code if the only adaptation required is to rename identifiers that collides with new keywords. There is no excuse for producing such a crap.

The issue always confuses me. The committee puts in a lot of effort to avoid introducing new keywords or repurposing obsolete keywords. This introduces some horribly overloaded keywords and awful syntax. Of course, new keywords break old code but what is so difficult about a grep-replace on your code base? The only reason I can come up with are the few corner cases where turning an identifier into a keyword can produ…

Pain now, or pain later? Most choose to put off the pain.

Python 3 chose pain now - and I think they made the correct choice - but three years later, people are still upset and many, many Python libraries have not made the transition.

Re: ISO C is increasingly moronic

#89

Post by caf »

to3m wrote: post #82
phkamp wrote: post #62

Earlier quoted context omitted.

You overlook the %z printf specifier which attempts, but not quite solves the problem, because size_t comes in both a signed (ssize_t) and unsigned (size_t) variant. I usually end up doing printf("%j", (intmax_t)foo);

Won't "%zu" vs "%zd" do the trick? `z' is a modifier, like `l'. (That said, I've only ever used %zu myself... don't think I've ever used ssize_t. I'm pretty sure it's non-ISO.)

It does (other variants like `%zx` are also fine).

Re: ISO C is increasingly moronic

#90

Post by mbell »

jshen wrote: post #55
derobert wrote: post #48

Earlier quoted context omitted.

Amendments 1–10 and 27 were products of the same Philadelphia Convention that produced the US Constitution, and were proposed along with it. You could try Wikipedia: http://en.wikipedia.org/wiki/United_States_Bill_of_Rights#Ph...

Nothing you said negates his argument. Why didn't the committee ad them to the constitution itself when it was passed?

They didn't agree about the inclusion of the articles and they wanted to get the constitution signed and proposed to the states for ratification ASAP. Thus those that wanted to get the Bill of Rights in there were promised "it would be coming soon" which appeased them enough to "sign off " on the constitution and those that had some issue with the articles were happy that they weren't initially included. Keep in mind that the "Bill of Rights" originally had 12 articles, only 10 passed initially, 1 finally passed in 1992 and 1 is still outstanding.

Also consider that they Philadelphia Convention wasn't some magical aw-inspiring meeting of the minds as it is sometimes made out to be. Only 39 of 55 actually actually signed the constitution and several were so pissed off they just walked out. I'm sure lots of bargaining and negotiation was done and the 12 articles in the Bill of Rights was simply one of the bargaining chips.

Post reply on HN