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

A critique of "How to C in 2016"

github.com

Post reply on HN
Print view View original

71–80 of 181 posts

Re: A critique of "How to C in 2016"

#71

Post by xcgvgh »

cataphract wrote: post #67

Isn't another problem of "ptrdiff_t diff = (uintptr_t)ptrOld - (uintptr_t)ptrNew;" that you're assigning an unsigned value to a signed variable? If ptrNew is larger than ptrOld this can give a very large value via wrapping around, so large that it will probably be bigger than the max value of ptrdiff_t, making the assignment a form of signed overflow.

The assignment is a conversion from unsigned to signed, if the value cannot be represented by the signed type, the result is implementation defined or an implementation defined signal is triggered.

Re: A critique of "How to C in 2016"

#72

Post by zodiac »

cesarb wrote: post #52

> Converting to uintprt_t will give you some result -- but that result won't be useful. Unless you're writing low-level system code, don't do any pointer comparison or arithmetic unless both pointers point into or just past the end of the same object. I disagree. There are situations where you need an ordering between unrelated objects, but the precise order doesn't matter, only that it's consistent. An example is wh…

I think comparing (using <) pointers to unrelated objects is undefined behavior. So you do not get a consistent ordering.

Re: A critique of "How to C in 2016"

#73

Post by dietrichepp »

logicallee wrote: post #65
dietrichepp wrote: post #41

Earlier quoted context omitted.

This comment only fans the flames of language war, it doesn't contribute to the discussion.

This is simply not true. The barrier to a NEW person starting to write C code in 2016 - imagine some 20 year old college student - is "Am I ready to pick a denomination and religion and read hundreds to thousands of pages of gospel?" There is no such barrier with any other language. You literally cannot give any examples of correct C code as a solution to a problem: literally, experts will disagree with you. I've had…

This is exactly my point. You're basically telling me that C is a horrible language. Why? Do you think I disagree with you? Do you think that you're giving me new information? Or are you just doing your part in the language war, perhaps repeating talking points that we're frankly a bit tired of? There are better things we could be talking about.

Re: A critique of "How to C in 2016"

#74

Post by dietrichepp »

golergka wrote: post #68
dietrichepp wrote: post #41

Earlier quoted context omitted.

This comment only fans the flames of language war, it doesn't contribute to the discussion.

What? This comment is directly related to whether advice "don't use C if you can avoid it" is good or not.

And arguing that point is just the language war, nothing more, nothing less. I'd get as much mileage telling people that they shouldn't use Emacs unless they have to.

Re: A critique of "How to C in 2016"

#75

Post by xcgvgh »

Anilm3 wrote: post #32

One of the most important reasons to use calloc, other than the zeroing of the allocated memory, is the fact that it checks for integer overflows (at least on most implementations). For example, when allocating an array of n elements, in malloc you would do something like the following: ptr = malloc(sizeof(int) * n); Which could potentially lead to an overflow of the size passed to malloc, hence allocating a signific…

Using calloc instead of malloc, just for checking arithmetic overflow, is superfluous. You can always write a check or a wrapper for malloc that does that automatically. It is so easy I can write it here:

  _Bool Check( const size_t a , const size_t b )
  {
    if( a > SIZE_MAX / b )
    {
       return false;
    }
    return true;  
  }
(If proper warnings are enabled, it also provides extra integer type checking.)

Re: A critique of "How to C in 2016"

#76

Post by stupidcar »

EliRivers wrote: post #45
stupidcar wrote: post #31

Earlier quoted context omitted.

Again, if people can't agree what type to use for integers, then it's not "simple". And yes, a tool being easy to misuse absolutely means we shouldn't use it unless we have to. A competent adult would never use a chainsaw or a scalpel except for tasks where nothing else would work.

Pick the integer type that is best suited for your use, given your circumstances. I can't make it any simpler. There is no one true magical perfect solution for all circumstances in all places at all times. This is why I employ competent programmers; to make these choices. A competent adult would never use a chainsaw or a scalpel except for tasks where nothing else would work. Of course they would. I do, frequently;…

Look, nobody cares how clever and talented a programmer you are, or think you are. Please just drop the unsubtle boasting and passive aggressive insults, they only make you sound like an insecure egotist. Concentrate on the actual issue.

In 99.9% of languages, there is one true magical perfect solution to a question as basic as "what type should I use for integers?", and it's "use the integer type". The fact that C not only has options in this case, but that experienced developers seemingly cannot even agree on best practices, is a very good reason to avoid using the language unless you have to.

Re: A critique of "How to C in 2016"

#77

Post by f00fc0d3 »

hamiltonkibbe wrote: post #66
nabla9 wrote: post #28

Earlier quoted context omitted.

Just one counterexample: Texas instrument C28x core is 16-bit addressable. Each byte is 16 bits. >The TMS320C28x byte is 16 Bits. By ANSI/ISO C definition, the sizeof operator yields the number of bytes required to store an object. ANSI/ISO further stipulates that when sizeof is applied to char, the result is 1. Since the TMS320C28x char is 16 bits (to make it separately addressable), a byte is also 16 bits. http://p…

Every TI DSP I've worked with uses 16-bit bytes

c6x has 8-bit bytes.

Re: A critique of "How to C in 2016"

#78

Post by ketzu »

EliRivers wrote: post #21
stupidcar wrote: post #15

Ironic that he begins by taking issue with the idea that you should avoid writing C if you can, then proceeds to provide the best evidence possible for why it's true. Why on Earth would you voluntarily code in a language where people can debate something as simple as which type to use for integers, unless you absolutely had to?

Because it's simple and low-overhead and compilers for it exist on every lump of hardware I've ever had to work with, from a clunky x64 to a PIC to a TigerSHARC to a bizarre DSP thingy from a tiny fab lab somewhere. A great many of the problems that people experience with C code can actually be nullified (zing!) by finding a competent C programmer who does the job properly. A tool being easy to misuse doesn't mean we…

I think what the discussion about this statement misses is the "unless you need to" part. There are cases where you should use C! It is not "never ever use C".

If the use-case is being able to run on everything from TigerSHARC to x64, you probably should use C. If you want a GUI based Windows App or a webapplication, that might not be a "you need to use C" case.

Re: A critique of "How to C in 2016"

#79

Post by pjmlp »

dietrichepp wrote: post #47
pjmlp wrote: post #37

Earlier quoted context omitted.

I fail to see how C is more portable than any other memory safe systems programming language, other than having the fortune that for 30 years OS and hardware vendors decided to only support C compilers.

But that's the most important thing, isn't it? Being able to compile and run your code? I mean, the English language sure isn't popular for its intrinsic merits either, but here we are.

Sure, but in a way C is the JavaScript of systems programming languages, in a deep need of a "The Good Parts" book as well.

Re: A critique of "How to C in 2016"

#80

Post by anon1385 »

EliRivers wrote: post #63
anon1385 wrote: post #55

Earlier quoted context omitted.

>Pick the integer type that is best suited for your use, given your circumstances. >Pick the fission reactor type that is best suited for your use, given your circumstances.

I cannot tell if you are in favour of, or against, the principle that one should pick the right tool for the job.

Saying "just pick the right tool" is a worthless statement when the question is the difficulty of doing that. Would you enter a discussion about curing cancer or depression and announce "just pick the right cure for the disease" and then get upset when people don't agree with you?
Post reply on HN