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

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

return -1 using size_t???

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

Contents

  return -1 using size_t??? Robert Hayes <rhyes80@gmail.com> - 2012-02-11 11:21 -0800
    Re: return -1 using size_t??? Shao Miller <sha0.miller@gmail.com> - 2012-02-11 15:00 -0500
      Re: return -1 using size_t??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-11 23:24 +0000
    Re: return -1 using size_t??? Jeffrey R <joeff@nospam.com> - 2012-02-11 19:58 +0000
      Re: return -1 using size_t??? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-11 15:11 -0500
    Re: return -1 using size_t??? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-11 15:07 -0500
      Re: return -1 using size_t??? Robert Hayes <rhyes80@gmail.com> - 2012-02-11 12:42 -0800
        Re: return -1 using size_t??? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-11 13:19 -0800
          Re: return -1 using size_t??? Keith Thompson <kst-u@mib.org> - 2012-02-11 17:10 -0800
            Re: return -1 using size_t??? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-12 03:48 -0800
              Re: return -1 using size_t??? Keith Thompson <kst-u@mib.org> - 2012-02-12 04:04 -0800
        Re: return -1 using size_t??? Jeffrey R <joeff@nospam.com> - 2012-02-11 22:25 +0000
          Re: return -1 using size_t??? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-02-11 14:36 -0800
            Re: return -1 using size_t??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-11 23:17 +0000
          Re: return -1 using size_t??? Jeroen Mostert <jmostert@xs4all.nl> - 2012-02-11 23:46 +0100
            Re: return -1 using size_t??? pete <pfiland@mindspring.com> - 2012-02-11 19:18 -0500
          Re: return -1 using size_t??? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-12 08:38 -0500
        Re: return -1 using size_t??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-11 23:32 +0000
        Re: return -1 using size_t??? pete <pfiland@mindspring.com> - 2012-02-11 19:15 -0500
      Re: return -1 using size_t??? Ralph Spitzner <rasp@spitzner.org> - 2012-02-13 13:51 +0100
    Re: return -1 using size_t??? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-02-11 12:40 -0800
      Re: return -1 using size_t??? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-11 17:02 -0500
        Re: return -1 using size_t??? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-02-11 14:11 -0800
          Re: return -1 using size_t??? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-11 17:21 -0500
            Re: return -1 using size_t??? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-02-11 14:31 -0800
              Re: return -1 using size_t??? Willem <willem@toad.stack.nl> - 2012-02-11 22:52 +0000
              Re: return -1 using size_t??? Jens Gustedt <jens.gustedt@loria.fr> - 2012-02-12 00:20 +0100
                Re: return -1 using size_t??? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-02-12 09:21 -0800
                  Re: return -1 using size_t??? Keith Thompson <kst-u@mib.org> - 2012-02-12 12:27 -0800
                    Re: return -1 using size_t??? Jeroen Mostert <jmostert@xs4all.nl> - 2012-02-12 22:17 +0100
                      Re: return -1 using size_t??? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-02-12 15:10 -0800
                        Re: return -1 using size_t??? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-13 03:11 -0800
                    Re: return -1 using size_t??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-12 23:25 +0000
                      Re: return -1 using size_t??? Jeroen Mostert <jmostert@xs4all.nl> - 2012-02-13 07:46 +0100
                      Re: return -1 using size_t??? Ike Naar <ike@sverige.freeshell.org> - 2012-02-13 10:27 +0000
                        Re: return -1 using size_t??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-13 12:36 +0000
                          Re: return -1 using size_t??? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-02-13 10:26 -0700
                          Re: return -1 using size_t??? Ike Naar <ike@iceland.freeshell.org> - 2012-02-14 00:18 +0000
                            Re: return -1 using size_t??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-14 00:29 +0000
                            Re: return -1 using size_t??? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-02-13 16:37 -0800
                      Re: return -1 using size_t??? Angel <angel+news@spamcop.net> - 2012-02-13 11:47 +0000
                        Re: return -1 using size_t??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-13 12:54 +0000
                          Re: return -1 using size_t??? Angel <angel+news@spamcop.net> - 2012-02-13 14:30 +0000
                            Re: return -1 using size_t??? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-22 01:53 +0200
                          Re: return -1 using size_t??? James Kuyper <jameskuyper@verizon.net> - 2012-02-13 12:11 -0500
                            Re: return -1 using size_t??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-13 17:28 +0000
                              Re: return -1 using size_t??? James Kuyper <jameskuyper@verizon.net> - 2012-02-13 13:08 -0500
                                Re: return -1 using size_t??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-13 23:06 +0000
                          Re: return -1 using size_t??? William Ahern <william@wilbur.25thandClement.com> - 2012-02-13 14:39 -0800
                            Re: return -1 using size_t??? Keith Thompson <kst-u@mib.org> - 2012-02-13 14:59 -0800
                  Re: return -1 using size_t??? Jens Gustedt <jens.gustedt@loria.fr> - 2012-02-12 22:17 +0100
                    Re: return -1 using size_t??? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-02-12 15:06 -0800
                      Re: return -1 using size_t??? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-12 18:12 -0500
                      Re: return -1 using size_t??? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-22 02:15 +0200
    Re: return -1 using size_t??? Barry Schwarz <schwarzb@dqel.com> - 2012-02-11 14:27 -0800
      Re: return -1 using size_t??? Keith Thompson <kst-u@mib.org> - 2012-02-11 17:34 -0800

Page 3 of 3 — ← Prev page 1 2 [3]

#17202

On 2012-02-12, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
> For those who wonder about all the oddities in the standard, here is a
> system that (a) uses EBCDIC[2]; (b) has unusual sizes and limits; (c) is
> not two's complement; (d) has padding bits in all integer types except
> the char types; (e) has trap representations in these types; and (f) has
> multiple pointer representations (so pointer casts often generate code).
> What's more it's *current*: there was recently an MCP 13.0 release with
> support into 2013.

Just out of curiosity, is there any change that this system can run
GNU/Linux?


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

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

#17210

Angel <angel+news@spamcop.net> writes:

> On 2012-02-12, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>
>> For those who wonder about all the oddities in the standard, here is a
>> system that (a) uses EBCDIC[2]; (b) has unusual sizes and limits; (c) is
>> not two's complement; (d) has padding bits in all integer types except
>> the char types; (e) has trap representations in these types; and (f) has
>> multiple pointer representations (so pointer casts often generate code).
>> What's more it's *current*: there was recently an MCP 13.0 release with
>> support into 2013.
>
> Just out of curiosity, is there any change that this system can run
> GNU/Linux?

It would surely be hard and it might be impossible, but why would you?
The only reason to use the clunky system is that you have old software
that requires this environment.

As someone pointed out, the modern versions of this architecture are
built using Intel Xeon CPUs, so if you had one of these machines and
needed GNU/Linux you'd start by throwing all the MCP emulation away.

-- 
Ben.

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

#17222

On 2012-02-13, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Angel <angel+news@spamcop.net> writes:
>
>> On 2012-02-12, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>
>>> For those who wonder about all the oddities in the standard, here is a
>>> system that (a) uses EBCDIC[2]; (b) has unusual sizes and limits; (c) is
>>> not two's complement; (d) has padding bits in all integer types except
>>> the char types; (e) has trap representations in these types; and (f) has
>>> multiple pointer representations (so pointer casts often generate code).
>>> What's more it's *current*: there was recently an MCP 13.0 release with
>>> support into 2013.
>>
>> Just out of curiosity, is there any change that this system can run
>> GNU/Linux?
>
> It would surely be hard and it might be impossible, but why would you?
> The only reason to use the clunky system is that you have old software
> that requires this environment.

I don't need reasons per se. I run Linux on old clunky stuff because I
can. :-)

> As someone pointed out, the modern versions of this architecture are
> built using Intel Xeon CPUs, so if you had one of these machines and
> needed GNU/Linux you'd start by throwing all the MCP emulation away.

That would make it just Linux on Intel. Been there, done that. :-)

Like I said, I was just curious. I've got Linux running on Intel, Sparc
and PowerPC, I'm always looking for a new challenge. :-)


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

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

#17756

Angel <angel+news@spamcop.net> writes:
> On 2012-02-13, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> > Angel <angel+news@spamcop.net> writes:
> >
> >> On 2012-02-12, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> >>>
> >>> For those who wonder about all the oddities in the standard, here is a
> >>> system that (a) uses EBCDIC[2]; (b) has unusual sizes and limits; (c) is
> >>> not two's complement; (d) has padding bits in all integer types except
> >>> the char types; (e) has trap representations in these types; and (f) has
> >>> multiple pointer representations (so pointer casts often generate code).
> >>> What's more it's *current*: there was recently an MCP 13.0 release with
> >>> support into 2013.
> >>
> >> Just out of curiosity, is there any change that this system can run
> >> GNU/Linux?
> >
> > It would surely be hard and it might be impossible, but why would you?
> > The only reason to use the clunky system is that you have old software
> > that requires this environment.
> 
> I don't need reasons per se. I run Linux on old clunky stuff because I
> can. :-)
> 
> > As someone pointed out, the modern versions of this architecture are
> > built using Intel Xeon CPUs, so if you had one of these machines and
> > needed GNU/Linux you'd start by throwing all the MCP emulation away.
> 
> That would make it just Linux on Intel. Been there, done that. :-)
> 
> Like I said, I was just curious. I've got Linux running on Intel, Sparc
> and PowerPC, I'm always looking for a new challenge. :-)

AlphaLinux needs some love and attention currently.

Phil
-- 
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

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

#17225

On 02/13/2012 07:54 AM, Ben Bacarisse wrote:
> Angel <angel+news@spamcop.net> writes:
> 
>> On 2012-02-12, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>
>>> For those who wonder about all the oddities in the standard, here is a
>>> system that (a) uses EBCDIC[2]; (b) has unusual sizes and limits; (c) is
>>> not two's complement; (d) has padding bits in all integer types except
>>> the char types; (e) has trap representations in these types; and (f) has
>>> multiple pointer representations (so pointer casts often generate code).
>>> What's more it's *current*: there was recently an MCP 13.0 release with
>>> support into 2013.
>>
>> Just out of curiosity, is there any change that this system can run
>> GNU/Linux?
> 
> It would surely be hard and it might be impossible, but why would you?
> The only reason to use the clunky system is that you have old software
> that requires this environment.

I thought you said this was "current"? That's a rather less impressive
example if it is indeed a clunky old machine, rather than one that is
still in sufficiently active use to require new supported releases.

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

#17229

James Kuyper <jameskuyper@verizon.net> writes:

> On 02/13/2012 07:54 AM, Ben Bacarisse wrote:
>> Angel <angel+news@spamcop.net> writes:
>> 
>>> On 2012-02-12, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>>
>>>> For those who wonder about all the oddities in the standard, here is a
>>>> system that (a) uses EBCDIC[2]; (b) has unusual sizes and limits; (c) is
>>>> not two's complement; (d) has padding bits in all integer types except
>>>> the char types; (e) has trap representations in these types; and (f) has
>>>> multiple pointer representations (so pointer casts often generate code).
>>>> What's more it's *current*: there was recently an MCP 13.0 release with
>>>> support into 2013.
>>>
>>> Just out of curiosity, is there any change that this system can run
>>> GNU/Linux?
>> 
>> It would surely be hard and it might be impossible, but why would you?
>> The only reason to use the clunky system is that you have old software
>> that requires this environment.
>
> I thought you said this was "current"? That's a rather less impressive
> example if it is indeed a clunky old machine, rather than one that is
> still in sufficiently active use to require new supported releases.

I did.  It is current.  It has supported releases (the latest into 2013
at least).  Is that inconsistent with it being a "clunky old system"?  (I
didn't say "machine".)

-- 
Ben.

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

#17231

On 02/13/2012 12:28 PM, Ben Bacarisse wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> 
>> On 02/13/2012 07:54 AM, Ben Bacarisse wrote:
...
>>> The only reason to use the clunky system is that you have old software
>>> that requires this environment.
>>
>> I thought you said this was "current"? That's a rather less impressive
>> example if it is indeed a clunky old machine, rather than one that is
>> still in sufficiently active use to require new supported releases.
> 
> I did.  It is current.  It has supported releases (the latest into 2013
> at least).  Is that inconsistent with it being a "clunky old system"?  (I
> didn't say "machine".)

I wouldn't call it "current" if it's only used by those with a pressing
need to run "old software". One term I've often heard used for such
systems is "legacy".

I own an old program called MaxThink that I'd love to be able to run
that requires (IIRC) MS-DOS 2.2 - it had some features that no more
modern software I've seen matches, and I have a lot of old files stored
in MaxThink format. If I still owned an MS-DOS 2.2 system I could run it
on, I wouldn't call it a "current" system, even if MS choose to still
provide support for such systems.

Of course, the original disks became corrupt even before I got rid of my
last floppy disk drive. It wasn't copy protected, and I made working
copies to several different locations, but all of those copies are
currently inaccessible for one reason or another, and the relevant
backup disks are unreadable. Therefore, even if I could copy it to an
emulated MS-DOS environment (I did once have it working under dosemu),
it wouldn't do me any good. Very annoying.

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

#17261

James Kuyper <jameskuyper@verizon.net> writes:

> On 02/13/2012 12:28 PM, Ben Bacarisse wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>> 
>>> On 02/13/2012 07:54 AM, Ben Bacarisse wrote:
> ...
>>>> The only reason to use the clunky system is that you have old software
>>>> that requires this environment.
>>>
>>> I thought you said this was "current"? That's a rather less impressive
>>> example if it is indeed a clunky old machine, rather than one that is
>>> still in sufficiently active use to require new supported releases.
>> 
>> I did.  It is current.  It has supported releases (the latest into 2013
>> at least).  Is that inconsistent with it being a "clunky old system"?  (I
>> didn't say "machine".)
>
> I wouldn't call it "current" if it's only used by those with a pressing
> need to run "old software". One term I've often heard used for such
> systems is "legacy".
>
> I own an old program called MaxThink that I'd love to be able to run
> that requires (IIRC) MS-DOS 2.2 - it had some features that no more
> modern software I've seen matches, and I have a lot of old files stored
> in MaxThink format. If I still owned an MS-DOS 2.2 system I could run it
> on, I wouldn't call it a "current" system, even if MS choose to still
> provide support for such systems.

That's not how I use the word, but I won't claim it the only right way.
But I don't see a problem here because I don't think my meaning could
have been misunderstood.  I stated that there were currently supported
releases, gave the date of the document, and added that you'd only use
it because you have old software that needs it.  What you or I label
such a C implementation is not very important.

The point it, it's not dead.  And, unless the documentation is
pointless, someone is writing (or at least maintaining) C code for it.

<snip>
-- 
Ben.

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

#17259

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Angel <angel+news@spamcop.net> writes:

> > On 2012-02-12, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> >>
> >> For those who wonder about all the oddities in the standard, here is a
> >> system that (a) uses EBCDIC[2]; (b) has unusual sizes and limits; (c) is
> >> not two's complement; (d) has padding bits in all integer types except
> >> the char types; (e) has trap representations in these types; and (f) has
> >> multiple pointer representations (so pointer casts often generate code).
> >> What's more it's *current*: there was recently an MCP 13.0 release with
> >> support into 2013.
> >
> > Just out of curiosity, is there any change that this system can run
> > GNU/Linux?

> It would surely be hard and it might be impossible, but why would you?
> The only reason to use the clunky system is that you have old software
> that requires this environment.

The OpenBSD team diligently maintains their VAX port just to keep themselves
honest. One of their rationalizations is that supporting older architectures
makes it easier to adapt to future architectures by exposing faulty
assumptions in the code.

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

#17260

William Ahern <william@wilbur.25thandClement.com> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Angel <angel+news@spamcop.net> writes:
>> > On 2012-02-12, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> >>
>> >> For those who wonder about all the oddities in the standard, here is a
>> >> system that (a) uses EBCDIC[2]; (b) has unusual sizes and limits; (c) is
>> >> not two's complement; (d) has padding bits in all integer types except
>> >> the char types; (e) has trap representations in these types; and (f) has
>> >> multiple pointer representations (so pointer casts often generate code).
>> >> What's more it's *current*: there was recently an MCP 13.0 release with
>> >> support into 2013.
>> >
>> > Just out of curiosity, is there any change that this system can run
>> > GNU/Linux?
>
>> It would surely be hard and it might be impossible, but why would you?
>> The only reason to use the clunky system is that you have old software
>> that requires this environment.
>
> The OpenBSD team diligently maintains their VAX port just to keep themselves
> honest. One of their rationalizations is that supporting older architectures
> makes it easier to adapt to future architectures by exposing faulty
> assumptions in the code.

Good point -- but the VAX architecture is much closer to most modern
systems than the one Ben describes: 32-bit int with no padding bits, all
pointers are 32 bits with the same representation, ASCII character set.
(VMS differs quite a bit from POSIX systems, but (a) not as much as some
other operating systems, and (b) that's not relevant for OpenBSD).

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

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

#17182

Am 02/12/2012 06:21 PM, schrieb Devil with the China Blue Dress:
> In article <4F36F7C4.5060103@loria.fr>, Jens Gustedt <jens.gustedt@loria.fr> 
> wrote:
> 
>> Am 02/11/2012 11:31 PM, schrieb Devil with the China Blue Dress:
>>> No, the question was about casting an signed number (-1) to an unsigned 
>>> type. 
>>> That this can be done and is closed under addition is a property of twos 
>>> complement integers.
>>
>> No, the representation of the -1 has nothing do with the result of
>> converting it into any unsigned integer type. As has been already been
>> repeated several times upthread, C strictly defines what has to be done
>> when converting a negative *value* to an unsigned integer type. And in
>> particular it uses the value and not the representation.
>>
>> For all conforming C implementations the result of converting -1 to
>> size_t is SIZE_MAX.
> 
> In 4-bit ones complement, -1 is 1110, but the maximum natural number is 1111; 
> signed magnitude are 1001 and 1111; twos complement are 1111 and 1111.

Frankly, I don't see the relation between your sentence and the one from
me that that you are citing above. As I said conversion from signed to
unsigned has by definition of the standard nothing to do with the
representation of the number but just by the value of it.

Jens

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

#17184

In article <4F382C80.10608@loria.fr>, Jens Gustedt <jens.gustedt@loria.fr> 
wrote:

> Am 02/12/2012 06:21 PM, schrieb Devil with the China Blue Dress:
> > In article <4F36F7C4.5060103@loria.fr>, Jens Gustedt 
> > <jens.gustedt@loria.fr> 
> > wrote:
> > 
> >> Am 02/11/2012 11:31 PM, schrieb Devil with the China Blue Dress:
> >>> No, the question was about casting an signed number (-1) to an unsigned 
> >>> type. 
> >>> That this can be done and is closed under addition is a property of twos 
> >>> complement integers.
> >>
> >> No, the representation of the -1 has nothing do with the result of
> >> converting it into any unsigned integer type. As has been already been
> >> repeated several times upthread, C strictly defines what has to be done
> >> when converting a negative *value* to an unsigned integer type. And in
> >> particular it uses the value and not the representation.
> >>
> >> For all conforming C implementations the result of converting -1 to
> >> size_t is SIZE_MAX.
> > 
> > In 4-bit ones complement, -1 is 1110, but the maximum natural number is 
> > 1111; 
> > signed magnitude are 1001 and 1111; twos complement are 1111 and 1111.
> 
> Frankly, I don't see the relation between your sentence and the one from
> me that that you are citing above. As I said conversion from signed to
> unsigned has by definition of the standard nothing to do with the
> representation of the number but just by the value of it.

Thank heavens we sell software to France instead of buying it.

-- 
My name Indigo Montoya.      |         It's Coraline, not Caroline.
You flamed my father.        |       I'm whoever you want me to be.
Prepare to be spanked.       |  Annoying Usenet one post at a time.
Stop posting that!           |    At least I can stay in character.

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

#17186

On 2/12/2012 6:06 PM, Devil with the China Blue Dress wrote:
> In article<4F382C80.10608@loria.fr>, Jens Gustedt<jens.gustedt@loria.fr>
> wrote:
>
>> Am 02/12/2012 06:21 PM, schrieb Devil with the China Blue Dress:
>>> In article<4F36F7C4.5060103@loria.fr>, Jens Gustedt
>>> <jens.gustedt@loria.fr>
>>> wrote:
>>>> [...]
>>>> For all conforming C implementations the result of converting -1 to
>>>> size_t is SIZE_MAX.
>>>
>>> In 4-bit ones complement, -1 is 1110, but the maximum natural number is
>>> 1111;
>>> signed magnitude are 1001 and 1111; twos complement are 1111 and 1111.
>>
>> Frankly, I don't see the relation between your sentence and the one from
>> me that that you are citing above. As I said conversion from signed to
>> unsigned has by definition of the standard nothing to do with the
>> representation of the number but just by the value of it.
>
> Thank heavens we sell software to France instead of buying it.

     Jens is right.  You are wrong.  You are also boorish.  Shut up.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#17757

Devil with the China Blue Dress <chine.bleu@yahoo.com> writes:
> In article <4F382C80.10608@loria.fr>, Jens Gustedt <jens.gustedt@loria.fr> wrote:
> > Am 02/12/2012 06:21 PM, schrieb Devil with the China Blue Dress:
> > > In article <4F36F7C4.5060103@loria.fr>, Jens Gustedt 
> > > <jens.gustedt@loria.fr> 
> > > wrote:
> > > 
> > >> Am 02/11/2012 11:31 PM, schrieb Devil with the China Blue Dress:
> > >>> No, the question was about casting an signed number (-1) to an unsigned 
> > >>> type. 
> > >>> That this can be done and is closed under addition is a property of twos 
> > >>> complement integers.
> > >>
> > >> No, the representation of the -1 has nothing do with the result of
> > >> converting it into any unsigned integer type. As has been already been
> > >> repeated several times upthread, C strictly defines what has to be done
> > >> when converting a negative *value* to an unsigned integer type. And in
> > >> particular it uses the value and not the representation.
> > >>
> > >> For all conforming C implementations the result of converting -1 to
> > >> size_t is SIZE_MAX.
> > > 
> > > In 4-bit ones complement, -1 is 1110, but the maximum natural number is 
> > > 1111; 
> > > signed magnitude are 1001 and 1111; twos complement are 1111 and 1111.
> > 
> > Frankly, I don't see the relation between your sentence and the one from
> > me that that you are citing above. As I said conversion from signed to
> > unsigned has by definition of the standard nothing to do with the
> > representation of the number but just by the value of it.
> 
> Thank heavens we sell software to France instead of buying it.

I suspected you'd eventually reach that level - wrong and obnoxious when 
corrected. Where you go from there, I care not.

Phil
-- 
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

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

#17142

On Sat, 11 Feb 2012 11:21:23 -0800 (PST), Robert Hayes
<rhyes80@gmail.com> wrote:

>I have read that size_t can hold an unsigned int.  I have been playing

size_t is defined as an unsigned integer type but it need not be
unsigned int.  I expect on most systems it is unsigned long as
recommended in 7.17-4 of n1256.

-- 
Remove del for email

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

#17165

Barry Schwarz <schwarzb@dqel.com> writes:
> On Sat, 11 Feb 2012 11:21:23 -0800 (PST), Robert Hayes
> <rhyes80@gmail.com> wrote:
>>I have read that size_t can hold an unsigned int.  I have been playing
>
> size_t is defined as an unsigned integer type but it need not be
> unsigned int.  I expect on most systems it is unsigned long as
> recommended in 7.17-4 of n1256.

That paragraph doesn't recommend using unsigned long; it recommends
*not* using a type with conversion rank greater than that of
unsigned long unless it's necessary.  An implementation defining
size_t as either unsigned int or unsigned long would satisfy the
recommendation.

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

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web