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

61–70 of 175 posts

Re: ISO C is increasingly moronic

#61

Post by phkamp »

jacques_chester wrote: post #56

The Sydney Opera House is a good example, actually. It's an iconic building. Australia is frequently represented by a picture of the opera house in front the the harbour bridge, possibly with Uluru in the middle distance (it's just outside Sydney, apparently). There's just one problem. It's not a very good opera house . The structural requirements make it impossible to have an ochestral pit for the musicians, and the…

Funny you should say that: I've always wondered how it worked in the inside.

I'm not claiming it is a great opera house, but it is a very good example of using modern building tools.

When Utzon died, one of our (Danish) newspapers explained that the required maintenance is now necessary because the architects original plan to cap the "top-seams" with metal was judged too expensive, and some plastic-sealant ("Caulk" ?) were filled into the seam instead, and that has allowed moisture to seep into the construction. I have no idea if this is true or not.

Re: ISO C is increasingly moronic

#62

Post by phkamp »

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);

Re: ISO C is increasingly moronic

#63

Post by mikeash »

phkamp wrote: post #45
forgotusername wrote: post #44

Earlier quoted context omitted.

1) http://gcc.gnu.org/wiki/SplitStacks > This is currently implemented for 32-bit and 64-bit x86 targets running GNU/Linux in gcc 4.6.0 and later. For full functionality you must be using the gold linker, which you can get by building binutils 2.21 or later with --enable-gold. 2) You're still conflating heap and stack.

Too bad it is not part of the ABI specification on any known platform, so if you call a library function compiled without this magic compiler you're totally screwed. But an interesting research project, I'll grant you that.

There's a section in that link which details how they handle calls to libraries that aren't aware of what's going on. Sounds like it works just fine.

Re: ISO C is increasingly moronic

#64

Post by jacques_chester »

phkamp wrote: post #61
jacques_chester wrote: post #56

The Sydney Opera House is a good example, actually. It's an iconic building. Australia is frequently represented by a picture of the opera house in front the the harbour bridge, possibly with Uluru in the middle distance (it's just outside Sydney, apparently). There's just one problem. It's not a very good opera house . The structural requirements make it impossible to have an ochestral pit for the musicians, and the…

Funny you should say that: I've always wondered how it worked in the inside. I'm not claiming it is a great opera house, but it is a very good example of using modern building tools. When Utzon died, one of our (Danish) newspapers explained that the required maintenance is now necessary because the architects original plan to cap the "top-seams" with metal was judged too expensive, and some plastic-sealant ("Caulk" ?…

Basically Utzon designed it to look awesome. And it does. As a work of sculpture it's really lovely, and the engineering to make it stand up is difficult and impressive.

But as I said, Utzon and his offsiders obviously did not care about the actual purpose of the building, or whether their beautiful design would be at all practical. It's not. Even Frank Gehry, whose work I find to be obnoxious, has managed to design a semi-practical music hall.

It's not really architecture, in a Vitruvian sense. It's walk-through sculpture.

Re: ISO C is increasingly moronic

#65

Post by FooBarWidget »

forgotusername wrote: post #33
phkamp wrote: post #28

Earlier quoted context omitted.

First: Why should the API for setting stack-size be implementation defined, when a stack mandated to implement the language ? Second: You seem to labour under the misunderstanding that all threads in a program have, and should have the same stack size ? That's simply not true, you can look in Varnish for a good example: We may have 10 "overhead" threads with big stacks and 100.000 worker threads with small stacks. Th…

For the third time, the API for setting stack size should be implementation defined because there are perfectly practical implementations for which any specification would be meaningless. Another reason is that almost all prevailing contemporary environments use virtual memory, and the prevailing embedded architecture (ARM) is about to go 64 bit (the desktop/server world already has). In a world with virtual memory,…

> Another reason is that almost all prevailing contemporary environments use virtual memory, and the prevailing embedded architecture (ARM) is about to go 64 bit (the desktop/server world already has). In a world with virtual memory, paging, and even where we're 10 years away from "complex system" interconnects powerful enough to provide shared memory across 10k+ computers filling a football field, how much longer would setting the stack size have any practical meaning.

I set the stack size on my worker threads because I don't want my users looking at my process in 'ps', see a big VSIZE, and conclude that my software is bloated and memory hogging. Yes I know I can educate my users but I would rather prevent them from bothering me with these false conclusions in the first place.

Re: ISO C is increasingly moronic

#66

Post by phkamp »

teyc wrote: post #60
phkamp wrote: post #53

Earlier quoted context omitted.

You have absolutely no idea what, or rather: who, you are talking about: I'm the second most active committer to FreeBSDs kernel over the project lifetime and I'm the author of Varnish, I even have C-code running in ATC systems, heck when it comes to that: My code scrambles your password. It's exactly because I am responsible for so much old code that I say we should not cripple the future for it.

First off, I didn't realize. I'm sorry. I am responsible for so much old code that I say we should not cripple the future for it. I had to read that a few times. Are you advocating a clean break so that whatever that is future is clearly not called C or even purports to be backwards compatible with C? That would be difficult wouldn't it? It simply wouldn't get traction.

I'm not sure I have a coherent proposal. Clearly ISO-C is a cul-de-sac by now, and will have to be ditched. What we should replace it with is not clear to me.

It is a big problem that so many standards, requirements and tools (from EMACS to Coverity over lint) have their fingers in the C-syntax. The autocrap abomination is a further complication.

So I guess a good place to start is to swear that we will never touch or use the botched ISO-C thread API, and beat some sense into the WG14, by whatever means are available.

Re: ISO C is increasingly moronic

#67

Post by nitrogen »

phkamp wrote: post #53
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?)

You have absolutely no idea what, or rather: who, you are talking about: I'm the second most active committer to FreeBSDs kernel over the project lifetime and I'm the author of Varnish, I even have C-code running in ATC systems, heck when it comes to that: My code scrambles your password. It's exactly because I am responsible for so much old code that I say we should not cripple the future for it.

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

Re: ISO C is increasingly moronic

#68

Post by ajross »

chipsy wrote: post #50
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…

Maybe the ISO committee is conspiring to destroy C with mediocrity so that a shiny new systems language can take its place, correcting C's deeper warts in the process. That would be nice, if only I believed it.

Exactly. I've long since lost track of which shiny new systems language we're supposed to be using.

Re: ISO C is increasingly moronic

#69

Post by phkamp »

zb wrote: post #59
api wrote: post #10

Nothing good ever came from a committee.

Actually I think C emerged from its original ANSI standardisation process in much better shape than when it went it. You don't see too much K&R C being written these days for good reason.

You're probably right about that, ANSI did a couple of good things, but I'm not sure I think they came out in the black in the end.

ISO on the other hand, seems like a total disaster.

Re: ISO C is increasingly moronic

#70

Post by ballard »

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?)

.

  #if defined(__HAVING_A_CASE_OF_THE_MUNDAYS_ON_TUESDAY__)
  # include 
  # include "mouth.h"
  # include 
  # include 
  # include 
  # include "pick_on_zed_for_grins.h"
  # include 
  #endif
Post reply on HN