Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #4783 > unrolled thread

C programming in 2011

Back to article view | Back to comp.lang.c

Contents

  C programming in 2011 Duncan Bayne <dhgbayne@gmail.com> - 2011-05-25 20:27 -0700
    Re: C programming in 2011 Shao Miller <sha0.miller@gmail.com> - 2011-05-25 22:33 -0500
    Re: C programming in 2011 Duncan Bayne <dhgbayne@gmail.com> - 2011-05-25 20:58 -0700
      Re: C programming in 2011 Duncan Bayne <dhgbayne@gmail.com> - 2011-05-25 21:06 -0700
        Re: C programming in 2011 Shao Miller <sha0.miller@gmail.com> - 2011-05-25 23:24 -0500
    Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-05-26 07:51 +0000
      Re: C programming in 2011 Chris H <chris@phaedsys.org> - 2011-05-26 11:15 +0100
        Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-05-26 06:53 -0400
          Re: C programming in 2011 Ian Collins <ian-news@hotmail.com> - 2011-05-27 09:12 +1200
        Re: C programming in 2011 Nizumzen <chicken@mcnuggets.com> - 2011-05-29 00:39 +0100
          Re: C programming in 2011 Noob <root@127.0.0.1> - 2011-06-01 17:38 +0200
            Re: C programming in 2011 Nizumzen <chicken@mcnuggets.com> - 2011-06-01 22:34 +0100
              Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-01 21:42 +0000
                Re: C programming in 2011 Nizumzen <chicken@mcnuggets.com> - 2011-06-02 00:33 +0100
      Re: C programming in 2011 Duncan Bayne <dhgbayne@gmail.com> - 2011-05-26 03:41 -0700
        Re: C programming in 2011 Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-28 00:46 +0000
      Re: C programming in 2011 Chad <cdalten@gmail.com> - 2011-05-26 14:09 -0700
        Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-26 15:07 -0700
        Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-05-27 07:42 +0000
        Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-05-27 07:30 -0400
      Re: C programming in 2011 Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-29 01:15 +0300
        Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-05-28 22:24 +0000
          Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-28 16:08 -0700
            Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-05-28 23:47 +0000
              Re: C programming in 2011 Geoff <geoff@invalid.invalid> - 2011-05-28 16:58 -0700
                Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-28 18:49 -0700
                  Re: C programming in 2011 Pierre Habouzit <madcoder@debian.org> - 2011-05-29 11:13 +0000
                    Re: C programming in 2011 Jorge <jorge@jorgechamorro.com> - 2011-06-04 08:05 -0700
                      Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-04 16:20 +0000
                  Re: C programming in 2011 Nizumzen <chicken@mcnuggets.com> - 2011-05-29 14:35 +0100
                    Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-29 12:49 -0700
                      OT: Brackets, parentheses, etc. (Was: C programming in 2011) Shao Miller <sha0.miller@gmail.com> - 2011-05-29 16:13 -0500
                        Re: OT: Brackets, parentheses, etc. (Was: C programming in 2011) "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-05-30 12:17 -0400
                          Re: OT: Brackets, parentheses, etc. (Was: C programming in 2011) Shao Miller <sha0.miller@gmail.com> - 2011-05-30 12:52 -0500
                      Re: C programming in 2011 Nizumzen <chicken@mcnuggets.com> - 2011-05-29 23:58 +0100
                        Re: C programming in 2011 Chris H <chris@phaedsys.org> - 2011-05-30 14:42 +0100
                          Re: C programming in 2011 Nizumzen <chicken@mcnuggets.com> - 2011-05-30 17:40 +0100
                          Re: C programming in 2011 Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2011-05-30 22:38 +0200
                      Re: C programming in 2011 "J. J. Farrell" <jjf@bcs.org.uk> - 2011-05-30 00:38 +0100
                      Re: C programming in 2011 Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-30 11:14 +0300
                Re: C programming in 2011 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-29 06:55 -0700
              Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-28 18:47 -0700
                Re: C programming in 2011 Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-30 15:02 +0300
          Re: C programming in 2011 Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-30 11:01 +0300
            Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-05-30 08:51 +0000
              Re: C programming in 2011 Nobody <nobody@nowhere.com> - 2011-05-31 01:54 +0100
                Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-05-31 12:00 +0000
                  Re: C programming in 2011 Seebs <usenet-nospam@seebs.net> - 2011-05-31 16:44 +0000
                    Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-31 11:43 -0700
    Re: C programming in 2011 Chris H <chris@phaedsys.org> - 2011-05-26 11:13 +0100
    Re: C programming in 2011 Francois Grieu <fgrieu@gmail.com> - 2011-05-26 16:04 +0200
      Re: C programming in 2011 Branimir Maksimovic <bmaxa@hotmail.com> - 2011-05-26 16:21 +0200
        Re: C programming in 2011 Francois Grieu <fgrieu@gmail.com> - 2011-05-26 17:23 +0200
          Re: C programming in 2011 Branimir Maksimovic <bmaxa@hotmail.com> - 2011-05-26 19:15 +0200
            Re: C programming in 2011 Willem <willem@toad.stack.nl> - 2011-05-26 17:29 +0000
              Re: C programming in 2011 Branimir Maksimovic <bmaxa@hotmail.com> - 2011-05-26 20:10 +0200
            Re: C programming in 2011 Pierre Habouzit <madcoder@debian.org> - 2011-05-26 17:35 +0000
              Re: C programming in 2011 Willem <willem@toad.stack.nl> - 2011-05-26 17:53 +0000
                Re: C programming in 2011 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-26 11:13 -0700
                  Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-05-26 21:57 -0400
                    Re: C programming in 2011 Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-31 01:13 -0700
              Re: C programming in 2011 Branimir Maksimovic <bmaxa@hotmail.com> - 2011-05-26 20:06 +0200
            Re: C programming in 2011 Ralf Damaschke <rwspam@gmx.de> - 2011-05-26 17:57 +0000
              Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-26 11:31 -0700
                Re: C programming in 2011 Ralf Damaschke <rwspam@gmx.de> - 2011-05-26 20:43 +0000
                  Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-26 14:53 -0700
          Re: C programming in 2011 Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-31 01:03 -0700
            Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-31 01:59 -0700
              Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-31 02:55 -0700
                Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-05-31 06:36 -0400
                  Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-31 05:57 -0700
                    Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-05-31 09:23 -0400
                      Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-31 07:50 -0700
                        Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-31 11:41 -0700
                          Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 01:46 -0700
                            Re: C programming in 2011 Ike Naar <ike@iceland.freeshell.org> - 2011-06-01 10:07 +0000
                              Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 04:12 -0700
                                Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 07:46 -0700
                                Re: C programming in 2011 Seebs <usenet-nospam@seebs.net> - 2011-06-01 17:53 +0000
                                Re: C programming in 2011 lawrence.jones@siemens.com - 2011-06-01 16:28 -0400
                                  Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 23:28 -0700
                                  Re: C programming in 2011 Uno <Uno@example.invalid> - 2011-06-09 21:24 -0600
                            Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-01 10:04 -0400
                              Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 08:21 -0700
                                Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 09:37 -0700
                                  Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-01 12:55 -0400
                                    Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 11:52 -0700
                                      Re: C programming in 2011 "J. J. Farrell" <jjf@bcs.org.uk> - 2011-06-02 00:00 +0100
                                        Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 23:19 -0700
                                Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-01 12:53 -0400
                                  Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 11:55 -0700
                              Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-01 08:41 -0700
                            Re: C programming in 2011 Noob <root@127.0.0.1> - 2011-06-01 17:12 +0200
                              Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 09:28 -0700
                            Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-01 08:38 -0700
                              Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-02 01:00 -0700
                                Re: C programming in 2011 Willem <willem@toad.stack.nl> - 2011-06-02 09:13 +0000
                                  Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-02 02:52 -0700
                                    Re: C programming in 2011 Willem <willem@toad.stack.nl> - 2011-06-02 11:41 +0000
                                      Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-02 05:53 -0700
                                        Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-02 06:49 -0700
                                          Re: C programming in 2011 Willem <willem@toad.stack.nl> - 2011-06-02 14:18 +0000
                                          Re: C programming in 2011 Seebs <usenet-nospam@seebs.net> - 2011-06-02 21:02 +0000
                                            Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-02 23:55 -0700
                                              Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-03 08:37 +0000
                                                Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-03 06:49 -0400
                                                  Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-03 11:52 +0000
                                              Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-03 11:11 -0700
                                                Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-03 18:23 +0000
                                                  Re: C programming in 2011 Seebs <usenet-nospam@seebs.net> - 2011-06-03 18:59 +0000
                                                    Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-03 19:48 +0000
                                                      Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-03 15:02 -0700
                                                Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-03 12:19 -0700
                                                  Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-03 13:40 -0700
                                                    Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-03 15:11 -0700
                                                      Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-03 15:24 -0700
                                                        Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-03 15:34 -0700
                                                          Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-03 17:10 -0700
                                                            Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-03 17:34 -0700
                                                        Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-04 09:47 -0400
                                        Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-02 10:02 -0400
                                    Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-02 12:17 +0000
                                Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-02 08:48 -0700
                                  Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-02 10:35 -0700
                                Re: C programming in 2011 gordonb.jpem8@burditt.org (Gordon Burditt) - 2011-06-05 23:32 -0500
                                  Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-06 00:12 -0700
                                    Re: C programming in 2011 gordonb.5k8u2@burditt.org (Gordon Burditt) - 2011-06-06 05:18 -0500
                                      Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-06 08:16 -0700
                            Re: C programming in 2011 Michael Press <rubrum@pacbell.net> - 2011-06-03 18:06 -0700
                            Re: C programming in 2011 gordonb.zourz@burditt.org (Gordon Burditt) - 2011-06-05 21:25 -0500
                              Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-06 01:14 -0700
                                Re: C programming in 2011 gordonb.donaz@burditt.org (Gordon Burditt) - 2011-06-06 04:36 -0500
                                  Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-06 09:02 -0700
                                    Re: C programming in 2011 gordonb.k6ruq@burditt.org (Gordon Burditt) - 2011-06-06 18:36 -0500
                                      Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-07 10:14 -0700
                        Re: C programming in 2011 "J. J. Farrell" <jjf@bcs.org.uk> - 2011-05-31 19:56 +0100
                          Re: C programming in 2011 Noob <root@127.0.0.1> - 2011-06-01 14:54 +0200
                            Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-01 13:07 +0000
                            Re: C programming in 2011 pete <pfiland@mindspring.com> - 2011-06-01 14:10 -0400
                              Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-01 19:58 -0400
                        Re: C programming in 2011 Willem <willem@toad.stack.nl> - 2011-06-01 09:07 +0000
                        Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-01 09:29 -0400
                        Re: C programming in 2011 David Thompson <dave.thompson2@verizon.net> - 2011-06-07 02:18 -0400
                          Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-07 09:31 -0700
                            Re: C programming in 2011 Patrick Scheible <kkt@zipcon.net> - 2011-06-09 14:55 -0700
                Re: C programming in 2011 Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-01 02:35 -0700
            Re: C programming in 2011 Francois Grieu <fgrieu@gmail.com> - 2011-05-31 21:57 +0200
              Re: C programming in 2011 Francois Grieu <fgrieu@gmail.com> - 2011-05-31 22:03 +0200
    Re: C programming in 2011 Kenneth Brody <kenbrody@spamcop.net> - 2011-05-26 12:27 -0400
    Re: C programming in 2011 Nobody <nobody@nowhere.com> - 2011-05-26 18:02 +0100

Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8  Next page →

#5090

James Kuyper <jameskuyper@verizon.net> writes:

> On 05/26/2011 02:13 PM, Malcolm McLean wrote:
>> On May 26, 8:53 pm, Willem <wil...@toad.stack.nl> wrote:
> ...
>>> Are you sure ?  As far as I know, casting a signed integer to unsigned
>>> is defined for negative numbers as being INT_MAX minus that number.
>>>
>> Plus one.
>> Invert and increment to negate, in twos complememnt
>
> That's UINT_MAX, not INT_MAX. And it's true whether or not 'int' is a
> 2's complement type; the rule is simply easier to implement in 2's
> complement.

Amusing that there were two levels of correction and
the result still isn't right.

[toc] | [prev] | [next] | [standalone]

#4813

On 26 May 2011 17:35:20 GMT
Pierre Habouzit <madcoder@debian.org> wrote:

> On 2011-05-26, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
> > On Thu, 26 May 2011 17:23:01 +0200
> > Francois Grieu <fgrieu@gmail.com> wrote:
> >
> >> On 26/05/2011 16:21, Branimir Maksimovic wrote:
> >> > On 05/26/2011 04:04 PM, Francois Grieu wrote:
> >> >> [3] some compilers know that, when j is an int,
> >> >> if (j<1 || j>8)
> >> >>     foo();
> >> >> can be rewritten as
> >> >>     if ((unsigned)j-1u>7u)
> >> >>         foo();
> >> >
> >> > No, it can't.
> >> 
> >> Would you please illustrate by an example when that does not stand?
> >
> > When j is in range [-8 , 0]
> 
> C99 doesn't assure you both are equivalent. I think what Francois
> tries to say is that gcc can produce assembly that will do the same as
> 
>     if ((unsigned)j - 1u > 7u)
> 
> and that's indeed what GCC does, since on the architectures GCC
> targets with the implementation choices it makes, both are equivalent.

Yes, indeed that is what gcc does ;).
I simply didn't imagine that casting -1 to unsigned *is not* 1 ;)


-- 
drwx------ 2 bmaxa bmaxa 4096 2011-05-26 20:02 .

[toc] | [prev] | [next] | [standalone]

#4811

Branimir Maksimovic <bmaxa@hotmail.com> wrote:

> On Thu, 26 May 2011 17:23:01 +0200
> Francois Grieu <fgrieu@gmail.com> wrote:
> 
>> On 26/05/2011 16:21, Branimir Maksimovic wrote:
>> > On 05/26/2011 04:04 PM, Francois Grieu wrote:
>> >> [3] some compilers know that, when j is an int,
>> >> if (j<1 || j>8)
>> >>     foo();
>> >> can be rewritten as
>> >>     if ((unsigned)j-1u>7u)
>> >>         foo();
>> >
>> > No, it can't.
>> 
>> Would you please illustrate by an example when that does not
>> stand? 
> 
> When j is in range [-8 , 0]
> 
> Actually: if(j < -8 || j > 8)
> can be rewritten as: if((unsigned)j>8)

Actually not! Consider, say, j = -1. Your first if statement
takes the else-part, your second the then-part - always.

You had had a quarter point when you had argued that the
precision of unsigned might not be larger than that of int.
But:

1: the compiler would know that and not internally rewrite the
expression the way Francis mentioned (for *some* compilers).

2: the vast majority of compilers (if not all, at least all I
know of) have a greater precision for unsigned than for int.

-- Ralf

[toc] | [prev] | [next] | [standalone]

#4819

Ralf Damaschke <rwspam@gmx.de> writes:
[...]
> 2: the vast majority of compilers (if not all, at least all I
> know of) have a greater precision for unsigned than for int.

Depends on what you mean by "precision".  For most compilers, signed int
and unsigned int can represent exactly the same number of values.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#4840

Keith Thompson <kst-u@mib.org> wrote:

> Ralf Damaschke <rwspam@gmx.de> writes:
> [...]
>> 2: the vast majority of compilers (if not all, at least all I
>> know of) have a greater precision for unsigned than for int.
> 
> Depends on what you mean by "precision".

Of course I use the term as defined:

C99, 6.2.6.2p6:
| The /precision/ of an integer type is the number of bits it
| uses to represent values, excluding any sign and padding bits.

> For most compilers,
> signed int and unsigned int can represent exactly the same
> number of values. 

D'accord, and that's implies that unsigned has a larger precision
than signed.

-- Ralf

[toc] | [prev] | [next] | [standalone]

#4846

Ralf Damaschke <rwspam@gmx.de> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>> Ralf Damaschke <rwspam@gmx.de> writes:
>> [...]
>>> 2: the vast majority of compilers (if not all, at least all I
>>> know of) have a greater precision for unsigned than for int.
>> 
>> Depends on what you mean by "precision".
>
> Of course I use the term as defined:
>
> C99, 6.2.6.2p6:
> | The /precision/ of an integer type is the number of bits it
> | uses to represent values, excluding any sign and padding bits.
>
>> For most compilers,
>> signed int and unsigned int can represent exactly the same
>> number of values. 
>
> D'accord, and that's implies that unsigned has a larger precision
> than signed.

Ah, I forgot that the standard defines the term "precision" for
integer types.  (It's possible for signed and unsigned to have the
same precision, but only if unsigned has a padding bit in places
of signed's sign bit, which woudl be unusual.)

Note that the standard also defines the "width" as the "precision"
plus any sign bit.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#5089

Francois Grieu <fgrieu@gmail.com> writes:

> On 26/05/2011 16:21, Branimir Maksimovic wrote:
>> On 05/26/2011 04:04 PM, Francois Grieu wrote:
>>> [3] some compilers know that, when j is an int,
>>> if (j<1 || j>8)
>>>     foo();
>>> can be rewritten as
>>>     if ((unsigned)j-1u>7u)
>>>         foo();
>>
>> No, it can't.
>
> Would you please illustrate by an example when that does not stand?
> Stick to C99, please.

On most implementations it will work, but it can fail if
UINT_MAX == INT_MAX.  Of course an implementation is
allowed to know that and take it into account.

[toc] | [prev] | [next] | [standalone]

#5093

On May 31, 10:03 am, Tim Rentsch <t...@alumni.caltech.edu> wrote:
> Francois Grieu <fgr...@gmail.com> writes:
> > On 26/05/2011 16:21, Branimir Maksimovic wrote:
> >> On 05/26/2011 04:04 PM, Francois Grieu wrote:
> >>> [3] some compilers know that, when j is an int,
> >>> if (j<1 || j>8)
> >>>     foo();
> >>> can be rewritten as
> >>>     if ((unsigned)j-1u>7u)
> >>>         foo();
>
> >> No, it can't.
>
> > Would you please illustrate by an example when that does not stand?
> > Stick to C99, please.
>
> On most implementations it will work, but it can fail if
> UINT_MAX == INT_MAX.  Of course an implementation is
> allowed to know that and take it into account.

I've been scratching my head for a bit, reading the above. In any
numbersystem i can come up with it seems that UINT_MAX > INT_MAX, if
only because of the sign bit required in integers.

So please, which situation did you have in mind where UINT_MAX ==
INT_MAX? The only one i can think of is a very silly definition in one
of the standard headers, making me want to give strong advice not to
use that a compiler. God knows what other silliness is hidden in the
headers.

[toc] | [prev] | [next] | [standalone]

#5096

On May 31, 11:30 am, Tim Rentsch <t...@alumni.caltech.edu> wrote:
> "Kleuskes & Moos" <kleu...@xs4all.nl> writes:
>
>
>
>
>
>
>
>
>
> > On May 31, 10:03 am, Tim Rentsch <t...@alumni.caltech.edu> wrote:
> >> Francois Grieu <fgr...@gmail.com> writes:
> >> > On 26/05/2011 16:21, Branimir Maksimovic wrote:
> >> >> On 05/26/2011 04:04 PM, Francois Grieu wrote:
> >> >>> [3] some compilers know that, when j is an int,
> >> >>> if (j<1 || j>8)
> >> >>>     foo();
> >> >>> can be rewritten as
> >> >>>     if ((unsigned)j-1u>7u)
> >> >>>         foo();
>
> >> >> No, it can't.
>
> >> > Would you please illustrate by an example when that does not stand?
> >> > Stick to C99, please.
>
> >> On most implementations it will work, but it can fail if
> >> UINT_MAX == INT_MAX.  Of course an implementation is
> >> allowed to know that and take it into account.
>
> > I've been scratching my head for a bit, reading the above. In any
> > numbersystem i can come up with it seems that UINT_MAX > INT_MAX, if
> > only because of the sign bit required in integers.
>
> > So please, which situation did you have in mind where UINT_MAX ==
> > INT_MAX? The only one i can think of is a very silly definition in one
> > of the standard headers, making me want to give strong advice not to
> > use that a compiler. God knows what other silliness is hidden in the
> > headers.
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
>
> Please refer to section 6.2.6.2, paragraph 2.

Nice to know that you know where integers are defined in the standard,
but that does not really answer my question. Much in contrast, from
what i read, it seems to validate my view, so please expound.

The chapter you mention endorses (explicitly) ones- and twos
complement, both of which obey the relation defined above, both for
the simple reason the need a (explicitly defined and demanded in the
chapter you mention) sign-bit.

[toc] | [prev] | [next] | [standalone]

#5097

On 05/31/2011 05:55 AM, Kleuskes & Moos wrote:
> On May 31, 11:30�am, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>> "Kleuskes & Moos" <kleu...@xs4all.nl> writes:
...
>>> I've been scratching my head for a bit, reading the above. In any
>>> numbersystem i can come up with it seems that UINT_MAX > INT_MAX, if
>>> only because of the sign bit required in integers.

The closest the standard comes to directly constraining UINT_MAX
relative to INT_MAX is in 6.2.5p9: "The range of nonnegative values of a
signed integer type is a subrange of the corresponding unsigned integer
type, ...". That corresponds to the constraint UINT_MAX >= INT_MAX; it
is not violated by UINT_MAX==INT_MAX.

>>> So please, which situation did you have in mind where UINT_MAX ==
>>> INT_MAX? The only one i can think of is a very silly definition in one
>>> of the standard headers, making me want to give strong advice not to
>>> use that a compiler. God knows what other silliness is hidden in the
>>> headers.
>>
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
>>
>> Please refer to section 6.2.6.2, paragraph 2.
> 
> Nice to know that you know where integers are defined in the standard,
> but that does not really answer my question. Much in contrast, from
> what i read, it seems to validate my view, so please expound.
> 
> The chapter you mention endorses (explicitly) ones- and twos
> complement, ...

You've forgotten sign-and-magnitude, which is also explicitly permitted.

... both of which obey the relation defined above, both for
> the simple reason the need a (explicitly defined and demanded in the
> chapter you mention) sign-bit.

Actually, the relevant issue is 6.2.6.2p1, which specifies that unsigned
types can have padding bits. In particular, the bit which serves as a
sign bit for the corresponding signed type could be a padding bit for
the unsigned type.
This does not apply to those unsigned types which are prohibited from
having padding bits: unsigned char and the exact-sized types from
<stdint.h>, but unsigned int is allowed to have padding bits.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#5102

On May 31, 12:36 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> On 05/31/2011 05:55 AM, Kleuskes & Moos wrote:
>
> > On May 31, 11:30 am, Tim Rentsch <t...@alumni.caltech.edu> wrote:
> >> "Kleuskes & Moos" <kleu...@xs4all.nl> writes:
> ...
> >>> I've been scratching my head for a bit, reading the above. In any
> >>> numbersystem i can come up with it seems that UINT_MAX > INT_MAX, if
> >>> only because of the sign bit required in integers.
>
> The closest the standard comes to directly constraining UINT_MAX
> relative to INT_MAX is in 6.2.5p9: "The range of nonnegative values of a
> signed integer type is a subrange of the corresponding unsigned integer
> type, ...". That corresponds to the constraint UINT_MAX >= INT_MAX; it
> is not violated by UINT_MAX==INT_MAX.

True. But then there's "not violating a constraint" and there's sheer,
unadulterated sillyness of actually creating an implementation in
which UINT_MAX==INT_MAX, since you would be throwing away half the
range of the unsigned integer (and that goes in all three mandated
numbersystems).

So while it may not violate the standard, it _is_ silly, and i would
very much like to know which compiler meets UINT_MAX==INT_MAX. Just so
that i can avoid it.

> >>> So please, which situation did you have in mind where UINT_MAX ==
> >>> INT_MAX? The only one i can think of is a very silly definition in one
> >>> of the standard headers, making me want to give strong advice not to
> >>> use that a compiler. God knows what other silliness is hidden in the
> >>> headers.
>
> >>http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
>
> >> Please refer to section 6.2.6.2, paragraph 2.
>
> > Nice to know that you know where integers are defined in the standard,
> > but that does not really answer my question. Much in contrast, from
> > what i read, it seems to validate my view, so please expound.
>
> > The chapter you mention endorses (explicitly) ones- and twos
> > complement, ...
>
> You've forgotten sign-and-magnitude, which is also explicitly permitted.

Yes. I omitted that one. But that changes nothing.

> ... both of which obey the relation defined above, both for
>
> > the simple reason the need a (explicitly defined and demanded in the
> > chapter you mention) sign-bit.
>
> Actually, the relevant issue is 6.2.6.2p1, which specifies that unsigned
> types can have padding bits. In particular, the bit which serves as a
> sign bit for the corresponding signed type could be a padding bit for
> the unsigned type.

Hmmm... For the reason mentioned above, that would be silly and i
suspect the padding has more to do with varying register sizes, the
occasional need to stuff a short int into a 32 bit register and
aligning arrays on word-boundaries.

> This does not apply to those unsigned types which are prohibited from
> having padding bits: unsigned char and the exact-sized types from
> <stdint.h>, but unsigned int is allowed to have padding bits.

True. And having these padding bits serves what purpose in your
opinion? IFAIK the standards guys do nothing without a proper
rationale.

[toc] | [prev] | [next] | [standalone]

#5105

On 05/31/2011 08:57 AM, Kleuskes & Moos wrote:
> On May 31, 12:36�pm, James Kuyper <jameskuy...@verizon.net> wrote:
...
>> The closest the standard comes to directly constraining UINT_MAX
>> relative to INT_MAX is in 6.2.5p9: "The range of nonnegative values of a
>> signed integer type is a subrange of the corresponding unsigned integer
>> type, ...". That corresponds to the constraint UINT_MAX >= INT_MAX; it
>> is not violated by UINT_MAX==INT_MAX.
> 
> True. But then there's "not violating a constraint" and there's sheer,
> unadulterated sillyness of actually creating an implementation in
> which UINT_MAX==INT_MAX, since you would be throwing away half the
> range of the unsigned integer (and that goes in all three mandated
> numbersystems).
> 
> So while it may not violate the standard, it _is_ silly, and i would
> very much like to know which compiler meets UINT_MAX==INT_MAX. Just so
> that i can avoid it.

There have been implementations which used the floating point processor
to implement an integer type (probably 'long int'), essentially by using
only mantissa bits, leaving the exponent bits completely unused.
Compared with that, throwing away only half of the potentially
representable range seems pretty minor.

...
>> This does not apply to those unsigned types which are prohibited from
>> having padding bits: unsigned char and the exact-sized types from
>> <stdint.h>, but unsigned int is allowed to have padding bits.
> 
> True. And having these padding bits serves what purpose in your
> opinion? IFAIK the standards guys do nothing without a proper
> rationale.

An obvious possibility is a platform with no hardware support for
unsigned integers - depending upon the precise details of it's
instruction set, it could be easiest to implement unsigned ints as
signed ints with a range restricted to non-negative values. However, I
claim no familiarity with any such system.

I gather that padding bits were allowed because not allowing them would
make creation of a conforming implementation of C more difficult on some
platforms. The wording that describes padding bits was probably more
general than was needed to address the specific platforms the committee
was aware of, but I'm sure they were also concerned about possible
future platforms, and did not desire to unnecessarily constrain the
implementability of C. While they may be obscure platforms, the general
attitude of the C committee seems to be that C should be implementable
almost everywhere, even obscure platforms.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#5112

On May 31, 3:23 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> On 05/31/2011 08:57 AM, Kleuskes & Moos wrote:
>
>
>
>
>
>
>
>
>
> > On May 31, 12:36 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> ...
> >> The closest the standard comes to directly constraining UINT_MAX
> >> relative to INT_MAX is in 6.2.5p9: "The range of nonnegative values of a
> >> signed integer type is a subrange of the corresponding unsigned integer
> >> type, ...". That corresponds to the constraint UINT_MAX >= INT_MAX; it
> >> is not violated by UINT_MAX==INT_MAX.
>
> > True. But then there's "not violating a constraint" and there's sheer,
> > unadulterated sillyness of actually creating an implementation in
> > which UINT_MAX==INT_MAX, since you would be throwing away half the
> > range of the unsigned integer (and that goes in all three mandated
> > numbersystems).
>
> > So while it may not violate the standard, it _is_ silly, and i would
> > very much like to know which compiler meets UINT_MAX==INT_MAX. Just so
> > that i can avoid it.
>
> There have been implementations which used the floating point processor
> to implement an integer type (probably 'long int'), essentially by using
> only mantissa bits, leaving the exponent bits completely unused.
> Compared with that, throwing away only half of the potentially
> representable range seems pretty minor.

Providing an example of even greatr sillyness, does not prove throwing
away half the range to be any less silly than it was before.


> >> This does not apply to those unsigned types which are prohibited from
> >> having padding bits: unsigned char and the exact-sized types from
> >> <stdint.h>, but unsigned int is allowed to have padding bits.
>
> > True. And having these padding bits serves what purpose in your
> > opinion? IFAIK the standards guys do nothing without a proper
> > rationale.
>
> An obvious possibility is a platform with no hardware support for
> unsigned integers - depending upon the precise details of it's
> instruction set, it could be easiest to implement unsigned ints as
> signed ints with a range restricted to non-negative values. However, I
> claim no familiarity with any such system.

Such a system would not be able to operate, since every relative jmp-
instruction involves the addition (or subtraction, which is basically
the same). So name that fabled platform.

> I gather that padding bits were allowed because not allowing them would
> make creation of a conforming implementation of C more difficult on some
> platforms. The wording that describes padding bits was probably more
> general than was needed to address the specific platforms the committee
> was aware of, but I'm sure they were also concerned about possible
> future platforms, and did not desire to unnecessarily constrain the
> implementability of C. While they may be obscure platforms, the general
> attitude of the C committee seems to be that C should be implementable
> almost everywhere, even obscure platforms.

Not so obscure that unsigned integers are not supported, after all,
every physical and logical memory address is, basically, an unsigned
integer.

So, noting the absence of any argument otherwise, UINT_MAX==INT_MAX is
only possible theoretically, but the chances of actually running into
it are virtually nonexistent, that is, somewhere between "highly
unlikely" and "absolute zero". In practice UINT_MAX > INT_MAX, and i
dare you to show me an example to the contrary.

[toc] | [prev] | [next] | [standalone]

#5134

"Kleuskes & Moos" <kleuske@xs4all.nl> writes:
> On May 31, 3:23 pm, James Kuyper <jameskuy...@verizon.net> wrote:
>> On 05/31/2011 08:57 AM, Kleuskes & Moos wrote:
>> > On May 31, 12:36 pm, James Kuyper <jameskuy...@verizon.net> wrote:
>> ...
>> >> The closest the standard comes to directly constraining UINT_MAX
>> >> relative to INT_MAX is in 6.2.5p9: "The range of nonnegative values of a
>> >> signed integer type is a subrange of the corresponding unsigned integer
>> >> type, ...". That corresponds to the constraint UINT_MAX >= INT_MAX; it
>> >> is not violated by UINT_MAX==INT_MAX.
>>
>> > True. But then there's "not violating a constraint" and there's sheer,
>> > unadulterated sillyness of actually creating an implementation in
>> > which UINT_MAX==INT_MAX, since you would be throwing away half the
>> > range of the unsigned integer (and that goes in all three mandated
>> > numbersystems).
>>
>> > So while it may not violate the standard, it _is_ silly, and i would
>> > very much like to know which compiler meets UINT_MAX==INT_MAX. Just so
>> > that i can avoid it.
[...]
>> An obvious possibility is a platform with no hardware support for
>> unsigned integers - depending upon the precise details of it's
>> instruction set, it could be easiest to implement unsigned ints as
>> signed ints with a range restricted to non-negative values. However, I
>> claim no familiarity with any such system.
>
> Such a system would not be able to operate, since every relative jmp-
> instruction involves the addition (or subtraction, which is basically
> the same). So name that fabled platform.

How do you know what's involved in relative jump instructions on a
hypothetical system that might not even exist?

>> I gather that padding bits were allowed because not allowing them would
>> make creation of a conforming implementation of C more difficult on some
>> platforms. The wording that describes padding bits was probably more
>> general than was needed to address the specific platforms the committee
>> was aware of, but I'm sure they were also concerned about possible
>> future platforms, and did not desire to unnecessarily constrain the
>> implementability of C. While they may be obscure platforms, the general
>> attitude of the C committee seems to be that C should be implementable
>> almost everywhere, even obscure platforms.
>
> Not so obscure that unsigned integers are not supported, after all,
> every physical and logical memory address is, basically, an unsigned
> integer.

On some systems, yes.  On the hypothetical system in question, it's
likely that physical and logical memory addresses are represented as
signed integers.  For example, if it's a 32-bit system, addresses might
range from -2147483648 to +2147483647.

> So, noting the absence of any argument otherwise, UINT_MAX==INT_MAX is
> only possible theoretically, but the chances of actually running into
> it are virtually nonexistent, that is, somewhere between "highly
> unlikely" and "absolute zero". In practice UINT_MAX > INT_MAX, and i
> dare you to show me an example to the contrary.

I do not claim that such an example exists, but it *could*.  Perhaps it
could be a specialized system, not primarily designed with C in mind,
but intended to support an environment which has no need for unsigned
arithmetic (and no, address calculations don't *necessarily* require
unsigned integer arithmetic).

On such a system, it would make sense to have:
    INT_MIN = -2147483648
    INT_MAX = +2147483647
    UINT_MAX = INT_MAX
and for unsigned int to have a single padding bit in place of
signed int's sign bit.  And that would probably result in much more
efficient code than forcing unsigned int to have 32 value bits and
perform most unsigned operations in software.  (Perhaps unsigned long
would be 32 bits wide, and be slower than unsigned int.)

The point is that C is designed to be implementable with reasonable
efficiency on a wide variety of systems.

There are more things in heaven and earth, Horatio, ...

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#5163

On May 31, 8:41 pm, Keith Thompson <ks...@mib.org> wrote:
> "Kleuskes & Moos" <kleu...@xs4all.nl> writes:
> > On May 31, 3:23 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> >> On 05/31/2011 08:57 AM, Kleuskes & Moos wrote:
> >> > On May 31, 12:36 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> >> ...
> >> >> The closest the standard comes to directly constraining UINT_MAX
> >> >> relative to INT_MAX is in 6.2.5p9: "The range of nonnegative values of a
> >> >> signed integer type is a subrange of the corresponding unsigned integer
> >> >> type, ...". That corresponds to the constraint UINT_MAX >= INT_MAX; it
> >> >> is not violated by UINT_MAX==INT_MAX.
>
> >> > True. But then there's "not violating a constraint" and there's sheer,
> >> > unadulterated sillyness of actually creating an implementation in
> >> > which UINT_MAX==INT_MAX, since you would be throwing away half the
> >> > range of the unsigned integer (and that goes in all three mandated
> >> > numbersystems).
>
> >> > So while it may not violate the standard, it _is_ silly, and i would
> >> > very much like to know which compiler meets UINT_MAX==INT_MAX. Just so
> >> > that i can avoid it.
> [...]
> >> An obvious possibility is a platform with no hardware support for
> >> unsigned integers - depending upon the precise details of it's
> >> instruction set, it could be easiest to implement unsigned ints as
> >> signed ints with a range restricted to non-negative values. However, I
> >> claim no familiarity with any such system.
>
> > Such a system would not be able to operate, since every relative jmp-
> > instruction involves the addition (or subtraction, which is basically
> > the same). So name that fabled platform.
>
> How do you know what's involved in relative jump instructions on a
> hypothetical system that might not even exist?

What other methods of doing relative jumps did you have in mind? Since
you think there's an alternative, it's up to you to name it.


<snip>

> > Not so obscure that unsigned integers are not supported, after all,
> > every physical and logical memory address is, basically, an unsigned
> > integer.
>
> On some systems, yes.  On the hypothetical system in question, it's
> likely that physical and logical memory addresses are represented as
> signed integers.  For example, if it's a 32-bit system, addresses might
> range from -2147483648 to +2147483647.

Ah. Another hypothetical system that defies the laws of common
sense... Great, what advantages does your hypothetical system with
signed memory addresses have? More importantly, how does that jive
with the electronics of the address-bus of that hypothetical system?

Objections concerning some hypothetical system which uses signed
integers as memory addresses and do not support nsigned integers are
not quite taken seriously on my side of the NNTP-server. Why not
invent a hypothetical system which uses pink bunnies to address
memory?

> > So, noting the absence of any argument otherwise, UINT_MAX==INT_MAX is
> > only possible theoretically, but the chances of actually running into
> > it are virtually nonexistent, that is, somewhere between "highly
> > unlikely" and "absolute zero". In practice UINT_MAX > INT_MAX, and i
> > dare you to show me an example to the contrary.
>
> I do not claim that such an example exists, but it *could*.

Yes. And the chip-select signal might be delivered by invisible pink
unicorns, the Carry Flag might be hoisted by Daffy Duck and interrupts
might be implemented by Yosemity Sam, firing his guns at the hootenest-
tootenest-shootenest programmable interrupt controller north, east,
south AAAAND west of the Pecos.

To me, the flurry of hypotheticals merely indicates that i was right,
but you don't like admitting it, so you're grasping at hypothetical
straws.

> Perhaps it could be a specialized system, not primarily designed with C
> in mind, but intended to support an environment which has no need for
> unsigned arithmetic (and no, address calculations don't *necessarily*
> require unsigned integer arithmetic).

Ok. So name a (non-hypothetical) example of adddresses not being
unsigned integers. I wager a case of Grolsch you won't be able to. Not
because it's not possible, just because it's unpractical.

Besides, a pattern of bits on the address bus, and this would be the
best objection you can make, can be interpreted as signed _or_
unsigned at the whim of whomsoever is interpreting it. It really makes
no difference, it's just a question of how you interpret them.

But, given the practicalities of hardware design, they are usually
interpreted as being unsigned, simply because it's more convenient.

> On such a system, it would make sense to have:
>     INT_MIN = -2147483648
>     INT_MAX = +2147483647
>     UINT_MAX = INT_MAX
> and for unsigned int to have a single padding bit in place of
> signed int's sign bit.  And that would probably result in much more
> efficient code than forcing unsigned int to have 32 value bits and
> perform most unsigned operations in software.  (Perhaps unsigned long
> would be 32 bits wide, and be slower than unsigned int.)

Ok.

Let me pose two simple questions...

How does a CPU add 1 and 1 and arrive at the (correct) answer: 2?
How do signed and unsigned versions of this operation differ?

The question "why doesn't anyone design a computer that does not
support unsigned arithmatic" should be obvious, if you got the above
two questions right, and hypothetical, highly unpractical systems
should then be laid to rest.

> The point is that C is designed to be implementable with reasonable
> efficiency on a wide variety of systems.

True. But i doubt you'll find ANY that match the exotic, nay,
excentric hardware you describe. I still dare yoou to name a single
CPU that does not support unsigned integers, and i'm very confident
you won't find any.

> There are more things in heaven and earth, Horatio, ...

True. But that's no argument.

[toc] | [prev] | [next] | [standalone]

#5169

On 2011-06-01, Kleuskes & Moos <kleuske@xs4all.nl> wrote:
> Ah. Another hypothetical system that defies the laws of common
> sense... Great, what advantages does your hypothetical system with
> signed memory addresses have? More importantly, how does that jive
> with the electronics of the address-bus of that hypothetical system?
>
> Objections concerning some hypothetical system which uses signed
> integers as memory addresses and do not support nsigned integers are
> not quite taken seriously on my side of the NNTP-server. Why not
> invent a hypothetical system which uses pink bunnies to address
> memory?

http://en.wikipedia.org/wiki/Burroughs_large_systems describres
a family of non-hypothetical systems that used sign-and magnitude
representation for integers (integers were simply floating-point
numbers with a zero exponent). These systems existed before the
C language became popular (Algol was their main high level language),
but UINT_MAX==INT_MAX would be a logical choice for a C implementation
on such a system.

[toc] | [prev] | [next] | [standalone]

#5171

On Jun 1, 12:07 pm, Ike Naar <i...@iceland.freeshell.org> wrote:
> On 2011-06-01, Kleuskes & Moos <kleu...@xs4all.nl> wrote:
>
> > Ah. Another hypothetical system that defies the laws of common
> > sense... Great, what advantages does your hypothetical system with
> > signed memory addresses have? More importantly, how does that jive
> > with the electronics of the address-bus of that hypothetical system?
>
> > Objections concerning some hypothetical system which uses signed
> > integers as memory addresses and do not support nsigned integers are
> > not quite taken seriously on my side of the NNTP-server. Why not
> > invent a hypothetical system which uses pink bunnies to address
> > memory?
>
> http://en.wikipedia.org/wiki/Burroughs_large_systemsdescribres
> a family of non-hypothetical systems that used sign-and magnitude
> representation for integers (integers were simply floating-point
> numbers with a zero exponent). These systems existed before the
> C language became popular (Algol was their main high level language),
> but UINT_MAX==INT_MAX would be a logical choice for a C implementation
> on such a system.

Dating back from the 60's. Ok. Welcome back to the stone age.

In short: UINT_MAX==INT_MAX is only found in hypothetical and
prehistoric machines. Which still does not invalidate the point that
the situation in question is (anno domini 2011) hypothetical at best.

There is a reason, and a very good one, too, that sign-and-magnitude
isn't used anymore. If you have a different opinion, please post the
hardware in question. I'd be curious.

[toc] | [prev] | [next] | [standalone]

#5189

On Jun 1, 1:56 pm, Angel <angel+n...@spamcop.net> wrote:
> On 2011-06-01, Kleuskes & Moos <kleu...@xs4all.nl> wrote:
>
>
>
> > In short: UINT_MAX==INT_MAX is only found in hypothetical and
> > prehistoric machines. Which still does not invalidate the point that
> > the situation in question is (anno domini 2011) hypothetical at best.
>
> > There is a reason, and a very good one, too, that sign-and-magnitude
> > isn't used anymore. If you have a different opinion, please post the
> > hardware in question. I'd be curious.
>
> Regardless of what is available now, you don't know what the future
> might bring. In order to ensure maximum portability, it's best not to
> make any assumptions about the implementation unless you really have to.
>
> There is already a lot of broken software out there because programmers
> assumed 32-bit integers (even though 64-bit systems have been around
> longer than most people think), we really don't need more broken
> software because programmers make assumptions about UINT_MAX that may
> or may not be true in the future.

Blahdiblahdiblah...

First off, i'm not assuming anything, just making the point that
UINT_MAX == INT_MAX is valid in hypothetical cases only and when a
(alledged) counterexample is finally found, it turns out to be
straight out of the jurassic age and never supported C in in the first
place. Instead it ran ALGOL and (with some prodding) COBOL.

There's good programming practice, such as not assuming any type to be
of any particular size, unless dictated by the standard, and there's
the sheer sillyness portrayed in this subthread.

Of course the standards guys allow for all kinds of stuff nobody would
normally use anymore, just to suit the fringe cases, but then there's
fringe cases and there's "CPU's that don't support unsigned integers".

[toc] | [prev] | [next] | [standalone]

#5216

On 2011-06-01, Kleuskes & Moos <kleuske@xs4all.nl> wrote:
> Dating back from the 60's. Ok. Welcome back to the stone age.

Okay, key insight:

What makes sense in hardware has been known to change RADICALLY over the
course of a couple of decades.

> In short: UINT_MAX==INT_MAX is only found in hypothetical and
> prehistoric machines. Which still does not invalidate the point that
> the situation in question is (anno domini 2011) hypothetical at best.

But it does invalidate the presumed argument that it will *remain*
hypothetical and that it is reasonable to assume that it's irrelevant.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#5241

Kleuskes & Moos <kleuske@xs4all.nl> wrote:
> 
> There is a reason, and a very good one, too, that sign-and-magnitude
> isn't used anymore. If you have a different opinion, please post the
> hardware in question. I'd be curious.

Note the decimal arithmetic was dead, buried, and fossilized until IBM
resurrected it a couple years ago and it suddenly became the hotest
thing in hardware design.
-- 
Larry Jones

Archaeologists have the most mind-numbing job on the planet. -- Calvin

[toc] | [prev] | [next] | [standalone]

Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8  Next page →

Back to top | Article view | comp.lang.c

csiph-web