5 ms·

This bit me in a library of mine. Some third-party code I used was using long as memory offsets which failed on Windows 8. Unfortunately I was developing on W

by phs2501 11y ago

This bit me in a library of mine. Some third-party code I used was using long as memory offsets which failed on Windows 8. Unfortunately I was developing on Windows 7, so it didn't get noticed until the customer stumbled over it. :( (Fortunately said third-party code had an update that switched to ptrdiff_t in all the right places, so it was an easy fix.) I'm a Unix person, so the notion of long being less than word-length seems pretty silly to me, but I understand why they did it, sort of.

sjolsen 11y ago
>I'm a Unix person, so the notion of long being less than word-length seems pretty silly to me It's silly for Windows to do something a certain way just because that's not how Unix does it? What's silly is assuming that long and unsigned long are more than 32 bits wide, since neither C nor C++ has ever guaranteed anything more.
- sp332 11y ago
  If it's not specified, implementers have the option of making it wider. Matching the width of a pointer seems like a better choice.
  - cremno 11y ago
    Yeah however the C standard recommends that the integer conversion rank of size_t and ptrdiff_t is lower or equal to long. http://port70.net/~nsz/c/c11/n1570.html#7.19p4 http://port70.net/~nsz/c/c11/n1570.html#7.19p4
    - asveikau 11y ago
      From a certain angle it would seem size_t and ptrdiff_t are meant to roughly correspond to array subscript use cases. Therefore it's not unheard of for them to not be as wide as a pointer. intptr_t is for that. In your link they have examples where size_t and ptrdiff_t are 16 bits. Obviously this is absurd on today's machines. But you can imagine a machine where array subscript is most convenient at 16 bits and total addressable space is larger (16 bit x86 comes to mind). By the same token I don't think it would be too weird to have a 32 bit size_t on a 64 bit architecture. It would just make memcpy et al more annoying when your allocations are large. Anyway the quotation from your link: > The types used for size_t and ptrdiff_t should not have an integer conversion rank greater than that of signed long int unless the implementation supports objects large enough to make this necessary. I guess if longs are 32bit and you can have a 4g allocation this pretty well follows the spirit here.
- michaelt 11y ago
  I don't write much C, so perhaps someone can educate me. What are the advantages of having data types that behave differently on different platforms, like C does? It seems to make code less portable and I'm having difficulty seeing what the benefits are. I can appreciate that, on an 8-bit processor, you'd want access to an 8-bit data type for speed - but wouldn't that be better accomplished by explicitly choosing an 8 bit data type?
  - pmelendez 11y ago
    I can think in at least one reason. Having let's say `int` as long as the register size would get you portable efficiency since it doesn't matter if the underlying processor is 8, 16 , 32 or 64 bit, you always will have a type that fix just right. There are some other types (i.e int32_t, int64_t, etc) that you could use if you want to be sure that your variable would have the same size regardless of the architecture.
    - okasaki 11y ago
      For that, there's now intN_fast_t in stdint.h - the fastest data type that's at least N bits.
  - brudgers 11y ago
    Undefined behavior in C standards is often not a result of technical decisions but of practical concerns when developing a consensus during the standards process. The people on the standards committee historically included compiler vendors and users of diverse operating systems. When the process started in 1983, there were 8, 16, and 32 bit systems [and things like Burroughs 48 bit word systems]. The practical decision to leave the sizes undefined was made so that nobody was burdened unfairly. It's choices like this - not biasing stakeholders toward forgoing a standard for clear business reasons - that makes the adoption of standards likely. Subsequent C standards have adopted the same undefined behavior for the same reasons [there are still 8 and 16 bit systems developed with C] and to facilitate backward compatibility of the new standards.
    - 11y ago

by phs2501 11y ago

sjolsen 11y ago

>I'm a Unix person, so the notion of long being less than word-length seems pretty silly to me It's silly for Windows to do something a certain way just because that's not how Unix does it? What's silly is assuming that long and unsigned long are more than 32 bits wide, since neither C nor C++ has ever guaranteed anything more.

sp332 11y ago
If it's not specified, implementers have the option of making it wider. Matching the width of a pointer seems like a better choice.
- cremno 11y ago
  Yeah however the C standard recommends that the integer conversion rank of size_t and ptrdiff_t is lower or equal to long. http://port70.net/~nsz/c/c11/n1570.html#7.19p4 http://port70.net/~nsz/c/c11/n1570.html#7.19p4
  - asveikau 11y ago
    From a certain angle it would seem size_t and ptrdiff_t are meant to roughly correspond to array subscript use cases. Therefore it's not unheard of for them to not be as wide as a pointer. intptr_t is for that. In your link they have examples where size_t and ptrdiff_t are 16 bits. Obviously this is absurd on today's machines. But you can imagine a machine where array subscript is most convenient at 16 bits and total addressable space is larger (16 bit x86 comes to mind). By the same token I don't think it would be too weird to have a 32 bit size_t on a 64 bit architecture. It would just make memcpy et al more annoying when your allocations are large. Anyway the quotation from your link: > The types used for size_t and ptrdiff_t should not have an integer conversion rank greater than that of signed long int unless the implementation supports objects large enough to make this necessary. I guess if longs are 32bit and you can have a 4g allocation this pretty well follows the spirit here.
michaelt 11y ago
I don't write much C, so perhaps someone can educate me. What are the advantages of having data types that behave differently on different platforms, like C does? It seems to make code less portable and I'm having difficulty seeing what the benefits are. I can appreciate that, on an 8-bit processor, you'd want access to an 8-bit data type for speed - but wouldn't that be better accomplished by explicitly choosing an 8 bit data type?
- pmelendez 11y ago
  I can think in at least one reason. Having let's say `int` as long as the register size would get you portable efficiency since it doesn't matter if the underlying processor is 8, 16 , 32 or 64 bit, you always will have a type that fix just right. There are some other types (i.e int32_t, int64_t, etc) that you could use if you want to be sure that your variable would have the same size regardless of the architecture.
  - okasaki 11y ago
    For that, there's now intN_fast_t in stdint.h - the fastest data type that's at least N bits.
- brudgers 11y ago
  Undefined behavior in C standards is often not a result of technical decisions but of practical concerns when developing a consensus during the standards process. The people on the standards committee historically included compiler vendors and users of diverse operating systems. When the process started in 1983, there were 8, 16, and 32 bit systems [and things like Burroughs 48 bit word systems]. The practical decision to leave the sizes undefined was made so that nobody was burdened unfairly. It's choices like this - not biasing stakeholders toward forgoing a standard for clear business reasons - that makes the adoption of standards likely. Subsequent C standards have adopted the same undefined behavior for the same reasons [there are still 8 and 16 bit systems developed with C] and to facilitate backward compatibility of the new standards.
  - 11y ago