5 ms·

It may be the right thing for the moment, but what happens to that code when new versions of the compiler come out? Someday it'll start leaking information agai

by tlb 8y ago

It may be the right thing for the moment, but what happens to that code when new versions of the compiler come out? Someday it'll start leaking information again. Relying on non-standard behavior always ends in tears.

8_hours_ago 8y ago
Presumably the compiler team wrote a test for that behavior so there won’t be a regression. I assume that Windows isn’t planning on switching compilers, so they can rely on that behavior as long as the Microsoft compiler passes all its tests.
EpicEng 8y ago
>Relying on non-standard behavior always ends in tears. Who's relying on unspecified behavior? Do you mean some theoretical programmer? Well of course that's not a good thing, but I don't see what it has to do with the situation in the story and the MS engineers decideing to change how they implement that unspecified part of the spec.
- tlb 8y ago
  The kernel programmer did, in this story. An example of such an information leak is: struct foo { int a; char b; } void send_foo_01() { foo x {0, 1}; write(fd, &x, sizeof(foo)); } which sends 3 bytes of the contents of the stack memory over the network, for almost every compiler except the one in the story. Running in a kernel, that could contain secrets.
  - EpicEng 8y ago
    Sorry, my mistake; yes, the kernel dev is now relying on the compiler to zero out those three bytes. I understand the decision to change this in the compiler, but I think the "fix" would have been to memset in the kernel code. I'd be surprised if they didn't do that, but maybe they can reasonably assume they'll never use another compiler to build the Windows kernel.
- legulere 8y ago
  Signed integer overflow. It’s undefined because some platforms don’t use two’s complement. Checking it after the fact is non-portable.
  - JoeAltmaier 8y ago
    Isn't that mostly theoretical? I can't seem to find any processor that doesn't use 2's complement.
    - gh02t 8y ago
      There are some old architectures that used one's complemeny and there are probably some still in service e.g. https://en.m.wikipedia.org/wiki/UNIVAC_1100/2200_series https://en.m.wikipedia.org/wiki/UNIVAC_1100/2200_series
      - JoeAltmaier 8y ago
        Is anybody writing code for them? Probably not porting modern C anyway. I assert this 'it might not be two's-complement' excuse is nonsense.
        gh02t 8y ago
        I seriously doubt it. I do agree with you, it's not a big deal for most devs. The only place I'd worry about it is systems where it might be expected to be in service for many years or intended to be ported frequently. In that case, you never know what sort of crazy architecture you may end up with in the future. There's always something a bit icky with not sticking to the spec, but in the grand scheme of things relying on two's complement is not a big deal.
        rurban 8y ago
        from the proposal http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm "Nowadays Unisys emulates their old architecture using x86 CPUs with attached FPGAs for customers who have legacy applications which they’ve been unable to migrate. These applications are unlikely to be well served by modern C++, signed integers are the least of their problem. Post-modern C++ should focus on serving its existing users well, and incoming users should be blissfully unaware of integer esoterica."

by tlb 8y ago

8_hours_ago 8y ago

Presumably the compiler team wrote a test for that behavior so there won’t be a regression. I assume that Windows isn’t planning on switching compilers, so they can rely on that behavior as long as the Microsoft compiler passes all its tests.

EpicEng 8y ago

>Relying on non-standard behavior always ends in tears. Who's relying on unspecified behavior? Do you mean some theoretical programmer? Well of course that's not a good thing, but I don't see what it has to do with the situation in the story and the MS engineers decideing to change how they implement that unspecified part of the spec.

tlb 8y ago
The kernel programmer did, in this story. An example of such an information leak is: struct foo { int a; char b; } void send_foo_01() { foo x {0, 1}; write(fd, &x, sizeof(foo)); } which sends 3 bytes of the contents of the stack memory over the network, for almost every compiler except the one in the story. Running in a kernel, that could contain secrets.
- EpicEng 8y ago
  Sorry, my mistake; yes, the kernel dev is now relying on the compiler to zero out those three bytes. I understand the decision to change this in the compiler, but I think the "fix" would have been to memset in the kernel code. I'd be surprised if they didn't do that, but maybe they can reasonably assume they'll never use another compiler to build the Windows kernel.
legulere 8y ago
Signed integer overflow. It’s undefined because some platforms don’t use two’s complement. Checking it after the fact is non-portable.
- JoeAltmaier 8y ago
  Isn't that mostly theoretical? I can't seem to find any processor that doesn't use 2's complement.
  - gh02t 8y ago
    There are some old architectures that used one's complemeny and there are probably some still in service e.g. https://en.m.wikipedia.org/wiki/UNIVAC_1100/2200_series https://en.m.wikipedia.org/wiki/UNIVAC_1100/2200_series
    - JoeAltmaier 8y ago
      Is anybody writing code for them? Probably not porting modern C anyway. I assert this 'it might not be two's-complement' excuse is nonsense.
      - gh02t 8y ago
        I seriously doubt it. I do agree with you, it's not a big deal for most devs. The only place I'd worry about it is systems where it might be expected to be in service for many years or intended to be ported frequently. In that case, you never know what sort of crazy architecture you may end up with in the future. There's always something a bit icky with not sticking to the spec, but in the grand scheme of things relying on two's complement is not a big deal.
        rurban 8y ago
        from the proposal http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm "Nowadays Unisys emulates their old architecture using x86 CPUs with attached FPGAs for customers who have legacy applications which they’ve been unable to migrate. These applications are unlikely to be well served by modern C++, signed integers are the least of their problem. Post-modern C++ should focus on serving its existing users well, and incoming users should be blissfully unaware of integer esoterica."