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

21–30 of 175 posts

Re: ISO C is increasingly moronic

#21

Post by forgotusername »

phkamp wrote: post #6
forgotusername wrote: post #2

Ignoring complaints about the introduction of a new style of _Identifier, the rant about pthreads seems myopic or just plain wrong. For a start as a vendor-neutral spec (the C standard itself), pthreads would never be adopted as-is. It simply couldn't happen for political reasons (without knowing a thing about the internals of the working group, I'm fairly confident of that). In the meantime it is still useful to def…

This comment was filled with fail. Pthreads has been the standard for 20 years, either you do better than it does, or you are wasting everybodys time, including your own. "Too dangerous" is a direct quote from a WG14 member. Stacksize is not an implementation detail, it often is crucial resource management issue for each individual application, in particular in high performance computing and network service applicati…

With respect to stack size, I still believe it is an implementation attribute independent of the abstract machine for which C is specified. There is no reason why some undefined external vendor-specific control (e.g. some glibc function) can't be provided by implementations, where required (however as in the example I gave, implementations are possible where such a control would be meaningless - its inclusion would be myopic).

Following your argument, complex systems could not be designed without similar controls on memory allocator behaviour ("how can I allocate anything when I don't know if malloc() will introduce syscall latency for a size-32 allocation!?") or environment table size ("how can I possibly execute a subprocess if I can't be certain setenv() will always succeed!?").

The answer to both of course is that you don't design for the standard, you design (and measure) for a particular closed system. I can't see why stack size is any different from the two (of many) examples above.

Re: absolute timeouts, the impossibility of emulating intervals reliably with wall-clock is a very good point.

Re: ISO C is increasingly moronic

#22

Post by phkamp »

scott_s wrote: post #16

I find this author's characterization of the history of C inaccurate. At the time, C was innovative. And its existence did enable computer science research, because with C, operating systems were finally portable. C itself was a worthwhile contribution to computer science research. Kernighan and Ritchie built upon prior languages, but they were able to distil what levels and kinds of abstraction were needed to implem…

You are rationalizing: C was not "novel", it was pretty much BCPL-light. There also were portable operating systems before UNIX, some of them were written in PL/1 and FORTRAN.

Re: ISO C is increasingly moronic

#23

Post by aliguori »

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…

There are many things horrible about it. Its arguments are evaluated many times which is different than what you would expect. The fact that you have to pass field is just plain clumsy.

C could benefit tremendously from a parameterized type mechanism.

Re: ISO C is increasingly moronic

#24

Post by scott_s »

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…

If you don't value backwards compatibility, then perhaps you should not use a 40-year-old language with a standards committee that does value it.

Re: ISO C is increasingly moronic

#25

Post by aliguori »

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…

I don't agree with your assertion that backwards compatibility isn't important, but I would like to point out that the very fact that C compilers allow you to use identifiers that are in the form _Word means that they are breaking backwards compatibility by introducing new keywords.

Many of the libraries on a typical Linux system (anything glib/gtk based, libxml2, etc.) use _Word extensively.

Re: ISO C is increasingly moronic

#26

Post by angersock »

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…

Therefore forwards compatibility is always, by definition, more important than backwards compatibility, and you should never penalize future programs and programmers for the misdeeds and sloppines of the past programs and programmers.

Ha. You're adorable.

While I do support the general "hey, let's fix old code and not be slaves to backwards compatibility", the fact of the matter is that legacy code / libraries / whatever in C aren't merely misdeeds/sloppiness--you might as well complain about having to use the same molecules of metal in your tools that our ancestors did building Rome instead of making your own from subatomic particles.

There is a finite number of existing programs whereas the number of future programs to be written is unbounded and very likely to be much higher over time.

But in the future, it's all Javascript/Ruby/CSS/HTML5! Why worry about writing more C code? ;)

Re: ISO C is increasingly moronic

#27

Post by latitude »

Taking bets on when ISO C will acquire a form of templates, or taking it in even more generic direction - parametrized namespaces. Something like this (an illustrative example, don't knock me down for including val into list):

  namespace(T)
  {
    struct list
    {
       T      val;
       list * next;
       list * prev;
    };

    void append(list * l, list * i)
    {
      ...
    }
  }
Then

  list * foo, * bar;
  ...
  append(foo, bar);
No need for namespace nesting, default arguments and other ++isms. Just something to replace multi-line macro blocks.

Re: ISO C is increasingly moronic

#28

Post by phkamp »

forgotusername wrote: post #21
phkamp wrote: post #6

Earlier quoted context omitted.

This comment was filled with fail. Pthreads has been the standard for 20 years, either you do better than it does, or you are wasting everybodys time, including your own. "Too dangerous" is a direct quote from a WG14 member. Stacksize is not an implementation detail, it often is crucial resource management issue for each individual application, in particular in high performance computing and network service applicati…

With respect to stack size, I still believe it is an implementation attribute independent of the abstract machine for which C is specified. There is no reason why some undefined external vendor-specific control (e.g. some glibc function) can't be provided by implementations, where required (however as in the example I gave, implementations are possible where such a control would be meaningless - its inclusion would b…

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.

Third: You cannot add "some glibc function" to set the stack-size of a thread you have not yet created, and setting it afterwards may be impossible (if you want it larger) or cause memory fragmentation (if you want it smaller).

Fourth: What does malloc(3) have to do with thread stacks ??

Re: ISO C is increasingly moronic

#29

Post by kenjackson »

pantaloons wrote: post #8
forgotusername wrote: post #2

Ignoring complaints about the introduction of a new style of _Identifier, the rant about pthreads seems myopic or just plain wrong. For a start as a vendor-neutral spec (the C standard itself), pthreads would never be adopted as-is. It simply couldn't happen for political reasons (without knowing a thing about the internals of the working group, I'm fairly confident of that). In the meantime it is still useful to def…

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 broken for Windows. Our compiler won't implement it." And just let gcc and Intel pick up the load. Which may be fine for some, but seems counterproductive.

Re: ISO C is increasingly moronic

#30

Post by dextorious »

angersock wrote: post #26
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…

Therefore forwards compatibility is always, by definition, more important than backwards compatibility, and you should never penalize future programs and programmers for the misdeeds and sloppines of the past programs and programmers. Ha. You're adorable. While I do support the general "hey, let's fix old code and not be slaves to backwards compatibility", the fact of the matter is that legacy code / libraries / what…

"""While I do support the general "hey, let's fix old code and not be slaves to backwards compatibility", the fact of the matter is that legacy code / libraries / whatever in C aren't merely misdeeds/sloppiness--you might as well complain about having to use the same molecules of metal in your tools that our ancestors did building Rome instead of making your own from subatomic particles.""""

Only you have to use the same molecules of metal by the laws of physics, while compilers you can IMPROVE. Heck, we even produce new metal alloys and materials all the time. So, the analogy is 100% flawed.

Post reply on HN