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

Into the Depths of C: Elaborating the De Facto Standards [pdf]

cl.cam.ac.uk

Post reply on HN
Print view View original

11–20 of 39 posts

Re: Into the Depths of C: Elaborating the De Facto Standards [pdf]

#11

Post by TickleSteve »

pkhuong wrote: post #9
TickleSteve wrote: post #8

I've been using C for over 20 years and I'm sure I would be caught out by these... ...but... The fact these curiosities are not an issue in day-to-day work and C is (one of) the most popular languages around today mean that they aren't too serious. When you have a knowledge of the hardware and are working at that level day-in day-out then issues like this really don't bother you that much. (I do realise that this is…

http://cacm.acm.org/magazines/2016/3/198849-a-differential-a... 8575 C or C++ packages in Wheezy. This tool found definite UB bugs in 40% of them. How would you know that your code is sometimes misbehaving because of UB?

not denying there are issues... just saying that C isn't the only widespread language with issues. at least C's problems are widely known.

Re: Into the Depths of C: Elaborating the De Facto Standards [pdf]

#12

Post by TickleSteve »

pcwalton wrote: post #10
TickleSteve wrote: post #8

I've been using C for over 20 years and I'm sure I would be caught out by these... ...but... The fact these curiosities are not an issue in day-to-day work and C is (one of) the most popular languages around today mean that they aren't too serious. When you have a knowledge of the hardware and are working at that level day-in day-out then issues like this really don't bother you that much. (I do realise that this is…

Undefined behavior in the form of memory safety issues is a problem in day-to-day work.

we will have to agree to disagree on that one.

Re: Into the Depths of C: Elaborating the De Facto Standards [pdf]

#13

Post by caf »

pcwalton wrote: post #10
TickleSteve wrote: post #8

I've been using C for over 20 years and I'm sure I would be caught out by these... ...but... The fact these curiosities are not an issue in day-to-day work and C is (one of) the most popular languages around today mean that they aren't too serious. When you have a knowledge of the hardware and are working at that level day-in day-out then issues like this really don't bother you that much. (I do realise that this is…

Undefined behavior in the form of memory safety issues is a problem in day-to-day work.

But that's not what this study is about: everyone agrees that stomping wildly off the end of an array in C is not going to end well.

This is about far more subtle issues than that - issues where there is some disagreement about whether it's OK to do or not. And the GP is right - these are often not such a problem in practice, if only because these are the kinds of issues where experienced C programmers know that they're sailing close to the wind, and there's almost always an alternative construct that's on more solid ground.

Re: Into the Depths of C: Elaborating the De Facto Standards [pdf]

#14

Post by D-Coder »

TickleSteve wrote: post #11
pkhuong wrote: post #9

Earlier quoted context omitted.

http://cacm.acm.org/magazines/2016/3/198849-a-differential-a... 8575 C or C++ packages in Wheezy. This tool found definite UB bugs in 40% of them. How would you know that your code is sometimes misbehaving because of UB?

not denying there are issues... just saying that C isn't the only widespread language with issues. at least C's problems are widely known.

The Potzrebie car isn't the only car with issues. At least the Potzrebie's doors-falling-off problem is widely known.

Re: Into the Depths of C: Elaborating the De Facto Standards [pdf]

#15

Post by jjnoakes »

pkhuong wrote: post #9
TickleSteve wrote: post #8

I've been using C for over 20 years and I'm sure I would be caught out by these... ...but... The fact these curiosities are not an issue in day-to-day work and C is (one of) the most popular languages around today mean that they aren't too serious. When you have a knowledge of the hardware and are working at that level day-in day-out then issues like this really don't bother you that much. (I do realise that this is…

http://cacm.acm.org/magazines/2016/3/198849-a-differential-a... 8575 C or C++ packages in Wheezy. This tool found definite UB bugs in 40% of them. How would you know that your code is sometimes misbehaving because of UB?

The linked paper claims their tool issued as least one warning on 40% of the C or C++ packages, not that they were all valid warnings indicating undefined behavior.

Re: Into the Depths of C: Elaborating the De Facto Standards [pdf]

#16

Post by EpicEng »

pkhuong wrote: post #9
TickleSteve wrote: post #8

I've been using C for over 20 years and I'm sure I would be caught out by these... ...but... The fact these curiosities are not an issue in day-to-day work and C is (one of) the most popular languages around today mean that they aren't too serious. When you have a knowledge of the hardware and are working at that level day-in day-out then issues like this really don't bother you that much. (I do realise that this is…

http://cacm.acm.org/magazines/2016/3/198849-a-differential-a... 8575 C or C++ packages in Wheezy. This tool found definite UB bugs in 40% of them. How would you know that your code is sometimes misbehaving because of UB?

A warning is not 'definite UB'

Re: Into the Depths of C: Elaborating the De Facto Standards [pdf]

#17

Post by Gibbon1 »

D-Coder wrote: post #14
TickleSteve wrote: post #11

Earlier quoted context omitted.

not denying there are issues... just saying that C isn't the only widespread language with issues. at least C's problems are widely known.

The Potzrebie car isn't the only car with issues. At least the Potzrebie's doors-falling-off problem is widely known.

If the compiler writers union decides that the spec allows for 'format hard drive off on signed overflow' we can always change the spec to 'don't format hard drive on signed overflow'

Re: Into the Depths of C: Elaborating the De Facto Standards [pdf]

#18

Post by wahern »

kerneis wrote: post #2

If you think you know C quite well, here is one of the studies the authors ran to elaborate their semantics on corner cases of the language: http://www.cl.cam.ac.uk/~pes20/cerberus/notes50-survey-discu... > If you zero all bytes of a struct and then write some of its members, do reads of the padding return zero? (e.g. for a bytewise CAS or hash of the struct, or to know that no security-relevant data has leaked into…

Here's a similar, real-world case involving GCC 6's more aggressive SRA and alias-analysis optimizations: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71120

Re: Into the Depths of C: Elaborating the De Facto Standards [pdf]

#19

Post by pcwalton »

Gibbon1 wrote: post #17
D-Coder wrote: post #14

Earlier quoted context omitted.

The Potzrebie car isn't the only car with issues. At least the Potzrebie's doors-falling-off problem is widely known.

If the compiler writers union decides that the spec allows for 'format hard drive off on signed overflow' we can always change the spec to 'don't format hard drive on signed overflow'

It's not that simple. The compiler writers have caused security issues before in the Linux kernel. And the compiler writers are right: the undefined behavior that they exploit exists for important performance-related reasons.

Re: Into the Depths of C: Elaborating the De Facto Standards [pdf]

#20

Post by Too »

kerneis wrote: post #5
blastrat wrote: post #3

Earlier quoted context omitted.

I knew C quite well. Haven't written any for years. The statements "zero all bytes of a struct" and "reads of the padding" contain enough ambiguity that it answers the question. Not to mention the ambiguity in the words "read" and "write" as they pertain to C, since they already have a "std" meaning that's not the same as lvalue or rvalue, so what exactly do they mean here? And if you think you can answer the questio…

I believe the questions in this study (I did not write it, only know the authors) were deliberately open-ended, allowing for comments on the specifics. A previous, much longer version used to contain code examples to comment, but it proved too detailed for people to complete. Moreover, the study was explicitly not about ISO C: "We were not asking what the ISO C standard permits, which is often more restrictive, or ab…

Is memset and memcmp compatible with strict aliasing? Intuitively it seems like that would be a gap into the aliasing rules. Altough void* is allowed to alias anything so maybe it works through that. Ive never seen memset, memcpy or memcmp on anything but char* in production code.
Post reply on HN