Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.wtal.de!news.tal.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Alessandro Basili Newsgroups: comp.lang.c Subject: Re: left shift count >= width of type Date: Fri, 04 Nov 2011 17:46:26 +0100 Lines: 112 Message-ID: <9hij73F5fnU1@mid.individual.net> References: <9hcichF56iU1@mid.individual.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------020709010906030101050008" X-Trace: individual.net WrclJiqvsishXic1PjdWuwny9AUD5lwNWLx0kJvoZNdRl89GtM Cancel-Lock: sha1:a0o5xtCsUMNBUTYJSH+MMQVGXjE= User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 In-Reply-To: X-Enigmail-Version: 1.3.2 Xref: x330-a1.tempe.blueboxinc.net comp.lang.c:12699 This is a multi-part message in MIME format. --------------020709010906030101050008 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/2/2011 12:34 PM, James Kuyper wrote: [...] > > The relevant clause is phrased in terms of whether not the the result > can be represented in the type, not the width of the type, For the > expression E1 << E2, "If E1 has a signed type and nonnegative value, and > E1 x 2^E2 is representable in the result type, then that is the > resulting value; otherwise, the behavior is undefined" (6.5.7p5) > > Therefore, for a 32-bit int, even 1 << 31 is problematic. That's an > example of why it's better to use unsigned types for most bit-masking > purposes. thanks for pointing that out. I indeed agree that bit masking may result in unexpected behavior if signed are used instead of unsigned, that's why I'm usually used to have my own data types not to get confused. > > However - and this is the key point - this is not a constraint, it's > undefined behavior. Conforming implementations are NOT required to issue > a diagnostic. > And I believe that is what happened in this case. Has to be said that this code is nearly 10 year old and back then probably gcc was not as rigorous as is today. >> Since this snippet is part of a very old implementation of g21k compiler >> for ADSP21xxx, I'm wondering why do we need to shift at all, isn't the >> above foo assignment equal to the following: >> >> foo = bar; > > Since this code has undefined behavior if INT_MAX < pow(2,32), I would > hope that it was intended for an implementation where INT_MAX > > pow(2,32). I have no idea whether the "g2lk compiler for ADSP21xxx" is > such an implementation. If it were, then the foo assignment statement > would not be equivalent to "foo = bar". Got your point. Indeed, compiling on my machine where INT_MAX < pow(2,32) the behavior is undefined, while it may very well be that in the author's case the INT_MAX > pow(2,32). That is also why there is a definition used in the code: > #if HOST_BITS_PER_LONG > HOST_BITS_PER_INT > #define HOST_BITS_PER_WIDE_INT HOST_BITS_PER_LONG > #define HOST_WIDE_INT long > #else > #define HOST_BITS_PER_WIDE_INT HOST_BITS_PER_INT > #define HOST_WIDE_INT int > #endif where there's a clear intention to distinguish between the two cases. Essential point is that apparently no attention was paid to the fact that int might be signed. > > However, it seem more plausible that the author of this code didn't know > or care about the fact that it had undefined behavior; it did what he > wanted it to do on the particular implementation where it needed to > work, and no attention was paid to whether or not it would do so > anywhere else. Considering that this compiler is specific for a family of DSPs, I rather think that was the case back then. --------------020709010906030101050008 Content-Type: application/pgp-keys; name="0xCD92ECB4.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0xCD92ECB4.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.11 (MingW32) mQENBE6mwlMBCAD+IQbcrWO3HHXRvQYhP7lWvxEtoZYttJ7kagFn14EW5EndOe9K iLiNvqY4Yd7/KKSRLHmU+h5nbdWetdSMsQNbJT+7gf4VrEr62Lv2SlnzzNXHK4Sm yBbaXd+nCpyCI4axJFChd4H961lw7WWligPpKix/IYXk61L9z3rNdkXp2NJpsD/2 2U+rkjM023gg5VN6wSe/g4OL5XE3W3wyBbU4K8hCGVW0kjxBWgd6uSJeNIKCT5bG LZc7urEIBuMsgxSBDM2ny47f+PRgT2ey45LPG+G4X3Yna226MOk1P+zW4XIHuo6w cCZ5rZTOma+MRsTbSjlONNSevDsfoV/nuL2PABEBAAG0O0FsZXNzYW5kcm8gQmFz aWxpIChubyBwYXNzd29yZCkgPGFsZXNzYW5kcm8uYmFzaWxpQGNlcm4uY2g+iQE+ BBMBAgAoBQJOpsJTAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAK CRA1TeSOzZLstNKrCADpymI9yF+XSAykhWzdSXmWBaDSogPZzQ9b8FvBUkykEqBU NWR9OL3xNKd2ehCGGug0tve4ienxloA4s3v0PJPeMO0O0UUNoe43wGmofspwyPrH gu+2cb7C/huPOeGY+Tww92+4SLheTMfrULYbb9pHt8Ao97OF2jlATQm8TztJb1N4 azzwxs2yihpNUQ6o2W5KmjljrHXXPIoEZGSWnjeNUynUAB7g9rXNJfnO5C2BAhX9 ACTDHmdJMVlaQUHtBXANxmHppdE3+P1yn5b4/PQG9HZEt/Sfhn4yw9BNL6iub+KN zf0506SHbEKYiDBWZe/P81GA/f+RMetwwOOO1S8FuQENBE6mwlMBCADZAp3NHyC+ VIRC1ISPcW9yW0Q2ppjmQo9rz6IZgbQtawS74th2buduhHOn9UcniSIzB9gcartE FcW2ctIDUkU8fkEtPBCyNzlbai/uBhi3DqYpmkUXKwy6ZnXaQgI5FkYYRRXnHIRq rASCckCrnZOiZnS/oYT9fd/+JJEdnMlldXOPT6pNoJSFJLpcliKLgHEMx8EjIffR DS0yGW+Wy/OSKOf1Jz7XveLqPpdAbrK0jAIqZVGmvhY4V7g2QJfAbAmA6jHCAKwC ULfq4hY+P9s1zU1L19/fJoMuopKgQr7rNeC9UquTR0GWY6K2u6D40Onv7osi9Edk C6hKp7QFKUXVABEBAAGJASUEGAECAA8FAk6mwlMCGwwFCQlmAYAACgkQNU3kjs2S 7LSd4gf/SlUPhsmv0hjFlcRvfz3ZyeU43wbyYvYgOh/6JGjSNhgTbumXKgtvg+YW nZzx8nVIGUard8X+MqStmigNoLxW9z18wrFopd/I0oqdUbakR7yXUY4ZklXPLbyk TPRysx74w2W4FARM54Lc0CU8llL3Y7pSAEecsQcrrr487YEOmAN1E+ugxaU3GVbM ZmC7SeYh6ykD/IwbLSSO0F/6HmCswf2GFNRB9/YFOoj7ka9vzwTXVwcRCWOozLlw 00QWNqBWzHs0Hs1GYT/WnwfRY3lk1hy5kxKw/SXrJNL+O245/r1S0H0EqfDUVCt6 TU0HOkRYra7GKIhd8KFomRqf4dwhoQ== =2qyd -----END PGP PUBLIC KEY BLOCK----- --------------020709010906030101050008--