Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Updating C default type |
| Date | 2014-04-22 11:59 -0700 |
| Organization | None to speak of |
| Message-ID | <lna9bdxk9t.fsf@nuthaus.mib.org> (permalink) |
| References | <lj66ho$8fg$1@speranza.aioe.org> <lj6750$a10$2@speranza.aioe.org> <lj6802$cek$1@speranza.aioe.org> |
Raj Pashwar <raj121190@hotmail.NOSPAM.com> writes:
[...]
> Of course, it does NOT make sense. However in this case, the benefit is
> the extra RANGE of double, not precision.
That extra range is of no benefit.
> With a double arg, malloc could allocate upto 1.7e308 bytes. It will be
> many years, before RAM density increases to exceed this size. Whereas, int
> can only allocate upto 2e9 bytes.
malloc's argument is of type size_t, not int. Implementations
already define size_t as an unsigned type large enough to represent
the size of any allocatable object. On many current systems,
the maximum value of size_t is 2**64-1, about 18 quintillion.
If future systems are allocate more than that, they can make size_t
a larger unsigned integer type.
The extra precision (malloc(3.5)) is obviously of no benefit at all,
nor is the ability to represent negative numbers. The extra range
is of no real benefit either, given that implementations can make
size_t as wide as they need to. Even if that weren't the case,
that extra range comes at the cost of precision. You could ask
malloc to allocate 2**64 bytes, but not 2**64-1, because 2**64-1
cannot be represented as a double (in a typical implementation).
> In other cases, i.e. return value for main(), BOTH the extra precision
> AND extra range of double can be valuable.
Not particularly. The full range of int typically isn't used.
The C standard defines the meaning of 2 or 3 return values (0,
EXIT_SUCCESS, and EXIT_FAILURE, where EXIT_SUCCESS is usually equal
to 0). POSIX discards all but the low-order 8 bits. The "curl"
command has the greatest number of distinct return status values
that I know of, and it only goes from 0 to 88. Programs that need
to communicate more information than can be stored in a status
code can already do so in a variety of ways, such as by writing
information to stdout or to a file.
The Plan 9 operating system, as I recall, uses a string rather than
an integer as the exit status of a program. It's an interesting
idea, but it's equally interesting to note that it hasn't caught
on elsewhere.
Your proposed change would break a large percentage of existing
code for no benefit that I can see.
--
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"
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Updating C default type Raj Pashwar <raj121190@hotmail.NOSPAM.com> - 2014-04-22 16:48 +0000
Re: Updating C default type jacob navia <jacob@spamsink.net> - 2014-04-22 18:59 +0200
Re: Updating C default type Raj Pashwar <raj121190@hotmail.NOSPAM.com> - 2014-04-22 17:13 +0000
Re: Updating C default type Keith Thompson <kst-u@mib.org> - 2014-04-22 11:59 -0700
Re: Updating C default type Kaz Kylheku <kaz@kylheku.com> - 2014-04-22 19:12 +0000
Re: Updating C default type jacob navia <jacob@spamsink.net> - 2014-04-25 19:31 +0200
Re: Updating C default type Stephen Sprunk <stephen@sprunk.org> - 2014-04-22 15:41 -0500
Re: Updating C default type "BartC" <bc@freeuk.com> - 2014-04-22 21:47 +0100
Re: Updating C default type Ken Brody <kenbrody@spamcop.net> - 2014-04-24 12:25 -0400
Re: Updating C default type Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-24 10:32 -0700
Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-24 20:17 +0000
Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-24 21:03 +0000
Re: Updating C default type Gareth Owen <gwowen@gmail.com> - 2014-04-22 19:12 +0100
Re: Updating C default type Keith Thompson <kst-u@mib.org> - 2014-04-22 10:26 -0700
Re: Updating C default type Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 10:28 -0700
Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-22 18:20 +0000
Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-22 19:09 +0000
Re: Updating C default type James Kuyper <jameskuyper@verizon.net> - 2014-04-22 15:35 -0400
Re: Updating C default type James Kuyper <jameskuyper@verizon.net> - 2014-04-22 15:38 -0400
Re: Updating C default type Kaz Kylheku <kaz@kylheku.com> - 2014-04-22 19:54 +0000
Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-22 21:27 +0000
Re: Updating C default type "BartC" <bc@freeuk.com> - 2014-04-22 23:08 +0100
Re: Updating C default type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-22 22:03 +0100
Re: Updating C default type Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-04-23 09:59 +0200
Re: Updating C default type David Thompson <dave.thompson2@verizon.net> - 2014-05-25 16:44 -0400
Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-05-26 05:48 +0000
Re: Updating C default type "Osmium" <r124c4u102@comcast.net> - 2014-04-22 14:01 -0500
Re: Updating C default type Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2014-04-23 16:57 +0000
Re: Updating C default type James Kuyper <jameskuyper@verizon.net> - 2014-04-23 13:13 -0400
Re: Updating C default type Kaz Kylheku <kaz@kylheku.com> - 2014-04-23 18:02 +0000
Re: Updating C default type Keith Thompson <kst-u@mib.org> - 2014-04-23 11:33 -0700
Re: Updating C default type Kaz Kylheku <kaz@kylheku.com> - 2014-04-22 19:08 +0000
Re: Updating C default type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-22 22:08 +0100
Re: Updating C default type "BartC" <bc@freeuk.com> - 2014-04-22 22:19 +0100
Re: Updating C default type Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 14:13 -0700
Re: Updating C default type Stephen Sprunk <stephen@sprunk.org> - 2014-04-23 11:55 -0500
Re: Updating C default type Keith Thompson <kst-u@mib.org> - 2014-04-23 10:55 -0700
Re: Updating C default type Robert Wessel <robertwessel2@yahoo.com> - 2014-04-24 00:03 -0500
Re: Updating C default type Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-23 22:37 -0700
Re: Updating C default type glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-24 12:05 +0000
Re: Updating C default type gordonb.ez7sl@burditt.org (Gordon Burditt) - 2014-04-25 06:11 -0500
Re: Updating C default type James Kuyper <jameskuyper@verizon.net> - 2014-04-25 08:48 -0400
Re: Updating C default type Stephen Sprunk <stephen@sprunk.org> - 2014-04-22 15:30 -0500
Re: Updating C default type ralph <nt_consulting@yahoo.com> - 2014-04-22 23:18 -0500
Re: Updating C default type Ken Brody <kenbrody@spamcop.net> - 2014-04-24 12:28 -0400
Re: Updating C default type gordonb.oztxz@burditt.org (Gordon Burditt) - 2014-04-24 23:50 -0500
Re: Updating C default type James Kuyper <jameskuyper@verizon.net> - 2014-04-25 08:41 -0400
Re: Updating C default type Hans Vlems <hvlems@freenet.de> - 2014-05-25 23:57 -0700
Re: Updating C default type Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-05-26 01:55 -0700
Re: Updating C default type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-05-26 13:01 +0100
Re: Updating C default type Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-05-26 13:12 -0700
Re: Updating C default type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-05-26 22:31 +0100
Re: Updating C default type Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-05-26 23:55 +0100
Re: Updating C default type Keith Thompson <kst-u@mib.org> - 2014-05-26 17:11 -0700
Re: Updating C default type James Kuyper <jameskuyper@verizon.net> - 2014-05-27 07:54 -0400
csiph-web