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

131–140 of 175 posts

Re: ISO C is increasingly moronic

#131

Post by gsg »

aliguori wrote: post #110
plq wrote: post #75

Earlier quoted context omitted.

> Reserving a namespace and not having a mechanism to enforce it was a massive fail on the part of the standards committee. How do you expect the compiler to enforce the "identifiers that begin with two underscores are reserved for use by the implementation" rule? Some things just belong in the documentation.

If the goal is to allow the introduction of new keywords, then it's fairly simple. Don't parse anything in the form __[a-z0-9$_] as anything but a keyword. Problem solved. Instead, they did something awkward by trying to carve out namespaces for the stdlib too but quite frequently don't adhere to their own rules.

The goal is not just to allow for new keywords. Reserved identifiers are also intended to be used in system headers to protect implementation code from the unfortunate effect of user defined symbols.

Go and read your /usr/include/stdio.h (or equivalent). It will be filled with such symbols. Obviously the compiler must lex them exactly as it would unreserved symbols.

This is an unfortunately legacy of C's decision to pass compilation information around by textual inclusion, and isn't really fixable at this point.

Re: ISO C is increasingly moronic

#132

Post by TheNewAndy »

aliguori wrote: post #110
plq wrote: post #75

Earlier quoted context omitted.

> Reserving a namespace and not having a mechanism to enforce it was a massive fail on the part of the standards committee. How do you expect the compiler to enforce the "identifiers that begin with two underscores are reserved for use by the implementation" rule? Some things just belong in the documentation.

If the goal is to allow the introduction of new keywords, then it's fairly simple. Don't parse anything in the form __[a-z0-9$_] as anything but a keyword. Problem solved. Instead, they did something awkward by trying to carve out namespaces for the stdlib too but quite frequently don't adhere to their own rules.

But there are lots of places where these identifiers aren't keywords, and it is valid code (try writing a compliant stdlib without using them).

The problem is that too many people assume that their usage of C is the same as everyone elses. I don't want to be writing a system library and fighting my compiler everytime I put something in the symbol table that isn't in the C spec.

Re: ISO C is increasingly moronic

#133

Post by leoc »

> Concrete has been known since antiquity, but steel-reinforced concrete and massive numerical calculations of stress-distribution, is the tools that makes the difference between using concrete as a filler material between stones, and as gravity-defying curved but perfectly safe load-bearing wall.

Ahem. http://www.google.ie/imgres?imgurl=http://romanconcrete.com/...

Re: ISO C is increasingly moronic

#134

Post by Confusion »

tedunangst wrote: post #81
teyc wrote: post #49

Earlier quoted context omitted.

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.

I don't think that's entirely fair. Sometimes who someone is, is a decisive factor in what arguments they present. It can give them a valuable jolt of insight to point out that they present those arguments because they are missing part of the view. Of course you should also explain why the arguments in themselves are wrong, but the main argument may be "you've never experienced X; those that have tend to argue Y, because of Z"

Re: ISO C is increasingly moronic

#135

Post by phkamp »

nitrogen wrote: post #117
nitrogen wrote: post #67

Earlier quoted context omitted.

Do you think a new language (Go, maybe?) will take C's place, given your distaste for ISO's handling of the standard?

Dead post from ballard: ballard 3 hours ago | link [dead] Java was an over-reaction to C. Go was a reaction to Java back to almost center. C is close to hardware, which is important for things like game engine cores, video drivers, varnish and the list of use-cases goes on and on. Finally, people tend to complain about their tools even when those tools work. Be thankful if you didn't have to write the tool yourself.…

Last time I wrote inline ASM was 2 days ago. I'm a kernel programmer, remember ?

Re: ISO C is increasingly moronic

#136

Post by alexchamberlain »

kmm wrote: post #37
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…

No, you're wrong. The old code will have something like typedef char bool And thus compiling this code in C99 would not work if bool were a keyword of the language. That is why the boolean datatype is called _Bool, so it doesn't clash with old code. In new code, you can still use the bool datatype, but instead of defining it yourself with char or int, you should better use a typedef of the _Bool datatype in stdbool.h

Your attitude is rediculous... Let code break! Make sure there is a __c1x macro and maintained projects will take 30 seconds to fix. Unmaintained projects will die, yay!

Re: ISO C is increasingly moronic

#137

Post by phkamp »

caf wrote: post #92

As noted elsewhere, the _Noreturn spelling is used precisely because such identifiers have been reserved since the first ISO C standard, so existing conforming code shouldn't use them and hence shouldn't break. However, rather than introducing to create the pretty spelling, it would perhaps have been better if the standard specified that if you define a macro like _C_SOURCE to a suitable value before including any st…

Provided you were prevented from linking objects together which were compiled with different C versions, that would be both better and safer.

The problem with ISO-C's approach is that the chances of having both "#include " and "#define bool char" in a codebase of a few million lines are almost unity, and causes bugs which are near-impossible to find, unless you happen to know the intricacies of hacks like this.

In general, optional features in a standard are a bad thing. ISO-C seems to think they are the solution to everything they cannot agree to do properly.

Re: ISO C is increasingly moronic

#138

Post by phkamp »

tptacek wrote: post #96
haberman wrote: post #91

> Now, don't get me wrong: There are lot of ways to improve the C language that would make sense: Bitmaps, defined structure packing (think: communication protocol packets), big/little endian variables (data sharing), sensible handling of linked lists etc. > As ugly as it is, even the printf()/scanf() format strings could be improved, by offering a sensible plugin mechanism, which the compiler can understand and use…

For the past 10 years or so, I've been using an alternative to printf() that I lifted out of Hanson's _C Interfaces and Implementations_; in my tree, it's "fmt.c", and includes the family of fmt_ functions. They're just string processing code, and so are trivially portable to WinAPI, OS X, Linux, and FreeBSD. This is so much of a win that I don't understand why everyone doesn't do it: * Cross-platform counted/allocat…

The reason why struct packing would be a win is probably not performance, but code readability and less bugs.

Making be/le/native conversion a job for the programmer is not only error-prone and a waste of time.

The compiler could safely optimize the byte-swizzles away on non-arithmetic operations, whereas most programmers tend to covert everything before they start working on it.

Re: ISO C is increasingly moronic

#139

Post by haberman »

tptacek wrote: post #123
haberman wrote: post #103

Earlier quoted context omitted.

> I'm going to tend to believe PHK if he thinks explicit structure packing is a win, noting at the same time how unlikely it is that any implementation of it is going to be a performance bottleneck compared with I/O. I've spent a lot of my life writing parsers for various network formats, and one thing that I can say with authority is that at both my current company (Google) and at my previous company (Amazon) the CP…

In the sense that your parsing strategy influences your I/O strategy and, in particular, may incur extra copies, I buy this. The idea that Amazon has cycle-optimized network parsing code, and that they did it for a significant practical benefit... I have no reason to doubt you, but I'd like to hear more. I've done a fair bit of high performance network code (not for Amazon or Google, but, for instance, for code watch…

> The idea that Amazon has cycle-optimized network parsing code, and that they did it for a significant practical benefit... I have no reason to doubt you, but I'd like to hear more.

I can speak better to Google, since it's my more recent experience. Google's internal data format is Protocol Buffers (and all the code is open-sourced, as you probably know). The C++ code that is generated to parse Protocol Buffers is fast (on the order of hundreds of MB/s) as a result of a lot of optimization. This has reached a rough ceiling of what I believe is possible with this approach (generated C++). Even so, Protocol Buffer parsing code shows up in company-wide CPU profiles, and certain teams in particular have performance issues where Protocol Buffer parsing is a significant concern for them.

To address these issues, I wrote a Protocol Buffer parser that improves performance in two ways:

- it is an event-based parser (like SAX) instead of the protobuf generated classes which are a more DOM-like approach (always parsing into a tree of data structures). With my parser you bind fields to callbacks, and you can parse into any data structure (or do pure stream processing).

- I wrote a JIT compiler that can translate a Protocol Buffer schema directly into x86-64 machine code that parses that schema. Without the intermediate C++ step, I can generate better machine code than the C++ compiler does. In an apples-to-apples test, I beat the generated C++ by 10-40%. If you do more pure stream parsing the win is even greater.

My protobuf work is open source: https://github.com/haberman/upb

> I'm not sure I could have won much by counting the cycles it took me to pull (say) an NBO integer out of a packet.

That's certainly different experience than mine. I don't know much about routers.

Re: ISO C is increasingly moronic

#140

Post by alexchamberlain »

Confusion wrote: post #134
tedunangst wrote: post #81

Earlier quoted context omitted.

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.

I don't think that's entirely fair. Sometimes who someone is, is a decisive factor in what arguments they present. It can give them a valuable jolt of insight to point out that they present those arguments because they are missing part of the view. Of course you should also explain why the arguments in themselves are wrong, but the main argument may be "you've never experienced X; those that have tend to argue Y, bec…

Age discrimination just makes you look like a fool.
Post reply on HN