Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #120124 > unrolled thread
| Started by | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| First post | 2017-09-21 20:50 -0700 |
| Last post | 2017-09-22 09:12 -0700 |
| Articles | 20 on this page of 178 — 26 participants |
Back to article view | Back to comp.lang.c
Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-21 20:50 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-22 01:15 -0500
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-22 01:21 -0500
Re: Something C might need fir <profesor.fir@gmail.com> - 2017-09-22 00:44 -0700
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-22 11:02 +0200
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-22 12:35 -0500
Re: Something C might need Richard Damon <Richard@Damon-Family.org> - 2017-09-22 13:46 -0400
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-22 11:47 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-22 12:16 -0700
Re: Something C might need Richard Damon <Richard@Damon-Family.org> - 2017-09-22 18:10 -0400
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-22 15:24 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-22 15:52 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-23 12:29 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-23 08:29 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 18:06 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 12:28 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-22 16:17 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-22 18:20 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-22 22:45 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-23 12:22 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 11:29 +0100
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-23 10:25 -0400
Re: Something C might need Reinhardt Behm <rbehm@hushmail.com> - 2017-09-24 22:09 +0800
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 15:32 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 13:17 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 21:53 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 14:54 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 23:10 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 16:14 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 01:04 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 17:23 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 08:48 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-25 11:50 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 21:59 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-25 14:25 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-26 09:39 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-26 11:50 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 15:44 -0500
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-24 18:57 -0400
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 00:08 +0100
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-24 20:51 -0400
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 02:10 +0100
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-24 22:22 -0400
Re: Something C might need Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 06:35 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 16:16 +0200
Re: Something C might need Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 07:47 -0700
Re: Something C might need Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 13:38 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-24 23:29 -0500
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 17:40 -0500
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-24 23:30 -0500
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-25 08:58 -0400
Re: Something C might need supercat@casperkitty.com - 2017-09-23 08:41 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 17:32 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-23 11:32 -0700
Re: Something C might need Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-09-25 14:43 +0000
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 22:07 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-25 13:34 -0700
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-26 10:04 +1300
Re: Something C might need Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-09-26 14:31 +0000
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-27 08:38 +1300
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 17:49 -0700
Re: Something C might need gordonb.w32iq@burditt.org (Gordon Burditt) - 2017-09-23 21:21 -0500
Re: Something C might need supercat@casperkitty.com - 2017-09-24 11:27 -0700
Re: Something C might need gordonb.woyvd@burditt.org (Gordon Burditt) - 2017-09-25 01:08 -0500
Re: Something C might need supercat@casperkitty.com - 2017-09-25 09:38 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-25 10:00 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-23 11:32 +0100
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-23 12:29 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-23 20:38 +0100
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-23 15:25 -0700
Re: Something C might need Richard Damon <Richard@Damon-Family.org> - 2017-09-23 20:36 -0400
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 01:42 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 18:03 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-23 22:47 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:03 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-24 15:10 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 16:20 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-24 16:44 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:00 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-24 16:51 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:11 +0200
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:04 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 22:10 +0100
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-24 10:19 +1300
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 01:38 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 02:14 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 18:41 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 11:16 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 11:41 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:15 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:23 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 14:03 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 13:59 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 16:08 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 21:50 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 21:40 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:28 +0200
Re: Something C might need luser droog <luser.droog@gmail.com> - 2017-09-26 06:28 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-26 07:47 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-27 08:26 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-27 07:22 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-27 09:01 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-27 09:42 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:42 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-27 19:22 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:48 +0200
Re: Something C might need scott@slp53.sl.home (Scott Lurndal) - 2017-09-28 17:31 +0000
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 22:09 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 22:44 +0100
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-25 01:57 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 02:02 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 19:10 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-27 16:27 +0100
Re: Something C might need Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-27 09:26 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:53 +0200
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-27 10:52 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-27 19:20 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-27 11:44 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:57 +0200
Re: Something C might need James Kuyper <jameskuyper@verizon.net> - 2017-09-24 14:49 -0400
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 22:06 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 20:09 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:12 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 20:46 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:41 +0200
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 21:05 +0100
Re: Something C might need gordonb.r273i@burditt.org (Gordon Burditt) - 2017-09-23 21:34 -0500
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 09:01 +0100
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-24 19:34 +0200
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-24 23:53 -0500
Re: Something C might need "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-25 12:27 -0400
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-25 20:33 +0200
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 15:52 -0500
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-25 23:23 +0200
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-25 15:15 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 17:49 -0500
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-26 09:46 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-26 07:32 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-26 21:50 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-26 14:32 -0700
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-26 22:34 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-26 14:39 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-25 19:38 +0100
Re: Something C might need "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-25 15:00 -0400
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-25 12:29 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 22:12 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-22 11:38 +0100
Re: Something C might need Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-22 04:21 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-22 14:54 +0200
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-22 08:02 -0700
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 06:49 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-22 20:24 +0100
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 12:45 -0700
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 09:00 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 17:34 -0400
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 10:49 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 19:25 -0400
Re: Something C might need "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-22 19:35 -0400
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 11:52 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 18:25 -0700
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 13:36 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 20:20 -0700
Rick says C is a dying language. (Was: Something C might need) gazelle@shell.xmission.com (Kenny McCormack) - 2017-09-23 09:15 +0000
Re: Rick says C is a dying language. (Was: Something C might need) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-23 04:40 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 13:00 +0100
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-23 10:28 -0400
Re: Something C might need James Kuyper <jameskuyper@verizon.net> - 2017-09-22 23:22 -0400
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 18:01 +1200
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-22 20:31 -0400
Re: Something C might need jladasky@itu.edu - 2017-09-22 16:27 -0700
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 16:34 -0700
Re: Something C might need scott@slp53.sl.home (Scott Lurndal) - 2017-09-26 21:44 +0000
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-26 14:53 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-23 02:14 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-22 21:31 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-22 14:02 -0700
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 17:29 -0400
Re: Something C might need supercat@casperkitty.com - 2017-09-22 09:12 -0700
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-27 07:22 -0700 |
| Message-ID | <a2147add-70ed-443f-b5fd-cd51c7a99e71@googlegroups.com> |
| In reply to | #120357 |
On Wednesday, September 27, 2017 at 1:26:46 AM UTC-5, David Brown wrote:
> The compiler could /almost/ do that internally, at least for targets
> that don't have padding and stick to two's complement arithmetic. The
> only problem I can see is that for types that are the same size (say, a
> 32-bit int and 32-bit long) would no longer have different ranks and be
> incompatible with each other. That would mean certain diagnostics could
> not be issued, and _Generic could not distinguish between 0 and 0L.
Compilers are free to issue diagnostics for any reason they see fit. While
it may be helpful to have an option to warn of incompatibility with compilers
that don't have the same sizes for types (and the Standard would allow such
warnings even in a conforming mode) I don't see any other real benefit to
such incompatibility. Reaping any significant "optimization advantage" from
the existence of two incompatible types of matching representation would
generally require that code be written in less-portable fashion than would
otherwise be necessary (e.g. if half of the uses of 64-bit values will never
alias the other half, using "long" for some and "long long" for the others,
thus making the code needlessly dependent upon "long" being 64 bits), and
the benefits obtainable in such fashion would pale in comparison with those
that could be reaped from being able to specify "compatibility classes", e.g.
expanding the allowable usages of "restrict" to:
typedef uint64_t restrict thing_block_location;
typedef uint64_t restrict thing_block_id;
as a means of creating thing_block_location and thing_block_id as types
which, while compatible with "uint64_t", would be incompatible with each
other.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-27 09:01 -0700 |
| Message-ID | <ln1sms1680.fsf@kst-u.example.com> |
| In reply to | #120275 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> (Personally, I would prefer standard integer types to be compatible with
> each other if they are of the same size.
Personally, I think that would be a bad idea.
You mention _Generic downthread. Making types of the same size
compatible would pretty much kill any use of _Generic for integer
types. A generic selection that uses "int" and "long" would be
legal in some implementations, illegal in others.
And there wouldn't be much benefit. You could write non-portable code
that assumes, for example, that int and long are compatible -- but such
code could and probably should be modified to use one type or the other.
> In fact, I'd rather have the
> <stdint.h> types as being the fundamental ones in C, with "int" being a
> typedef for "int_fast16_t", "long" being a typedef for "int_fast32_t",
> and so on. But C I don't waste many tears about what C could have been,
> as long as it works fine for what I need.)
The fact that each of the intN_t types is compatible with *some*
built-in integer type, but you can't portably assume which one, is IMHO
a bit of a problem. This:
int a;
int32_t *b;
*b = a;
is valid in some implementations, a constraint violation in others.
I would have liked to have a method, similar to typedef, that
defines a new and incompatible type with the same characteristics
as an existing type. Then int, long, int32_t, and int64_t could
all be distinct and incompatible types.
(A current implementation could do this by making the [u]intN_t types
typedefs for extended integer types.)
But again, that would mess up _Generic for integer types.
[...]
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-27 09:42 -0700 |
| Message-ID | <7aec6ac3-c8b9-44b5-a924-e0212381d17a@googlegroups.com> |
| In reply to | #120373 |
On Wednesday, September 27, 2017 at 11:01:13 AM UTC-5, Keith Thompson wrote: > You mention _Generic downthread. Making types of the same size > compatible would pretty much kill any use of _Generic for integer > types. A generic selection that uses "int" and "long" would be > legal in some implementations, illegal in others. Or the Standard could a means of specifying that if two types are both given as generic choices, a compiler should choose among them somehow. In many cases, which method was chosen will only *matter* if the types aren't essentially equivalent. > And there wouldn't be much benefit. You could write non-portable code > that assumes, for example, that int and long are compatible -- but such > code could and probably should be modified to use one type or the other. Unless it has to communicate with an API which is controlled by someone else. Given a function in one API which populates an array of "long", and another which consumes an array of "long long", how should one write code that reads the former and writes the latter? Using a union which contains an array of each would be a nice approach on systems where both are the same size, except that gcc's interpretation of the aliasing rules won't make that work *even if code explicitly reads each element as the type with which it had been written, and writes it as the next type with which it will be read*.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-28 10:42 +0200 |
| Message-ID | <oqiclk$9ob$1@dont-email.me> |
| In reply to | #120373 |
On 27/09/17 18:01, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> (Personally, I would prefer standard integer types to be compatible with >> each other if they are of the same size. > > Personally, I think that would be a bad idea. Yeah, you and the C committee both :-) There are a few changes that I would prefer in C, because it would suit /me/, /my/ work and /my/ style of coding - but I am fully aware that other people have different needs and different opinions. And of course a brief comment in a Usenet post does not mean I have thought carefully through all implications of such changes! > > You mention _Generic downthread. Making types of the same size > compatible would pretty much kill any use of _Generic for integer > types. A generic selection that uses "int" and "long" would be > legal in some implementations, illegal in others. If the type system were based on fixed size types, like int32_t, int64_t, etc., then that would not be a problem. You would do your _Generics on those types, where the selection really matters because your foo_int32_t() and foo_int64_t() functions are different. It would avoid the necessity of having foo_int(), foo_long() and foo_longlong() as three defined functions when only two are actually needed. (This is for a typical target with 32-bit int, 64-bit long long, and where long might be 32-bit or 64-bit.) Another possibility is to make it legal for _Generic cases to overlap, and let the compiler pick whichever branch it wanted in the case of duplicates. > > And there wouldn't be much benefit. You could write non-portable code > that assumes, for example, that int and long are compatible -- but such > code could and probably should be modified to use one type or the other. > >> In fact, I'd rather have the >> <stdint.h> types as being the fundamental ones in C, with "int" being a >> typedef for "int_fast16_t", "long" being a typedef for "int_fast32_t", >> and so on. But C I don't waste many tears about what C could have been, >> as long as it works fine for what I need.) > > The fact that each of the intN_t types is compatible with *some* > built-in integer type, but you can't portably assume which one, is IMHO > a bit of a problem. This: > > int a; > int32_t *b; > *b = a; > > is valid in some implementations, a constraint violation in others. > I would have liked to have a method, similar to typedef, that > defines a new and incompatible type with the same characteristics > as an existing type. Then int, long, int32_t, and int64_t could > all be distinct and incompatible types. I'd also be keen on having a way to make new integer types that are /not/ compatible with the standard ones. I'd like a nice way to make arithmetic types "distance" and "speed" that are incompatible, even though they are both "int" (or "int32_t") underneath. In C today, that means wrapping them in a struct - losing the possibility of infix operator syntax. I suppose making all the intN_t types incompatible with the standard integer types is a different way to solve the same issue. I don't like the inconsistency here. On some of my common targets, int32_t is compatible with "long", on others it is compatible with "int", even though on most these are the same size. I suggested making these all compatible - but making them all /incompatible/ is an alternative that would give consistent behaviour. > > (A current implementation could do this by making the [u]intN_t types > typedefs for extended integer types.) That would be one method. Another would be using extensions such as gcc's __attribute__ syntax to mark the types as incompatible. gcc has an attribute to mark a type as being "may_alias". If "int32_t" were marked this way, then using an int32_t pointer to access an int or a long will work, even though the pointers may not be compatible. > > But again, that would mess up _Generic for integer types. > (Once you starting thinking of one new feature, it leads to another new feature, and another - and pretty soon someone like me is going to say "just use C++".)
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-27 19:22 +0100 |
| Message-ID | <C%RyB.939878$HN.400581@fx21.am4> |
| In reply to | #120275 |
On 25/09/2017 08:28, David Brown wrote: > On 24/09/17 22:40, bartc wrote: >> It is especially a nuisance for me since I very often have to interface >> from such a C API from my language, and may need to exactly duplicate a >> struct comprised of shorts, ints, longs and pointers, complete with all >> the expected alignment and padding. > > Use the OS's standard headers. Use .... how? Perhaps you missed where I said I have to emulate such structs from another language. That means manually looking at the C definition which is often a mess of multiple lots of conditional code, typedefs defined on top of typedefs whose definitions are themselves conditional and which may be buries in headers several levels deep. That you don't know about the width of 'long' or what packing may be in force is just part of it. You've no idea how spoilt you are insulating yourself from these details, but that also means you don't know how horrendous a lot of C header code actually is. Provided you feed it in the compiler at one end and out comes an object file, is all that apparently matters. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-28 10:48 +0200 |
| Message-ID | <oqid0r$c3d$1@dont-email.me> |
| In reply to | #120398 |
On 27/09/17 20:22, bartc wrote: > On 25/09/2017 08:28, David Brown wrote: >> On 24/09/17 22:40, bartc wrote: > >>> It is especially a nuisance for me since I very often have to interface >>> from such a C API from my language, and may need to exactly duplicate a >>> struct comprised of shorts, ints, longs and pointers, complete with all >>> the expected alignment and padding. >> >> Use the OS's standard headers. > > Use .... how? > > Perhaps you missed where I said I have to emulate such structs from > another language. > > That means manually looking at the C definition which is often a mess of > multiple lots of conditional code, typedefs defined on top of typedefs > whose definitions are themselves conditional and which may be buries in > headers several levels deep. That you don't know about the width of > 'long' or what packing may be in force is just part of it. > > You've no idea how spoilt you are insulating yourself from these > details, but that also means you don't know how horrendous a lot of C > header code actually is. Provided you feed it in the compiler at one end > and out comes an object file, is all that apparently matters. > Well, yes - that /is/ what matters to a C programmer. I really don't care how "horrendous" header code might be. (Although in all your examples over the years, the headers have not looked nearly as bad to me as they seem to you, and all the "extra" stuff that you don't like is there for good reasons.) If you are implementing a new language, then /you/ have to figure out how to interface with C libraries using C headers. You might do it by having a way to read C headers directly. You might do it by making a tool that /you/ use that reads in the C headers, runs it through a standard C preprocessor, then extracts the function and symbols and generates some sort of interface module for your own language. There are tools like this for many languages - people manage it for things like Perl and Python that are much more different from C than your language is.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-09-28 17:31 +0000 |
| Message-ID | <amazB.186247$OC1.139570@fx06.iad> |
| In reply to | #120432 |
David Brown <david.brown@hesbynett.no> writes:
>If you are implementing a new language, then /you/ have to figure out
>how to interface with C libraries using C headers. You might do it by
>having a way to read C headers directly. You might do it by making a
>tool that /you/ use that reads in the C headers, runs it through a
>standard C preprocessor, then extracts the function and symbols and
>generates some sort of interface module for your own language.
Or slightly modify the open source 'pahole(1)' program to generate headers
for whatever language you desire from a compiled C or C++ program
that includes the file in question:
e.g.
$ pahole bin/vsim > /tmp/bbb
struct tm {
int tm_sec; /* 0 4 */
int tm_min; /* 4 4 */
int tm_hour; /* 8 4 */
int tm_mday; /* 12 4 */
int tm_mon; /* 16 4 */
int tm_year; /* 20 4 */
int tm_wday; /* 24 4 */
int tm_yday; /* 28 4 */
int tm_isdst; /* 32 4 */
/* XXX 4 bytes hole, try to pack */
long int tm_gmtoff; /* 40 8 */
const char * tm_zone; /* 48 8 */
/* size: 56, cachelines: 1, members: 11 */
/* sum members: 52, holes: 1, sum holes: 4 */
/* last cacheline: 56 bytes */
};
struct lconv {
char * decimal_point; /* 0 8 */
char * thousands_sep; /* 8 8 */ char * grouping; /* 16 8 */
char * int_curr_symbol; /* 24 8 */ char * currency_symbol; /* 32 8 */
char * mon_decimal_point; /* 40 8 */
char * mon_thousands_sep; /* 48 8 */
char * mon_grouping; /* 56 8 */
/* --- cacheline 1 boundary (64 bytes) --- */
char * positive_sign; /* 64 8 */
char * negative_sign; /* 72 8 */
char int_frac_digits; /* 80 1 */
char frac_digits; /* 81 1 */
char p_cs_precedes; /* 82 1 */
char p_sep_by_space; /* 83 1 */
char n_cs_precedes; /* 84 1 */
char n_sep_by_space; /* 85 1 */
char p_sign_posn; /* 86 1 */
char n_sign_posn; /* 87 1 */
char int_p_cs_precedes; /* 88 1 */
char int_p_sep_by_space; /* 89 1 */
char int_n_cs_precedes; /* 90 1 */
char int_n_sep_by_space; /* 91 1 */
char int_p_sign_posn; /* 92 1 */
char int_n_sign_posn; /* 93 1 */
/* size: 96, cachelines: 2, members: 24 */
/* padding: 2 */
/* last cacheline: 32 bytes */
};
etc.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-09-24 22:09 +0100 |
| Message-ID | <87wp4n3isc.fsf@bsb.me.uk> |
| In reply to | #120228 |
bartc <bc@freeuk.com> writes: > On 24/09/2017 13:03, David Brown wrote: >> On 24/09/17 12:16, bartc wrote: > >>>> The answer to your question is in n1570.pdf. >>> >>> Why do you guys do this? >>> >>> Obviously there must be some nuance that I've missed out, but then both >>> of you suggest I can find the answer in a 700-page reference manual. >>> >>> WHY DON'T YOU JUST SAY WHAT IT IS? >> >> Perhaps because it has been already said dozens of times here? Perhaps >> Keith has specifically told you exactly what it means already? > > And yours is the third post that beats around the bush. > > I said 'long long is a type at least as wide as a long'. Someone else > said 'no it isn't'. No you didn't say that. You have edited the quoted material to remove what you actually said and you have re-worded it here so as to make it a correct statement. You've even put it in quotes to suggest this is literal quote. I am trying as hard as I can to believe that that's all just accidental. > So what did I say wrong? No one is willing to tell me. > > The only clue, and not even directed at me, was: > > BB: >> There are lots of example of long >> long being at least as wide a long (indeed it must be). The error was >> to say that that is all that long long must be. > > So this finally admits that what I said wasn't actually wrong (as > someone else might have thought from 'No it isn't'). How dare you. You have removed what you really said from the quoted material, re-worded it to be trivial but true, and then you have the gall to claim I have finally admitted you were "not actually wrong".[1] I try to stay calm and polite on Usenet but this exchange is testing that resolve. Since you will claim you have no idea what I am talking about here is what you originally wrote: | long long simply means a type at l[e]ast as wide as a long. That is not at all the same as | long long is a type at least as wide as a long <snip> [1] Even the "finally" part is spin. I posted "no it isn't" at 1:38, just before going to bed, and according to you, I "finally admitted" something first thing this morning. And in case you think I've since been avoiding the issue, I've been at a seminar all day. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-24 22:44 +0100 |
| Message-ID | <_GVxB.1482907$8M.1165599@fx47.am4> |
| In reply to | #120247 |
On 24/09/2017 22:09, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: > I try to stay calm and polite on Usenet but this exchange is testing > that resolve. It's not me making a mountain out of a molehill. If there was something amiss with my remark, which was aimed at the misapprehension that a 'long' attribute always doubles the width of a type, then you could just have posted a correction. Instead you seemed to delight in calling me out, without telling me (or the OP) what was irking you. No else bothered either, and it was the best part of 24 hours before I find out what was you all had in mind. > Since you will claim you have no idea what I am talking about here is > what you originally wrote: > > | long long simply means a type at l[e]ast as wide as a long. In response to: "...is obvious what it means - a value twice as long as a long." To which someone could have replied to my remark: "and of at least 64 bits" if they really thought it was that critical. And that would have been the end of it. BTW inflammatory comments like this don't help keeping other people calm and polite: "You could have find out what it means if you wanted to, but I expect you'd rather just complain about how it's all so confusing." -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-09-25 01:57 +0100 |
| Message-ID | <87fubb389d.fsf@bsb.me.uk> |
| In reply to | #120248 |
bartc <bc@freeuk.com> writes: > On 24/09/2017 22:09, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: > >> I try to stay calm and polite on Usenet but this exchange is testing >> that resolve. > > It's not me making a mountain out of a molehill. You accused me of being dishonest in a post where you re-wrote what you originally said in order to be able to make that accusation. If getting cross about that is making a mountain out of a molehill, so be it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-25 02:02 +0100 |
| Message-ID | <JAYxB.1383978$f17.939@fx46.am4> |
| In reply to | #120261 |
On 25/09/2017 01:57, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: > >> On 24/09/2017 22:09, Ben Bacarisse wrote: >>> bartc <bc@freeuk.com> writes: >> >>> I try to stay calm and polite on Usenet but this exchange is testing >>> that resolve. >> >> It's not me making a mountain out of a molehill. > > You accused me of being dishonest in a post where you re-wrote what you > originally said in order to be able to make that accusation. If getting > cross about that is making a mountain out of a molehill, so be it. > Sorry, but you started by turning a simple correction into a personal dig.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-24 19:10 -0700 |
| Message-ID | <lntvzr1qbq.fsf@kst-u.example.com> |
| In reply to | #120262 |
bartc <bc@freeuk.com> writes:
> On 25/09/2017 01:57, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>>> On 24/09/2017 22:09, Ben Bacarisse wrote:
>>>> bartc <bc@freeuk.com> writes:
>>>
>>>> I try to stay calm and polite on Usenet but this exchange is testing
>>>> that resolve.
>>>
>>> It's not me making a mountain out of a molehill.
>>
>> You accused me of being dishonest in a post where you re-wrote what you
>> originally said in order to be able to make that accusation. If getting
>> cross about that is making a mountain out of a molehill, so be it.
>
> Sorry, but you started by turning a simple correction into a personal dig.
You altered your own quoted words so as to appear to invalidate that
"simple correction".
In Message-ID: <N_NxB.7479$3e5.5383@fx02.am4>, you wrote:
I said 'long long is a type at least as wide as a long'. Someone else
said 'no it isn't'.
The quotation marks would imply to an unwary reader that those were
your exact words.
But in your earlier article, Message-ID:
<s4AxB.1045491$LJ4.896194@fx37.am4>, you actually wrote:
long long simply means a type at last as wide as a long.
And, on my 64-bit Linux, both long and long long are 64-bit
values. But are different types! (So long long* is incompatible with
long*.)
("last" was obviously a typo for "least", no big deal)
Somebody refuted your original statement, not your later misquotation
of it.
I can imagine that you didn't realize that you were fundamentally
altering the meaning of your original statement. Did you realize that,
or did you misunderstand your own statement?
I can also imagine that you didn't know that long long is required to be
at least 64 bits, but that would be very odd for someone who has worked
on a C implementation. Did you really not know that?
--
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 | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-27 16:27 +0100 |
| Message-ID | <HrPyB.977421$FB3.54645@fx14.am4> |
| In reply to | #120264 |
On 25/09/2017 03:10, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> On 25/09/2017 01:57, Ben Bacarisse wrote:
>>> bartc <bc@freeuk.com> writes:
>>>> On 24/09/2017 22:09, Ben Bacarisse wrote:
>>>>> bartc <bc@freeuk.com> writes:
>>>>
>>>>> I try to stay calm and polite on Usenet but this exchange is testing
>>>>> that resolve.
>>>>
>>>> It's not me making a mountain out of a molehill.
>>>
>>> You accused me of being dishonest in a post where you re-wrote what you
>>> originally said in order to be able to make that accusation. If getting
>>> cross about that is making a mountain out of a molehill, so be it.
>>
>> Sorry, but you started by turning a simple correction into a personal dig.
>
> You altered your own quoted words so as to appear to invalidate that
> "simple correction".
>
> In Message-ID: <N_NxB.7479$3e5.5383@fx02.am4>, you wrote:
>
> I said 'long long is a type at least as wide as a long'. Someone else
> said 'no it isn't'.
>
> The quotation marks would imply to an unwary reader that those were
> your exact words.
>
> But in your earlier article, Message-ID:
> <s4AxB.1045491$LJ4.896194@fx37.am4>, you actually wrote:
>
> long long simply means a type at last as wide as a long.
>
> And, on my 64-bit Linux, both long and long long are 64-bit
> values. But are different types! (So long long* is incompatible with
> long*.)
>
> ("last" was obviously a typo for "least", no big deal)
>
> Somebody refuted your original statement, not your later misquotation
> of it.
>
> I can imagine that you didn't realize that you were fundamentally
> altering the meaning of your original statement. Did you realize that,
> or did you misunderstand your own statement?
>
> I can also imagine that you didn't know that long long is required to be
> at least 64 bits, but that would be very odd for someone who has worked
> on a C implementation. Did you really not know that?
Whether it slipped my mind not, it doesn't matter. At the heart of the
issue was correcting the idea that 'long' doubles the size of a type.
Does 'long' double the size? No, it defines a size that may be at least
as wide, but could also be the same size.
That behaviour of 'long' applies both to the second applied long in
'long long int, and the long in 'long int'.
That some specific combinations come with a minimum width is not so
relevant. And since the OP is more interested in C89, I don't think that
'long long' is officially part of that language, therefore it can't
officially have a minimum width.
Of course that could also mean that the exact meaning of 'long long' is
up for grabs, but it would make sense to assume the OP would want a
second 'long' to modify a type using rules similar way as a first. In
other words, to have a new type is no smaller than before, but may be wider.
That long long currently also means 64-bits or more is less important,
but if someone wanted to mention that, then fine.
What I had a problem with is someone summarily saying "No it isn't."
without explaining what they meant, suggesting I'm getting it (whatever
'it' is ) wrong on purpose, and others not helping by giving references
to online documents that are supposed to tell which part of my statement
was wrong instead of just telling me (and a few dozen lurkers wandering
the same thing). (Actually they didn't help at all.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2017-09-27 09:26 -0700 |
| Message-ID | <3c0d0d03-a7d4-442f-bf37-2a693868d98b@googlegroups.com> |
| In reply to | #120370 |
On Wednesday, September 27, 2017 at 4:27:50 PM UTC+1, Bart wrote: > > Whether it slipped my mind not, it doesn't matter. At the heart of the > issue was correcting the idea that 'long' doubles the size of a type. > No, it probably should, but it doesn't. The idea is probably to keep long reasonably efficient on 32 bit platforms. Nowadays the 32 bit registers with 4GB memory set-up is becoming increasingly rare, however, and 64 bit longs are starting to make sense.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-28 10:53 +0200 |
| Message-ID | <oqid9n$dp6$1@dont-email.me> |
| In reply to | #120378 |
On 27/09/17 18:26, Malcolm McLean wrote: > On Wednesday, September 27, 2017 at 4:27:50 PM UTC+1, Bart wrote: >> >> Whether it slipped my mind not, it doesn't matter. At the heart of the >> issue was correcting the idea that 'long' doubles the size of a type. >> > No, it probably should, but it doesn't. The idea is probably to keep long > reasonably efficient on 32 bit platforms. Nowadays the 32 bit registers > with 4GB memory set-up is becoming increasingly rare, however, and 64 > bit longs are starting to make sense. > 32-bit registers are not "becoming increasingly rare" - they are becoming increasingly common, replacing 8-bit and 16-bit registers. 64-bit longs have made always made sense on 64-bit machines, and most systems use them. The main exception is 64-bit Windows. 64-bit long longs have existed since C99 and have remained unchanged in C11 - so there has been a standard 64-bit (or more) type in C for nearly a couple of decades.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-27 10:52 -0700 |
| Message-ID | <lnpoacyqpa.fsf@kst-u.example.com> |
| In reply to | #120370 |
bartc <bc@freeuk.com> writes:
> On 25/09/2017 03:10, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>>> On 25/09/2017 01:57, Ben Bacarisse wrote:
>>>> bartc <bc@freeuk.com> writes:
>>>>> On 24/09/2017 22:09, Ben Bacarisse wrote:
>>>>>> bartc <bc@freeuk.com> writes:
>>>>>
>>>>>> I try to stay calm and polite on Usenet but this exchange is testing
>>>>>> that resolve.
>>>>>
>>>>> It's not me making a mountain out of a molehill.
>>>>
>>>> You accused me of being dishonest in a post where you re-wrote what you
>>>> originally said in order to be able to make that accusation. If getting
>>>> cross about that is making a mountain out of a molehill, so be it.
>>>
>>> Sorry, but you started by turning a simple correction into a personal dig.
>>
>> You altered your own quoted words so as to appear to invalidate that
>> "simple correction".
>>
>> In Message-ID: <N_NxB.7479$3e5.5383@fx02.am4>, you wrote:
>>
>> I said 'long long is a type at least as wide as a long'. Someone else
>> said 'no it isn't'.
>>
>> The quotation marks would imply to an unwary reader that those were
>> your exact words.
>>
>> But in your earlier article, Message-ID:
>> <s4AxB.1045491$LJ4.896194@fx37.am4>, you actually wrote:
>>
>> long long simply means a type at last as wide as a long.
>>
>> And, on my 64-bit Linux, both long and long long are 64-bit
>> values. But are different types! (So long long* is incompatible with
>> long*.)
>>
>> ("last" was obviously a typo for "least", no big deal)
>>
>> Somebody refuted your original statement, not your later misquotation
>> of it.
And you continue to refuse to acknowledge that, whether intentionally or
not, you substantially altered the meaning of your own quoted words.
The phrase "simply means" made your original statement factually
incorrect. Your later summary of that statement removed that phrase and
made it appear that the modified *correct* statement was the one that
someone had tried to refute.
(As for "long" meaning "twice", someone else made that claim, and IIRC
yet another person may have incorrectly attributed it to you.)
[...]
> What I had a problem with is someone summarily saying "No it isn't."
> without explaining what they meant, suggesting I'm getting it
> (whatever 'it' is ) wrong on purpose, and others not helping by giving
> references to online documents that are supposed to tell which part of
> my statement was wrong instead of just telling me (and a few dozen
> lurkers wandering the same thing). (Actually they didn't help at all.)
I think some of us (including myself) assumed that you would already
know that long long has to be at least 64 bits wide, or at least
that you could very easily find that out by reading the standard.
As one data point, I just now opened my copy of n1570.pdf and did
a search for "long long", starting at the beginning. The second
occurrence is in 5.2.4.2.1 <limits.h>, defining the requirements
on the values of LLONG_MIN and LLONG_MAX, which imply that it must
be at least 64 bits.
Yes, it would have been simpler to say "no, it also has to be at
least 64 bits" in the first place, which I finally did (probably
not in exactly those words). But it can be difficult to figure
out what you actually don't know and what you gloss over because
it doesn't fit into your view that C is too complicated.
--
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 | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-27 19:20 +0100 |
| Message-ID | <f_RyB.939620$HN.232664@fx21.am4> |
| In reply to | #120390 |
On 27/09/2017 18:52, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: > And you continue to refuse to acknowledge that, whether intentionally or > not, you substantially altered the meaning of your own quoted words. Yes, I paraphrased what I'd said; so what? And that was later after aspersions had already been cast on my motives. At that time I had no idea what everyone was so het up about. Perhaps if they'd spelled it out instead of my having to tease that information out of them it wouldn't have go that far. And when I did find what everyone was on about; I just shrugged. Some people like to be pedantic in every single post and cross and dot everything, and some don't think it is necessary. > (As for "long" meaning "twice", someone else made that claim, and IIRC > yet another person may have incorrectly attributed it to you.) Actually, long meaning "twice" would have made far more sense! (In my languages, I don't use 'long' but I use a 'd' prefix - dint and dword - and it means a type exactly double the width. Not just me; assemblers such as Nasm use 'd', 'q' and 'o' to mean double, quad and octo (8 times) respectively. Of course David Brown would argue that even in assembly, you don't really need to know that! And going back a few years to 36-bit, I don't know if there was a term for double (72 bits), but I think we used HALF for an 18 bit half-word. I wonder how easy it would have been if we'd used SHORT, and it meant anything from 18 to 36?) (And I wonder if C's 'double' type is always exactly twice the width of a float? If not, then it has been rather misleadingly named!) > occurrence is in 5.2.4.2.1 <limits.h>, defining the requirements > on the values of LLONG_MIN and LLONG_MAX, which imply that it must > be at least 64 bits. > > Yes, it would have been simpler to say "no, it also has to be at > least 64 bits" in the first place, which I finally did (probably > not in exactly those words). But it can be difficult to figure > out what you actually don't know and what you gloss over because > it doesn't fit into your view that C is too complicated. It's a piece of information I would have seen every so often, then forgotten about or gave no further thought to. Because what's more important is the actual sizes of the types of the implementations I'm likely to use (or to implement). So all I know is that for both Windows and Linux, long long means 64 bits. long is either 32 or 64. And int is 32 for the systems I'm going to be using (except for Arduino where I believe it was 16, as I found out after five minutes). -- bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-27 11:44 -0700 |
| Message-ID | <b6be03ed-a958-4f4e-9597-5b360b30d878@googlegroups.com> |
| In reply to | #120397 |
On Wednesday, September 27, 2017 at 1:21:07 PM UTC-5, Bart wrote: > Actually, long meaning "twice" would have made far more sense! The Standard does not impose any limit on the maximum size of an object. The minimum specified size of "long int" is twice the minimum specified size for "int", and the minimum for "long long int" is twice the minimum specified for "long int".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-28 10:57 +0200 |
| Message-ID | <oqidhf$f6n$1@dont-email.me> |
| In reply to | #120397 |
On 27/09/17 20:20, bartc wrote: > On 27/09/2017 18:52, Keith Thompson wrote: >> bartc <bc@freeuk.com> writes: > >> And you continue to refuse to acknowledge that, whether intentionally or >> not, you substantially altered the meaning of your own quoted words. > > Yes, I paraphrased what I'd said; so what? And that was later after > aspersions had already been cast on my motives. > > At that time I had no idea what everyone was so het up about. Perhaps if > they'd spelled it out instead of my having to tease that information out > of them it wouldn't have go that far. > > And when I did find what everyone was on about; I just shrugged. > > Some people like to be pedantic in every single post and cross and dot > everything, and some don't think it is necessary. > >> (As for "long" meaning "twice", someone else made that claim, and IIRC >> yet another person may have incorrectly attributed it to you.) > > Actually, long meaning "twice" would have made far more sense! > > (In my languages, I don't use 'long' but I use a 'd' prefix - dint and > dword - and it means a type exactly double the width. Not just me; > assemblers such as Nasm use 'd', 'q' and 'o' to mean double, quad and > octo (8 times) respectively. > > Of course David Brown would argue that even in assembly, you don't > really need to know that! Why would you think that? When programming in assembly, you are doing low-level stuff - you want to know the exact sizes you are dealing with. And you use the terminology appropriate for the assembly in question - whether that be "byte, word, dword", or "byte, halfword, word", or whatever. There are many different conventions used by many different assemblers.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-09-24 14:49 -0400 |
| Message-ID | <oq8uon$cs4$1@dont-email.me> |
| In reply to | #120226 |
On 09/24/2017 08:03 AM, David Brown wrote: > On 24/09/17 12:16, bartc wrote: ... > Now, if you have read these two pages and /still/ don't know what a > "long long" is, and why neither "twice as long as long" nor "at least as > wide as long" is a description of the type, then ask again. I promise I > will then give you an explanation. "twice as long as long" is inaccurate, because a conforming implementation can have a "long long" type which violates that specification - but the same is not true about "at least as wide as long". I'm not sure why you imply that those two statements are equally objectionable. Neither is complete, but the second one is both true and important. ... > It does not have types like uint_least27_t for those that want 27 bit > types, but that's because the number of users is going to be rather > small. But the standard says how they should work, if an implementation > wants to provide them. The standard makes precisely as much provision for uint_least27_t as it does for int32_t. Both types are optional, but neither the types nor the corresponding macros can be supported unless the corresponding type is actually supported in the fashion specified by the standard. >> And even in C99 and later, int32_t etc is a poor solution. People want >> to just write 'int' and be able to use "%d" and "INT_MAX". >> > > /You/ might want to do that. Other people are quite happy with writing > "int32_t" and friends. Actually, I'm not. In a new language which had no need to retain backwards compatibility with C89, I'd have preferred simpler names for the size-named types. But, unlike Bartc, I'm willing to understand the necessity of maintaining backwards compatibility, and the corresponding clumsiness in the way that the language has added new features. For instance, we should have had "var" meaning "variable" rather than "const" meaning "constant", because "const" should have been the default - not that I expect Bartc to agree with me about that particular judgment.
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web