3 ms·

This is a 2^15 hours bug, not a 2^16 hours bug. Odds are, somewhere in the SSD firmware source code, there's a missing "unsigned". And in the Makefile, probably

This is a 2^15 hours bug, not a 2^16 hours bug. Odds are, somewhere in the SSD firmware source code, there's a missing "unsigned". And in the Makefile, probably a missing "-Wextra".

richthegeek 7y ago
Presumably the bug would still be considered a bug if it occured at 65536 hours? The incorrectly-signed bit only makes it appear sooner, but it's not the bug.
- pfortuny 7y ago
  Someone says below that rollover may work OK but not negative times, for whatever reasons.
  - air7 7y ago
    Oh! So in that case owners just need to wait 32,768 hours and they'll be fine. /s
- moonbug 7y ago
  That's 7.4 years, and well outside warranty.
  - eb0la 7y ago
    If you purchase a Carepaq, can actually extend the service beyond that? 3,4,and 5-Year 24x7 Carepaqs are available on purchase for the _whole_ chassis and parts... but I wonder if I can keep purchasing 1-year carepaq extensions beyond the 6th year.
    - HorstG 7y ago
      Yes, its possible. However, prices go up with age.
garaetjjte 7y ago
2^16 would be still rather too small, 65536 hours is not impossible duration.
coldpie 7y ago
> Odds are, somewhere in the SSD firmware source code, there's a missing "unsigned". And in the Makefile, probably a missing "-Wextra". Our industry really sucks. We need languages where this can't happen, and we need testing procedures where these things are caught. I wonder if software is the industry with the lowest quality:importance ratio.
rocqua 7y ago
Using signed integers for values that are always positive isn't necessarily a mistake. Most notably because for signed integers (in C and C++) overflow is undefined behavior. This allows for more aggressive optimizations by the compiler. Some advice I've read is to only use unsigned integers if you want to explicitly opt-in to having overflow be defined behavior.
- cesarb 7y ago
  > Some advice I've read is to only use unsigned integers if you want to explicitly opt-in to having overflow be defined behavior. I read somewhere that the true reason for that advice is that it allows the compiler to silently store an "int" loop counter in a 64-bit register, without having to care about 32-bit overflow. If you use size_t for the loop counter, that's no longer an issue.
  - jdsully 7y ago
    At least on X86 that truncation behavior is free. 32-bit EAX is just first 32-bits of RAX.
  - nullc 7y ago
    I haven't seen an example where that's the case. It commonly factors in loop analysis around unrolling and vectorization, e.g. the loop will run exactly 16*n times OR an integer will overflow and it'll run some other number of times. Use of signed precludes the overflow and the exact bound enables efficient vectorization.
- jschwartzi 7y ago
  Undefined behavior is platform-specific behavior. In this case it means that rollover’s effect on the value depends on how the register stores the integer and on how the particular instruction is documented to behave.
  - rocqua 7y ago
    No, undefined behavior is specified by the standard. There is also 'implementation defined' which tends to be both architecture and compiler specific. The difference is that a program which invokes 'implementation defined' behavior can be well defined, whereas a program that invokes undefined behavior is literally free to do anything.

This is a 2^15 hours bug, not a 2^16 hours bug. Odds are, somewhere in the SSD firmware source code, there's a missing "unsigned". And in the Makefile, probably a missing "-Wextra".

richthegeek 7y ago

Presumably the bug would still be considered a bug if it occured at 65536 hours? The incorrectly-signed bit only makes it appear sooner, but it's not the bug.

pfortuny 7y ago
Someone says below that rollover may work OK but not negative times, for whatever reasons.
- air7 7y ago
  Oh! So in that case owners just need to wait 32,768 hours and they'll be fine. /s
moonbug 7y ago
That's 7.4 years, and well outside warranty.
- eb0la 7y ago
  If you purchase a Carepaq, can actually extend the service beyond that? 3,4,and 5-Year 24x7 Carepaqs are available on purchase for the _whole_ chassis and parts... but I wonder if I can keep purchasing 1-year carepaq extensions beyond the 6th year.
  - HorstG 7y ago
    Yes, its possible. However, prices go up with age.

garaetjjte 7y ago

2^16 would be still rather too small, 65536 hours is not impossible duration.

coldpie 7y ago

> Odds are, somewhere in the SSD firmware source code, there's a missing "unsigned". And in the Makefile, probably a missing "-Wextra". Our industry really sucks. We need languages where this can't happen, and we need testing procedures where these things are caught. I wonder if software is the industry with the lowest quality:importance ratio.

rocqua 7y ago

Using signed integers for values that are always positive isn't necessarily a mistake. Most notably because for signed integers (in C and C++) overflow is undefined behavior. This allows for more aggressive optimizations by the compiler. Some advice I've read is to only use unsigned integers if you want to explicitly opt-in to having overflow be defined behavior.

cesarb 7y ago
> Some advice I've read is to only use unsigned integers if you want to explicitly opt-in to having overflow be defined behavior. I read somewhere that the true reason for that advice is that it allows the compiler to silently store an "int" loop counter in a 64-bit register, without having to care about 32-bit overflow. If you use size_t for the loop counter, that's no longer an issue.
- jdsully 7y ago
  At least on X86 that truncation behavior is free. 32-bit EAX is just first 32-bits of RAX.
- nullc 7y ago
  I haven't seen an example where that's the case. It commonly factors in loop analysis around unrolling and vectorization, e.g. the loop will run exactly 16*n times OR an integer will overflow and it'll run some other number of times. Use of signed precludes the overflow and the exact bound enables efficient vectorization.
jschwartzi 7y ago
Undefined behavior is platform-specific behavior. In this case it means that rollover’s effect on the value depends on how the register stores the integer and on how the particular instruction is documented to behave.
- rocqua 7y ago
  No, undefined behavior is specified by the standard. There is also 'implementation defined' which tends to be both architecture and compiler specific. The difference is that a program which invokes 'implementation defined' behavior can be well defined, whereas a program that invokes undefined behavior is literally free to do anything.