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

141–150 of 181 posts

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

#141

Post by krylon »

pjmlp wrote: post #129
krylon wrote: post #98

Earlier quoted context omitted.

The key phrase here is " if you can avoid it". When your target platform is an 8-bit microcontroller or an embedded system with hard real-time requirements, your options are very limited. But there are plenty of situations where there are alternatives, and often these allow you to solve your problem in less time, with much lower risk of bugs than in C. As always in life, one has to evaluate one's options, consider th…

> When your target platform is an 8-bit microcontroller or an embedded system with hard real-time requirements, your options are very limited. You mean like the CPUs supported by MikroElektronika's Pascal and Basic compilers? http://www.mikroe.com/8051/ http://www.mikroe.com/pic/ http://www.mikroe.com/avr/

I get your point. However, I did not say there were no alternatives, just that they were "very limited" (when compared to, say, Debian running on amd64).

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

#142

Post by xcgvgh »

cataphract wrote: post #134
xcgvgh wrote: post #71

Earlier quoted context omitted.

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.

Right. Implementation defined, not undefined. Still not great for portable code, which is what the article is all about.

It's also very dangerous.

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

#143

Post by lmm »

snakeanus wrote: post #138
lmm wrote: post #57

> int in particular is going to be the most "natural" integer type for the current platform. If you want signed integers that are reasonably fast and are at least 16 bits, there's nothing wrong with using int The slight performance gain on a few systems that you get from using int rather than int16_t is very rarely worth the hugely increased risk of introducing platform-specific undefined behaviour, IMO. > float and…

>The slight performance gain on a few systems that you get from using int rather than int16_t int16_t is also unportable as he mentions later >the hugely increased risk of introducing platform-specific undefined behaviour What risk? Please explain how int introduces undefined behaviour. >how much performance It's not about performance. intN_t is NOT guaranteed to exist. >But you just said in the previous section that…

> int16_t is also unportable as he mentions later

It's theoretically unportable. I have yet to see a real system to which it's unportable.

> What risk? Please explain how int introduces undefined behaviour.

(Signed) integer overflow is undefined behaviour. It is very common to develop on platforms on which int is 32 or 64-bits. This carries a high risk of accidentally overflowing the limits of a 16-bit integer and not realizing. When you do this you don't notice anything (because it doesn't show up on your development machines), but you've introduced undefined behaviour that can easily manifest in practice on machines with 16-bit int.

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

#144

Post by woodman »

fithisux wrote: post #105

The discussion usually boils down to a. We need a better C b. We need better programmers. Personally I believe C tries to hard to be high level instead of what it really is. Newer revisions should try to make it lower level. For example I never could understand why we need enums. Enums are very useful for Java or Golang which are high-level. C never needs enums. Why should I ever put const in the argument of a functi…

> For example I never could understand why we need enums.

> Why should I ever put const in the argument of a function?

Reducing potential state and conveying programmer intent. Both lead to safer and more performant code (by way of compiler optimizations).

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

#145

Post by lmm »

rc4algorithm wrote: post #130
DrJokepu wrote: post #85

Earlier quoted context omitted.

I mean, reading zeroed out memory is not really incorrect behaviour anyway. If you know that it was zeroed out, then you're really just reading memory that was initialised with a specific default value. That being said, zeroing out everything you allocate will make it difficult for the kernel's paging system to defer allocating you a physical page until you actually need it, so you will need to be a lot more careful…

Unless the zeroing is defined by the language, assuming it t is incorrect and shouldn't be done.

Calloc is defined to return memory that's all-bits-zero, which in turn defines the value for many datatypes. The overwhelming majority of C implementations additionally define the values of all-bits-zero floats and pointers. IMO it's reasonable to write programs targeting only such implementations, provided such a dependency is clearly documented (just as e.g. it's reasonable to write C programs targeting only implementations on which floating-point arithmetic is IEEE 754, despite this not being required by the C standard).

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

#146

Post by lmm »

snakeanus wrote: post #137
lultimouomo wrote: post #102

Earlier quoted context omitted.

> I would argue that any code doing anything under the assumption that a char variable occupies 8 bits in memory and that the next char in an array is physically adjacent to it with no wasted space in between is just poorly-written and inherently not portable I don't think that's fair at all. It's well written and perfectly portable, under that assumption . If that assumption happens to hold for all the systems that…

ehmmmm standard C has floats and doubles. so they are valid C >Why assuming that unsigned integers overflow to 0 is fair because the standard says so In your other posts I noticed some more misunderstanding of the C standard, so I suggest not to talk about things you are not aware about.

> ehmmmm standard C has floats and doubles. so they are valid C

Sure, but the standard says hardly anything about their behaviour, making it practically impossible to write code that actually does anything with floats and doubles that will behave correctly on any standards-compliant C implementation.

I suggest you refrain from personal attacks, especially based on your own misreadings of the comment you're replying to.

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

#147

Post by lmm »

ue_ wrote: post #38
pcwalton wrote: post #29

Earlier quoted context omitted.

As a matter of fact, GCC extensions are de facto standards at this point. Clang had to copy most of them. Same with bytes not being 8 bits. Nobody will ever make a system where that's not the case anymore. You'd break de facto compatibility with almost all C code for no reason. Market realities trump making systems "for fun".

>You'd break de facto compatibility with almost all C code for no reason. The authors of that code should have written portable code if they didn't want it to break.

If a few people write unportable code in your language, they're bad programmers. But if everyone writes unportable code in your language, it's a bad language.

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

#148

Post by efaref »

rc4algorithm wrote: post #132
avian wrote: post #5

> Zeroing memory often means that buggy code will have consistent behavior; by definition it will not have correct behavior. And consistently incorrect behavior can be more difficult to track down. I agree that using calloc should not be an excuse for writing sloppy initialization code. But in my experience, inconsistently incorrect behaviour (e.g. heisenbugs that tend to appear and disappear depending on the content…

All of that useless zeroing is very painful from a performance perspective. It just isn't a reasonable option in performance-relevant code like kernels and core infrastructure. The Moore's Law argument doesn't apply because memory bus latencies and case pressure are lasting problems.

On high-performance code for an embedded PPC system I used to work on, we made all our control block a multiple of the L1 cache width. Our allocation routines then all had inline assembler to run the dcbz instruction (data cache block zero) on all the cache blocks for the control block as it was allocated. This meant the control block was always zeroed, and the memory bus wasn't touched in order to do so. Yes, things were evicted from the cache, but since we're about to start writing things into the control block, the lack of fetch was a net gain.

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

#149

Post by rc4algorithm »

lmm wrote: post #145
rc4algorithm wrote: post #130

Earlier quoted context omitted.

Unless the zeroing is defined by the language, assuming it t is incorrect and shouldn't be done.

Calloc is defined to return memory that's all-bits-zero, which in turn defines the value for many datatypes. The overwhelming majority of C implementations additionally define the values of all-bits-zero floats and pointers. IMO it's reasonable to write programs targeting only such implementations, provided such a dependency is clearly documented (just as e.g. it's reasonable to write C programs targeting only implem…

> The overwhelming majority of C implementations additionally define the values of all-bits-zero floats and pointers.

So... Clang and GCC?

Regardless, you're ignoring the obvious difference: that isn't POSIX- or ISO-defined at all. If you choose to use it, you're using a weird dialect. Might as well just switch to Cyclone.

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

#150

Post by lmm »

rc4algorithm wrote: post #149
lmm wrote: post #145

Earlier quoted context omitted.

Calloc is defined to return memory that's all-bits-zero, which in turn defines the value for many datatypes. The overwhelming majority of C implementations additionally define the values of all-bits-zero floats and pointers. IMO it's reasonable to write programs targeting only such implementations, provided such a dependency is clearly documented (just as e.g. it's reasonable to write C programs targeting only implem…

> The overwhelming majority of C implementations additionally define the values of all-bits-zero floats and pointers. So... Clang and GCC? Regardless, you're ignoring the obvious difference: that isn't POSIX- or ISO-defined at all. If you choose to use it, you're using a weird dialect. Might as well just switch to Cyclone.

> that isn't POSIX- or ISO-defined at all. If you choose to use it, you're using a weird dialect.

People used C (even on multiple compilers) long before POSIX or ISO. You're putting the standardization cart before the compatibility horse.

Post reply on HN