Live data from Hacker News

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

cl.cam.ac.uk

1–10 of 39 posts

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

#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 them.)

(and 14 other questions)

Webpage of the project: http://www.cl.cam.ac.uk/~pes20/cerberus/

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

#3
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…

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 question without resolving the ambiguities, that answers some other questions.

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

#5
post #3
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…

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 about obsolete or obscure hardware or compilers. We focussed on the behaviour of memory and pointers. This is a step towards an unambiguous and mathematically precise definition of the de facto standards: the C dialects that are actually used by systems programmers and implemented by mainstream compilers."

Here is an actual example of a comment to this question:

    I would expect this code to work:
    
    struct foo
    {
        char a;
        double b;
    };
    
    foo p;
    foo q;
    memset( &p, 0, sizeof( p ) );
    memset( &q, 0, sizeof( q ) );
    p.a = 1;
    q.a = 1;
    assert( memcmp( &p, &q, sizeof( foo ) ) == 0 );

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

#6
post #4

To write portable code, I wouldn't study de-facto definitions of de-jure undefined behavior, except to see if I could cover every possible one and only if all alternatives were inferior.

Indeed not, but enquiring into what the in-the-wild de-facto beliefs about behaviour are might help in deciding what the de-jure rules should be changed to, or what a compiler implementation ought to do if it cares about what it does on the vast mass of code out there that does commit undefined behaviour, wittingly or otherwise...

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

#7
post #5
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…

Indeed. The long version is at [pdf] http://www.cl.cam.ac.uk/~pes20/cerberus/notes30-full.pdf; it has 85 questions supported by concrete code examples and experimental data, e.g. (one of several questions that refine the above):

Q64. After an explicit write of zero to a padding

byte followed by a write to adjacent members of

the structure, does the padding byte hold a

well-defined zero value? (not an unspecified

value)

  #include 

  #include 

  typedef struct { char c; float f; int i; } st;

  int main() {

    // check there is a padding byte between c and f

    size_t offset_padding = offsetof(st,c)+sizeof(char);

    if (offsetof(st,f)>offset_padding) {

        st s; 

        unsigned char *p = 

          ((unsigned char*)(&s)) + offset_padding;

        *p = 0;

        s.c = 'A';

        s.f = 1.0;

        s.i = 42;

        unsigned char c3 = *p; 

        // does c3 hold 0, not an unspecified value?

        printf("c3=0x%x\n",c3);

    }

    return 0;

  }
Some of the questions have clear answers with respect to either the ISO or de facto standards, but many do not - that's the point.

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

#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 a slightly contrarian view these days, but there is an awful lot of unjustified C-bashing around currently).

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

#9

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?

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

#10

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.
Post reply on HN