Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.unix.programmer > #7948 > unrolled thread
| Started by | spud@potato.field |
|---|---|
| First post | 2016-03-01 11:06 +0000 |
| Last post | 2016-03-20 07:12 -0400 |
| Articles | 20 on this page of 186 — 27 participants |
Back to article view | Back to comp.unix.programmer
Odd compiler behaviour? spud@potato.field - 2016-03-01 11:06 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-01 12:57 +0100
Re: Odd compiler behaviour? spud@potato.field - 2016-03-01 13:48 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-01 15:46 +0100
Re: Odd compiler behaviour? spud@potato.field - 2016-03-01 15:08 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-01 08:36 -0800
Re: Odd compiler behaviour? spud@potato.field - 2016-03-01 16:47 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-01 08:51 -0800
Re: Odd compiler behaviour? spud@potato.field - 2016-03-01 17:05 +0000
Re: Odd compiler behaviour? Geoff <geoff@invalid.invalid> - 2016-03-01 10:00 -0800
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-01 10:56 -0800
Re: Odd compiler behaviour? spud@potato.field - 2016-03-02 09:42 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-01 10:55 -0800
Re: Odd compiler behaviour? spud@potato.field - 2016-03-02 09:46 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-01 20:59 +0000
Re: Odd compiler behaviour? Geoff <geoff@invalid.invalid> - 2016-03-01 10:09 -0800
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 13:03 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-01 13:54 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-01 14:15 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-01 14:38 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-01 14:59 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-01 11:20 -0500
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-01 08:45 -0800
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 16:54 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-01 13:14 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 19:10 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-01 19:26 +0000
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 19:57 +0000
Re: Odd compiler behaviour? Noob <root@127.0.0.1> - 2016-03-01 21:07 +0100
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-01 15:40 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 21:14 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-01 21:20 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-01 21:59 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-01 22:09 +0000
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 23:04 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-01 17:08 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-01 22:59 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-02 10:39 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 16:19 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-02 11:56 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 17:21 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-02 12:42 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 18:03 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-02 10:41 -0800
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 18:59 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-02 11:40 -0800
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 20:05 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-02 15:32 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 20:51 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-02 16:01 -0500
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 21:10 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-02 16:41 -0500
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-02 13:52 -0800
Re: Odd compiler behaviour? Richard Kettlewell <rjk@greenend.org.uk> - 2016-03-02 22:14 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-02 18:54 -0500
Re: Odd compiler behaviour? gazelle@shell.xmission.com (Kenny McCormack) - 2016-03-02 21:30 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-02 13:34 -0800
Re: Odd compiler behaviour? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-03-05 16:48 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-05 15:29 -0500
Re: Odd compiler behaviour? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-03-05 15:41 -0500
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-05 23:19 -0500
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-06 12:44 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-06 14:10 -0500
Re: Odd compiler behaviour? spud@potato.field - 2016-03-07 09:53 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-08 12:59 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-08 13:59 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-08 15:28 +0000
Re: Odd compiler behaviour? Barry Margolin <barmar@alum.mit.edu> - 2016-03-08 10:42 -0500
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-08 17:09 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-08 20:38 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-08 22:15 +0000
Re: Odd compiler behaviour? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-03-08 16:21 -0700
Re: Odd compiler behaviour? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-03-08 10:47 -0500
Re: Odd compiler behaviour? spud@potato.field - 2016-03-08 16:04 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-09 00:21 -0500
Re: Odd compiler behaviour? spud@potato.field - 2016-03-09 09:40 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-09 11:31 +0100
Re: Odd compiler behaviour? BartC <bc@freeuk.com> - 2016-03-09 11:21 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-09 12:57 +0100
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-09 15:32 +0000
Re: Odd compiler behaviour? Robert Wessel <robertwessel2@yahoo.com> - 2016-03-09 11:13 -0600
Re: Odd compiler behaviour? Les Cargill <lcargill99@comcast.com> - 2016-03-09 07:16 -0600
Re: Odd compiler behaviour? spud@potato.field - 2016-03-09 13:19 +0000
Re: Odd compiler behaviour? Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-09 09:28 -0500
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-09 15:35 +0000
Re: Odd compiler behaviour? Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-09 11:08 -0500
Re: Odd compiler behaviour? spud@potato.field - 2016-03-09 13:32 +0000
Re: Odd compiler behaviour? Nicolas George <nicolas$george@salle-s.org> - 2016-03-09 13:34 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-09 16:17 +0000
Re: Odd compiler behaviour? Nicolas George <nicolas$george@salle-s.org> - 2016-03-09 16:54 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-09 19:45 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-10 09:34 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-10 15:40 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-10 15:57 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-10 16:07 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-10 14:12 -0500
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-10 19:51 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-10 20:08 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-10 22:31 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-10 22:55 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-10 17:25 -0500
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-11 17:49 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-12 18:11 -0800
Re: Odd compiler behaviour? spud@potato.field - 2016-03-14 09:43 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-14 15:57 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-14 12:16 -0400
Re: Odd compiler behaviour? spud@potato.field - 2016-03-14 17:00 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-14 17:14 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-14 18:29 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-14 18:46 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-14 18:16 -0400
Re: Odd compiler behaviour? Ian Collins <ian-news@hotmail.com> - 2016-03-15 20:45 +1300
Re: Odd compiler behaviour? spud@potato.field - 2016-03-15 09:25 +0000
Re: Odd compiler behaviour? Ian Collins <ian-news@hotmail.com> - 2016-03-15 22:36 +1300
Re: Odd compiler behaviour? spud@potato.field - 2016-03-15 10:23 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-15 10:11 -0400
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-15 14:33 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-15 15:41 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-17 18:18 -0400
Re: Odd compiler behaviour? Nicolas George <nicolas$george@salle-s.org> - 2016-03-17 23:01 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-18 09:44 +0000
Re: Odd compiler behaviour? Ian Collins <ian-news@hotmail.com> - 2016-03-29 11:31 +1300
Re: Odd compiler behaviour? spud@potato.field - 2016-03-29 08:32 +0000
Re: Odd compiler behaviour? Ian Collins <ian-news@hotmail.com> - 2016-03-29 21:46 +1300
Re: Odd compiler behaviour? spud@potato.field - 2016-03-29 09:25 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-29 13:22 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-29 14:07 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-29 15:59 +0100
Re: Odd compiler behaviour? spud@potato.field - 2016-03-29 15:12 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-29 17:27 +0100
Re: Odd compiler behaviour? spud@potato.field - 2016-03-30 08:35 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-29 16:29 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-30 08:23 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-30 13:14 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-30 13:38 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-30 15:20 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-29 16:23 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-18 15:58 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-18 16:20 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-19 02:46 -0400
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-15 15:42 +0000
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-15 21:55 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-15 13:37 +0000
Re: Odd compiler behaviour? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-03-31 19:25 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-09 15:17 +0100
Re: Odd compiler behaviour? spud@potato.field - 2016-03-09 16:23 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-09 19:30 +0100
Re: Odd compiler behaviour? Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-09 14:40 -0500
Re: Odd compiler behaviour? spud@potato.field - 2016-03-10 09:28 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-10 10:57 +0100
Re: Odd compiler behaviour? spud@potato.field - 2016-03-10 10:29 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-10 12:50 +0100
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-10 12:21 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-10 12:22 +0000
Re: Odd compiler behaviour? BartC <bc@freeuk.com> - 2016-03-10 13:01 +0000
Re: Odd compiler behaviour? spud@potato.field - 2016-03-10 13:55 +0000
Re: Odd compiler behaviour? Keith Thompson <kst-u@mib.org> - 2016-03-10 08:29 -0800
Re: Odd compiler behaviour? gordonb.uf2r1@burditt.org (Gordon Burditt) - 2016-03-12 03:36 -0600
Re: Odd compiler behaviour? Richard Damon <Richard@Damon-Family.org> - 2016-03-12 10:13 -0500
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-13 23:11 +0100
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-13 22:12 +0000
succint expressions (was: Odd compiler behaviour?) Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-09 11:04 +0000
Re: Odd compiler behaviour? BartC <bc@freeuk.com> - 2016-03-09 11:39 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-09 19:51 -0500
Re: Odd compiler behaviour? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-10 01:00 +0000
Re: Odd compiler behaviour? Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-09 09:27 -0500
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-09 15:24 +0000
Re: Odd compiler behaviour? Jerry Stuckle <jstucklex@attglobal.net> - 2016-03-09 11:10 -0500
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-09 19:14 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-09 20:18 +0000
Re: Odd compiler behaviour? gordonb.2x965@burditt.org (Gordon Burditt) - 2016-03-14 23:45 -0500
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-09 16:11 +0000
Re: Odd compiler behaviour? David Brown <david.brown@hesbynett.no> - 2016-03-09 19:37 +0100
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-09 19:34 +0000
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-09 20:05 +0000
[OT] Re: Odd compiler behaviour? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-03-09 15:13 -0500
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-09 19:51 -0500
Re: Odd compiler behaviour? Rainer Weikusat <rweikusat@talktalk.net> - 2016-03-10 15:35 +0000
Re: Odd compiler behaviour? "James K. Lowden" <jklowden@speakeasy.net> - 2016-03-09 00:21 -0500
Re: Odd compiler behaviour? Kaz Kylheku <330-706-9395@kylheku.com> - 2016-03-01 21:01 +0000
Re: Odd compiler behaviour? raltbos@xs4all.nl (Richard Bos) - 2016-03-02 12:09 +0000
Re: Odd compiler behaviour? scott@slp53.sl.home (Scott Lurndal) - 2016-03-01 14:18 +0000
Re: Odd compiler behaviour? raltbos@xs4all.nl (Richard Bos) - 2016-03-02 12:53 +0000
Re: Odd compiler behaviour? Noob <root@127.0.0.1> - 2016-03-01 16:44 +0100
Re: Odd compiler behaviour? Geoff <geoff@invalid.invalid> - 2016-03-01 09:22 -0800
Re: Odd compiler behaviour? David Thompson <dave.thompson2@verizon.net> - 2016-03-20 07:12 -0400
Page 1 of 10 [1] 2 3 … 10 Next page →
| From | spud@potato.field |
|---|---|
| Date | 2016-03-01 11:06 +0000 |
| Subject | Odd compiler behaviour? |
| Message-ID | <nb3t47$19o6$1@gioia.aioe.org> |
I noticed some odd behaviour with left shifting off the end of an int with both
gcc on Linux and clang on OS/X so I wrote the following test program:
#include <stdio.h>
int main()
{
int s = 32;
printf("%d\n",(int)1 << s);
printf("%d\n",(int)1 << 32);
return 0;
}
With both gcc and clang a warning is given about type width for the 2nd printf
but not the first which is understandable, however the results are different
between the 2 printfs. With both gcc and clang , the first shift apparently
wraps the bit and the result is 1 (increase the shift to 33 and the answer is 2
etc). However with gcc the second printf returns zero whereas with clang it
returns some random number.
Is this behaviour expected or simply undefined? And why the difference between
the 2 shifts? I'd have expected a zero result in all circumstances.
--
Spud
[toc] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-03-01 12:57 +0100 |
| Message-ID | <nb3vud$ttl$1@dont-email.me> |
| In reply to | #7948 |
On 01/03/16 12:06, spud@potato.field wrote:
> I noticed some odd behaviour with left shifting off the end of an int with both
> gcc on Linux and clang on OS/X so I wrote the following test program:
>
> #include <stdio.h>
>
> int main()
> {
> int s = 32;
> printf("%d\n",(int)1 << s);
> printf("%d\n",(int)1 << 32);
> return 0;
> }
>
>
> With both gcc and clang a warning is given about type width for the 2nd printf
> but not the first which is understandable, however the results are different
> between the 2 printfs. With both gcc and clang , the first shift apparently
> wraps the bit and the result is 1 (increase the shift to 33 and the answer is 2
> etc). However with gcc the second printf returns zero whereas with clang it
> returns some random number.
>
> Is this behaviour expected or simply undefined? And why the difference between
> the 2 shifts? I'd have expected a zero result in all circumstances.
>
It is undefined behaviour - compilers are free to generate whatever
value they like (or launch nasal daemons, though these are rarely seen
in practice with such code). Typical code would be to use a fixed value
such as 0, or generate assembly shift instructions and give you whatever
the cpu returns, or leave the register value entirely unset (giving a
random value or some old data). Sometimes the undefined nature of the
result can be used to simplify other code. Given the code:
// Assuming int is 32-bit
void foo(int i) {
if ((i << 32) == 0) {
printf("Result is zero\n");
} else {
printf("Result is non-zero\n");
}
}
the compiler could choose to print neither, both, or one of these
statements, with no regard for the value in "i". (It could actually
choose to do anything it wants, but those are the likely choices.)
Different compilers will give different results, and different
optimisation levels will give different results.
It is slightly disappointing that neither gcc nor clang will warn about
the case of "int s = 32; 1 << s;" - there is no reason why they could
not do so.
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-01 13:48 +0000 |
| Message-ID | <nb46jj$1sbo$1@gioia.aioe.org> |
| In reply to | #7949 |
On Tue, 01 Mar 2016 12:57:54 +0100 David Brown <david.brown@hesbynett.no> wrote: >On 01/03/16 12:06, spud@potato.field wrote: >It is slightly disappointing that neither gcc nor clang will warn about >the case of "int s = 32; 1 << s;" - there is no reason why they could >not do so. Presumably because 'i' won't be initialised until runtime and the compiler would have to check all execution paths to see if the value it contained by the time it got to the shift was valid. And things would get even more complicated if an expression was used instead. Probably not worth the effort. -- Spud
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-03-01 15:46 +0100 |
| Message-ID | <nb49qt$4r7$1@dont-email.me> |
| In reply to | #7951 |
On 01/03/16 14:48, spud@potato.field wrote: > On Tue, 01 Mar 2016 12:57:54 +0100 > David Brown <david.brown@hesbynett.no> wrote: >> On 01/03/16 12:06, spud@potato.field wrote: >> It is slightly disappointing that neither gcc nor clang will warn about >> the case of "int s = 32; 1 << s;" - there is no reason why they could >> not do so. > > Presumably because 'i' won't be initialised until runtime and the compiler > would have to check all execution paths to see if the value it contained > by the time it got to the shift was valid. And things would get even more > complicated if an expression was used instead. Probably not worth the effort. > The compiler can happily see that "s" is initialised to 32, and that this value will not change. gcc uses this to determine that the value is undefined, and sets the relevant register for the printf call to 0 (choosing to give a consistent run-time behaviour for the undefined behaviour in source) - clang determines that the value is undefined and does not bother initialising the register at all. In both cases, the compilers take advantage of the clearly undefined behaviour of "int s = 32; 1 << s;" - but neither has the decency to warn the user of the situation. Propagation of known compile-time values like this is very much worth the effort - it is a significant part of compiler optimisation.
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-01 15:08 +0000 |
| Message-ID | <nb4b8g$61u$1@gioia.aioe.org> |
| In reply to | #7956 |
On Tue, 01 Mar 2016 15:46:42 +0100
David Brown <david.brown@hesbynett.no> wrote:
>On 01/03/16 14:48, spud@potato.field wrote:
>> On Tue, 01 Mar 2016 12:57:54 +0100
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 01/03/16 12:06, spud@potato.field wrote:
>>> It is slightly disappointing that neither gcc nor clang will warn about
>>> the case of "int s = 32; 1 << s;" - there is no reason why they could
>>> not do so.
>>
>> Presumably because 'i' won't be initialised until runtime and the compiler
>> would have to check all execution paths to see if the value it contained
>> by the time it got to the shift was valid. And things would get even more
>> complicated if an expression was used instead. Probably not worth the effort.
>>
>
>The compiler can happily see that "s" is initialised to 32, and that
>this value will not change. gcc uses this to determine that the value
>is undefined, and sets the relevant register for the printf call to 0
The 1 << s actually returns 1 , not zero. The hard coded value returns zero.
Also this code gives the same result if you enter 32. So unless gcc is psychic
the '1' result is calculated at runtime, not compile time:
int main()
{
char str[10];
int s;
gets(str);
s = atoi(str);
printf("%d\n",(int)1 << s);
return 0;
}
--
Spud
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-03-01 08:36 -0800 |
| Message-ID | <ln37saxiic.fsf@kst-u.example.com> |
| In reply to | #7958 |
spud@potato.field writes:
> On Tue, 01 Mar 2016 15:46:42 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>>On 01/03/16 14:48, spud@potato.field wrote:
>>> On Tue, 01 Mar 2016 12:57:54 +0100
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> On 01/03/16 12:06, spud@potato.field wrote:
>>>> It is slightly disappointing that neither gcc nor clang will warn about
>>>> the case of "int s = 32; 1 << s;" - there is no reason why they could
>>>> not do so.
>>>
>>> Presumably because 'i' won't be initialised until runtime and the compiler
>>> would have to check all execution paths to see if the value it contained
>>> by the time it got to the shift was valid. And things would get even more
>>> complicated if an expression was used instead. Probably not worth the effort.
>>>
>>
>>The compiler can happily see that "s" is initialised to 32, and that
>>this value will not change. gcc uses this to determine that the value
>>is undefined, and sets the relevant register for the printf call to 0
>
> The 1 << s actually returns 1 , not zero. The hard coded value returns zero.
> Also this code gives the same result if you enter 32. So unless gcc is psychic
> the '1' result is calculated at runtime, not compile time:
It depends on the optimization level. Experiment shows that gcc
generates code to compute `1 << s` at run time if optimization is not
enabled, but computes it at compile time with -O1 or higher.
You can use the "-S" option to examine the generated assembly code.
> int main()
> {
> char str[10];
> int s;
> gets(str);
> s = atoi(str);
> printf("%d\n",(int)1 << s);
> return 0;
> }
Why are you calling gets()?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-01 16:47 +0000 |
| Message-ID | <nb4h2m$i69$1@gioia.aioe.org> |
| In reply to | #7963 |
On Tue, 01 Mar 2016 08:36:27 -0800
Keith Thompson <kst-u@mib.org> wrote:
>spud@potato.field writes:
>> The 1 << s actually returns 1 , not zero. The hard coded value returns zero.
>> Also this code gives the same result if you enter 32. So unless gcc is
>psychic
>> the '1' result is calculated at runtime, not compile time:
>
>It depends on the optimization level. Experiment shows that gcc
>generates code to compute `1 << s` at run time if optimization is not
>enabled, but computes it at compile time with -O1 or higher.
How can it compute it at compile time if it doesn't know what the value of 's'
is going to be?
>> int main()
>> {
>> char str[10];
>> int s;
>> gets(str);
>> s = atoi(str);
>> printf("%d\n",(int)1 << s);
>> return 0;
>> }
>
>Why are you calling gets()?
Why in this example or why at all because its an unsafe function?
Its an easy way to get user input in a simple example to demonstrate that the
output from printf can't possibly be computed at compile time since the user
enters the shift value at runtime.
--
Spud
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-03-01 08:51 -0800 |
| Message-ID | <lnsi0aw38d.fsf@kst-u.example.com> |
| In reply to | #7965 |
spud@potato.field writes:
> On Tue, 01 Mar 2016 08:36:27 -0800
> Keith Thompson <kst-u@mib.org> wrote:
>>spud@potato.field writes:
>>> The 1 << s actually returns 1 , not zero. The hard coded value
>>> returns zero. Also this code gives the same result if you enter
>>> 32. So unless gcc is psychic the '1' result is calculated at
>>> runtime, not compile time:
>>
>>It depends on the optimization level. Experiment shows that gcc
>>generates code to compute `1 << s` at run time if optimization is not
>>enabled, but computes it at compile time with -O1 or higher.
>
> How can it compute it at compile time if it doesn't know what the
> value of 's' is going to be?
It can't, of course. In the example I was referring to, the value of s
*can* be determined at compile time, and gcc does so with "-O1" or
higher.
>>> int main()
>>> {
>>> char str[10];
>>> int s;
>>> gets(str);
>>> s = atoi(str);
>>> printf("%d\n",(int)1 << s);
>>> return 0;
>>> }
>>
>>Why are you calling gets()?
>
> Why in this example or why at all because its an unsafe function?
>
> Its an easy way to get user input in a simple example to demonstrate that the
> output from printf can't possibly be computed at compile time since the user
> enters the shift value at runtime.
Ok. Using gets() obscured the point you were making. It's not merely
unsafe; it's been removed from the language as of the 2011 standard.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-01 17:05 +0000 |
| Message-ID | <nb4i5g$kjt$1@gioia.aioe.org> |
| In reply to | #7966 |
On Tue, 01 Mar 2016 08:51:46 -0800 Keith Thompson <kst-u@mib.org> wrote: >spud@potato.field writes: >> On Tue, 01 Mar 2016 08:36:27 -0800 >> Keith Thompson <kst-u@mib.org> wrote: >>>spud@potato.field writes: >>>> The 1 << s actually returns 1 , not zero. The hard coded value >>>> returns zero. Also this code gives the same result if you enter >>>> 32. So unless gcc is psychic the '1' result is calculated at >>>> runtime, not compile time: >>> >>>It depends on the optimization level. Experiment shows that gcc >>>generates code to compute `1 << s` at run time if optimization is not >>>enabled, but computes it at compile time with -O1 or higher. >> >> How can it compute it at compile time if it doesn't know what the >> value of 's' is going to be? > >It can't, of course. In the example I was referring to, the value of s >*can* be determined at compile time, and gcc does so with "-O1" or >higher. Ok. >> Its an easy way to get user input in a simple example to demonstrate that the >> output from printf can't possibly be computed at compile time since the user >> enters the shift value at runtime. > >Ok. Using gets() obscured the point you were making. It's not merely Obscured it or you just didn't read the code properly? >unsafe; it's been removed from the language as of the 2011 standard. TBH I doubt many people care much about C standards past 1999. C++ leads the way these days I'm afraid. -- Spud
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2016-03-01 10:00 -0800 |
| Message-ID | <pqlbdbdjtjsaonu5hd4avfsurcp80mab0i@4ax.com> |
| In reply to | #7968 |
On Tue, 1 Mar 2016 17:05:52 +0000 (UTC), spud@potato.field wrote: >TBH I doubt many people care much about C standards past 1999. C++ leads the >way these days I'm afraid. It's interesting you should say that since C++ relies on the C standard library and if gets has been removed from the C standard library then it's removed from C++. Furthermore, what you have written isn't C++ but C and you posted your question in a C newsgroup. But none of this is relevant to your original question about why your original code gives unexpected results.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-03-01 10:56 -0800 |
| Message-ID | <lnk2lmvxgu.fsf@kst-u.example.com> |
| In reply to | #7971 |
Geoff <geoff@invalid.invalid> writes:
> On Tue, 1 Mar 2016 17:05:52 +0000 (UTC), spud@potato.field wrote:
>>TBH I doubt many people care much about C standards past 1999. C++ leads the
>>way these days I'm afraid.
>
> It's interesting you should say that since C++ relies on the C
> standard library and if gets has been removed from the C standard
> library then it's removed from C++. Furthermore, what you have written
> isn't C++ but C and you posted your question in a C newsgroup.
The current C++ standard refers to the C99 library, not the C11 library.
I believe there are discussions in progress about updating that for the
next C++ standard.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-02 09:42 +0000 |
| Message-ID | <nb6cj2$1fur$1@gioia.aioe.org> |
| In reply to | #7971 |
On Tue, 01 Mar 2016 10:00:00 -0800 Geoff <geoff@invalid.invalid> wrote: >On Tue, 1 Mar 2016 17:05:52 +0000 (UTC), spud@potato.field wrote: > >>TBH I doubt many people care much about C standards past 1999. C++ leads the >>way these days I'm afraid. > >It's interesting you should say that since C++ relies on the C >standard library and if gets has been removed from the C standard >library then it's removed from C++. Furthermore, what you have written >isn't C++ but C and you posted your question in a C newsgroup. Did I write it in C? Wow, thanks for the heads up there! I wondered why I hadn't put in any classes, maybe a factory or singleton for constructing the variable and use some rtti to really get to the meat of the issue. -- Spud
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-03-01 10:55 -0800 |
| Message-ID | <lnoaayvxig.fsf@kst-u.example.com> |
| In reply to | #7968 |
spud@potato.field writes:
> On Tue, 01 Mar 2016 08:51:46 -0800
> Keith Thompson <kst-u@mib.org> wrote:
>>spud@potato.field writes:
[...]
>>> Its an easy way to get user input in a simple example to demonstrate that the
>>> output from printf can't possibly be computed at compile time since the user
>>> enters the shift value at runtime.
>>
>>Ok. Using gets() obscured the point you were making. It's not merely
>
> Obscured it or you just didn't read the code properly?
Possibly both. You posted code and didn't say anything about it. The
call to gets() was the first thing that jumped out at me.
>>unsafe; it's been removed from the language as of the 2011 standard.
>
> TBH I doubt many people care much about C standards past 1999. C++ leads the
> way these days I'm afraid.
It's been deprecated longer than that -- and if you want comp.lang.c++
(or comp.lang.c++.moderated, or comp.std.c++) you know where to find it.
In any case, several major C compilers, including gcc and clang, have
implemented large parts of C11.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-02 09:46 +0000 |
| Message-ID | <nb6cqd$1gd7$1@gioia.aioe.org> |
| In reply to | #7975 |
On Tue, 01 Mar 2016 10:55:19 -0800 Keith Thompson <kst-u@mib.org> wrote: >spud@potato.field writes: >> On Tue, 01 Mar 2016 08:51:46 -0800 >> Keith Thompson <kst-u@mib.org> wrote: >>>spud@potato.field writes: >[...] >>>> Its an easy way to get user input in a simple example to demonstrate that >the >>>> output from printf can't possibly be computed at compile time since the >user >>>> enters the shift value at runtime. >>> >>>Ok. Using gets() obscured the point you were making. It's not merely >> >> Obscured it or you just didn't read the code properly? > >Possibly both. You posted code and didn't say anything about it. The >call to gets() was the first thing that jumped out at me. I did mention use input which should have been a clue. However given I'm posting to programming groups I would have expected a reader to comprehend a few lines of basic C without a bullet point summation of the code. >It's been deprecated longer than that -- and if you want comp.lang.c++ >(or comp.lang.c++.moderated, or comp.std.c++) you know where to find it. > >In any case, several major C compilers, including gcc and clang, have >implemented large parts of C11. Given its 2016 one would hope so. -- Spud
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <330-706-9395@kylheku.com> |
|---|---|
| Date | 2016-03-01 20:59 +0000 |
| Message-ID | <20160301125150.814@kylheku.com> |
| In reply to | #7966 |
On 2016-03-01, Keith Thompson <kst-u@mib.org> wrote:
> spud@potato.field writes:
>> On Tue, 01 Mar 2016 08:36:27 -0800
>>>> int main()
>>>> {
>>>> char str[10];
>>>> int s;
>>>> gets(str);
>>>> s = atoi(str);
>>>> printf("%d\n",(int)1 << s);
>>>> return 0;
>>>> }
>>>
>>>Why are you calling gets()?
>>
>> Why in this example or why at all because its an unsafe function?
>>
>> Its an easy way to get user input in a simple example to demonstrate that the
>> output from printf can't possibly be computed at compile time since the user
>> enters the shift value at runtime.
>
> Ok. Using gets() obscured the point you were making. It's not merely
> unsafe; it's been removed from the language as of the 2011 standard.
For probing undefind behavior, it's ideal.
With gets in place as above, we can cause undefined behavior by entering
the input "32" (if int is only that wide).
Or we can choose to have undefined behavior happen even before the
shift, by entering a line of ten or more characters.
The program is made more "feature rich".
I think it should also "return s;", so that we can cause it
to have an implementation-defined termination status
with a nonzero s.
:)
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2016-03-01 10:09 -0800 |
| Message-ID | <f7mbdbpg13c8j5l7r6cb5l3em82gog4u5k@4ax.com> |
| In reply to | #7958 |
On Tue, 1 Mar 2016 15:08:00 +0000 (UTC), spud@potato.field wrote:
>The 1 << s actually returns 1 , not zero. The hard coded value returns zero.
>Also this code gives the same result if you enter 32. So unless gcc is psychic
>the '1' result is calculated at runtime, not compile time:
>
>int main()
>{
> char str[10];
> int s;
> gets(str);
> s = atoi(str);
> printf("%d\n",(int)1 << s);
> return 0;
>}
Your fallacious assertion is not proved and you could easily prove it
yourself by looking at the compiled code.
Since you are on OS/X and your target is x86, what you are seeing is
an artifact of the eax shl,cl instruction the compiler is generating
in un-optimized mode. This instruction is limited by the fact the cl
register is masked to 5 bits (cl & 0x1f) internally in the processor
and when cl == 32 it is effectively no shift at all. (0x20 & 0x1f ==
0)
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <rjk@greenend.org.uk> |
|---|---|
| Date | 2016-03-01 13:03 +0000 |
| Message-ID | <87si0afiyr.fsf@mantic.terraraq.uk> |
| In reply to | #7948 |
spud@potato.field writes:
> I noticed some odd behaviour with left shifting off the end of an int
> with both gcc on Linux and clang on OS/X so I wrote the following test
> program:
>
> #include <stdio.h>
>
> int main()
> {
> int s = 32;
> printf("%d\n",(int)1 << s);
> printf("%d\n",(int)1 << 32);
> return 0;
> }
>
>
> With both gcc and clang a warning is given about type width for the
> 2nd printf but not the first which is understandable, however the
> results are different between the 2 printfs. With both gcc and clang ,
> the first shift apparently wraps the bit and the result is 1 (increase
> the shift to 33 and the answer is 2 etc). However with gcc the second
> printf returns zero whereas with clang it returns some random number.
>
> Is this behaviour expected or simply undefined?
Undefined. C99 6.5.7#4:
The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
bits are filled with zeros. If E1 has an unsigned type, the value of
the result is E1*2^E2, reduced modulo one more than the maximum
value representable in the result type. If E1 has a signed type and
nonnegative value, and E1*2^E2 is representable in the result type,
then that is the resulting value; otherwise, the behavior is
undefined.
> And why the difference between the 2 shifts? I'd have expected a zero
> result in all circumstances.
Because it’s undefined. There are no requirements whatsoever on the
results of the calculation.
Here’a an even more pathological outcome:
$ cat t.c && clang -o t -O2 t.c && ./t
#include <stdio.h>
int main()
{
int s = 32;
printf(“%#x\n”,(int)1 << s);
printf(“%#x\n”,(int)1 << 32);
printf(“\n”);
return 0;
}
t.c:7:31: warning: shift count >= width of type [-Wshift-count-overflow]
printf(“%#x\n”,(int)1 << 32);
^ ~~
1 warning generated.
0x84a52f98
0x7ffffff5
$ uname -m
x86_64
In this example the compiler has simply not bothered computing the
undefined values and the output is whatever value happens to be lying
around in a CPU register at the time of the call to printf.
--
http://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-01 13:54 +0000 |
| Message-ID | <nb46u1$1ste$1@gioia.aioe.org> |
| In reply to | #7950 |
On Tue, 01 Mar 2016 13:03:56 +0000 Richard Kettlewell <rjk@greenend.org.uk> wrote: >Undefined. C99 6.5.7#4: That seems an odd decision to make. Its not undefined when you do an assembly left shift in most CPUs AFAIK - you get zero or a wrap if you use a rotate - so why should it be undefined in C? However looking at the assembly output from both gcc and clang they don't see to be in a hurry to use the CPU shift instructions but seem to role their own methods using movs which I don't understand the reason for. -- Spud
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <330-706-9395@kylheku.com> |
|---|---|
| Date | 2016-03-01 14:15 +0000 |
| Message-ID | <20160301061135.783@kylheku.com> |
| In reply to | #7952 |
On 2016-03-01, spud@potato.field <spud@potato.field> wrote: > On Tue, 01 Mar 2016 13:03:56 +0000 > Richard Kettlewell <rjk@greenend.org.uk> wrote: >>Undefined. C99 6.5.7#4: > > That seems an odd decision to make. Its not undefined when you do an assembly > left shift in most CPUs AFAIK - you get zero or a wrap if you use a rotate - so Well, that's part of the problem, isn't it? It's well-defined for each of the instruction sets (that you know) *individually*, but not for assembly language as such. So that means, at best, we could have it "implementation-defined" in C, if all that mattered was those CPUs.
[toc] | [prev] | [next] | [standalone]
| From | spud@potato.field |
|---|---|
| Date | 2016-03-01 14:38 +0000 |
| Message-ID | <nb49gp$2ha$1@gioia.aioe.org> |
| In reply to | #7953 |
On Tue, 1 Mar 2016 14:15:16 +0000 (UTC) Kaz Kylheku <330-706-9395@kylheku.com> wrote: >On 2016-03-01, spud@potato.field <spud@potato.field> wrote: >> On Tue, 01 Mar 2016 13:03:56 +0000 >> Richard Kettlewell <rjk@greenend.org.uk> wrote: >>>Undefined. C99 6.5.7#4: >> >> That seems an odd decision to make. Its not undefined when you do an assembly >> left shift in most CPUs AFAIK - you get zero or a wrap if you use a rotate - >so > >Well, that's part of the problem, isn't it? > >It's well-defined for each of the instruction sets (that you know) >*individually*, but not for assembly language as such. Ok, but why not just define it anyway to give a certain result irrespective of what various CPUs do for the sake of portability? C data types are defined to be a specific size and have a specific range regardless of whether all possible processors support them natively so I don't see why it couldn't be done for this. -- Spud
[toc] | [prev] | [next] | [standalone]
Page 1 of 10 [1] 2 3 … 10 Next page →
Back to top | Article view | comp.unix.programmer
csiph-web