Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #75341 > unrolled thread
| Started by | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| First post | 2015-11-08 16:49 +0100 |
| Last post | 2015-11-12 14:39 +0100 |
| Articles | 20 on this page of 181 — 23 participants |
Back to article view | Back to comp.lang.c
Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-08 16:49 +0100
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-08 19:29 +0100
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 11:46 -0800
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-08 20:03 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 12:18 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-08 21:14 +0100
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 12:25 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-08 13:06 -0800
Re: Right C version for GCC Philip Lantz <prl@canterey.us> - 2015-11-08 14:52 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-08 15:12 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 09:38 +0100
Re: Right C version for GCC Nick Bowler <nbowler@draconx.ca> - 2015-11-09 19:04 +0000
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 11:27 -0800
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-09 00:00 +0000
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-08 16:35 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-08 12:37 -0800
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 12:58 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-08 13:19 -0800
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-08 21:49 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 14:14 -0800
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 01:02 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 02:26 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 12:53 +0100
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 15:00 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 08:55 -0800
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 17:07 +0000
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 09:51 -0800
Re: Right C version for GCC jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-09 19:01 +0100
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 19:16 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 11:24 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 20:30 +0100
Re: Right C version for GCC jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-09 20:40 +0100
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 08:56 -0800
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 09:41 -0800
Re: Right C version for GCC gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-09 17:44 +0000
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-09 18:53 +0100
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 18:00 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 10:27 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 11:17 -0800
Re: Right C version for GCC glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-09 22:59 +0000
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 11:15 -0800
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-12 16:47 +0100
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-12 09:24 -0800
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-13 12:54 +0100
Re: Right C version for GCC Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-13 12:01 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-14 10:47 -0800
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-14 21:32 +0100
Re: Right C version for GCC Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-14 16:57 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 11:07 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 20:18 +0100
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 11:27 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 20:41 +0100
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 12:07 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 21:12 +0100
Re: Right C version for GCC glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-09 23:13 +0000
Re: Right C version for GCC James Kuyper <jameskuyper@verizon.net> - 2015-11-09 19:02 -0500
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-10 17:52 +0000
Re: Right C version for GCC glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-10 21:34 +0000
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-17 22:28 +0000
Re: Right C version for GCC glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-18 00:51 +0000
Re: Right C version for GCC James Kuyper <jameskuyper@verizon.net> - 2015-11-17 22:26 -0500
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-18 11:06 +0100
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 15:37 -0800
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-10 12:54 +1300
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 16:14 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 16:37 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 16:56 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 17:25 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 10:37 +0100
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 18:06 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 18:51 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-10 08:40 -0800
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-10 17:55 +0000
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-10 17:50 +0000
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-12 14:32 +0100
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-09 10:35 +0000
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-08 23:57 +0100
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 00:47 +0100
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 13:01 +0100
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 13:18 +0100
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 14:01 +0100
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 00:55 +0000
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-09 10:42 +0000
Re: Right C version for GCC Chad <cdalten@gmail.com> - 2015-11-09 03:03 -0800
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 03:27 -0800
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-09 12:28 +0000
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-10 09:07 +0000
Re: Right C version for GCC James Kuyper <jameskuyper@verizon.net> - 2015-11-09 07:37 -0500
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-09 16:57 +0100
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 12:39 +0100
Re: Right C version for GCC James Kuyper <jameskuyper@verizon.net> - 2015-11-09 13:18 -0500
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 10:49 +0100
Re: Right C version for GCC Les Cargill <lcargill99@comcast.com> - 2015-11-10 19:33 -0600
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-11 13:34 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-11 06:53 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-08 17:00 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 13:37 +0100
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-09 13:53 +0100
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-09 21:54 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 15:45 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 11:14 +0100
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-10 10:53 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-10 03:14 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 13:00 +0100
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-10 12:39 +0000
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 15:11 +0100
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-10 16:16 +0100
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 16:35 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-10 08:54 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 18:56 +0100
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-10 23:27 +0100
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-17 22:32 +0000
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-18 08:44 +0100
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-19 10:43 +0000
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-19 12:29 +0100
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-20 11:01 +0000
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-21 15:50 +0100
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-18 11:13 +0100
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-10 07:25 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 16:42 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-10 08:48 -0800
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-11 01:08 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-11 13:43 +0100
Re: Right C version for GCC Les Cargill <lcargill99@comcast.com> - 2015-11-11 08:27 -0600
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-11 16:27 +0100
Re: Right C version for GCC David Thompson <dave.thompson2@verizon.net> - 2015-12-06 07:57 -0500
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-12-06 22:34 +0100
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 22:41 +0000
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-12-07 09:47 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-12-07 07:30 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-12-07 17:30 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-12-07 10:17 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-12-07 21:29 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-12-07 13:16 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-12-07 23:35 +0100
Re: Right C version for GCC jadill33@gmail.com - 2015-12-07 10:41 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-12-07 21:35 +0100
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-08 20:11 +0000
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-09 09:57 +1300
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 13:06 -0800
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-09 10:16 +1300
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-08 22:59 +0100
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-09 12:13 +1300
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 00:43 +0100
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-09 13:00 +1300
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 12:02 +0100
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 09:00 -0800
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-10 07:25 +1300
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 19:35 +0100
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-10 08:55 +1300
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 21:00 +0100
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-10 09:04 +1300
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 21:11 +0100
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 20:18 +0000
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 21:21 +0100
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-10 09:30 +1300
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 12:53 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 12:30 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 13:02 -0800
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-09 21:35 +0000
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 14:41 -0800
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-09 23:31 +0000
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 16:33 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 11:16 +0100
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-11 08:04 +1300
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-10 18:04 +0000
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-10 18:03 +0000
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-11 08:23 +1300
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 13:41 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-08 13:24 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-08 23:00 +0100
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 15:18 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 00:35 +0100
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-08 17:03 -0800
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-09 12:42 +0000
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-08 17:51 -0800
Re: Right C version for GCC Les Cargill <lcargill99@comcast.com> - 2015-11-09 12:20 -0600
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 19:36 +0100
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-09 18:47 +0000
Re: Right C version for GCC Stephen Sprunk <stephen@sprunk.org> - 2015-11-11 00:55 -0600
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-12 14:39 +0100
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-09 14:41 -0800 |
| Message-ID | <417e4cc0-5b2f-4b01-8911-f3cd27dc48d1@googlegroups.com> |
| In reply to | #75518 |
On Monday, November 9, 2015 at 3:36:09 PM UTC-6, Bart wrote:
> In another language (not C), I used a simple mechanism to alias fields;
> C-style:
>
> struct {
> int a, b, c;
> int x @ b;
> }
I've long thought the usefulness of bitfields could be enormously improved
if there were a way of defining a bitfield alias to a specified part of
another field in the structure. As it is, the Standard specifies the layout
of bitfields with enough detail to forbid what would otherwise be some useful
layouts (e.g. a three-byte structure holding eight 3-bit fields) but not
enough to let code do much of anything it couldn't do if the spec had left
the layout up to the implementation.
> Probably a good thing. After a few minutes I still had no idea of what
> this was trying to do. But it also stops the compiler picking up error
> of using the wrong field: suppose you had objects P (an xy struct), and
> Q (a sample struct), but mistakenly wrote Q.x instead of P.x; that bug
> would get through.
I don't think that would be any more probable than with any other kind of
structures. I should have been clearer about the intended usage case:
there exists a structure like:
typedef struct { int x,y; char *z; } FOO;
Later a need emerges to be able to be able to pass a pointer to that struct
to code that only needs to work with x and y, and also needs to accommodate
structures that only have x and y. One approach would be to define a new
structure type
typedef struct { int x,y; } XY_ONLY;
and redefine foo as
typedef struct { xy_only xy; char *z; } FOO;
and then replace all instances of foo.x and foo.y with foo.xy.x and foo.xy.y,
but that seems rather unattractive. Another approach would be to define a
union:
typedef union {
XY_ONLY xy;
struct { int x,y; char *z; };
} FOO;
but that is relying upon the x and y fields of FOO to alias with the
corresponding fields of a type xy which are declared elsewhere. That
would be specified to work as long as both types list the same types
of fields in the same order, but would be rather brittle; it's also
not compatible with older compilers.
What I'd like to see would be a means of saying, basically, "allow this
group of fields to either be used as a structure, or as independent fields
in the containing type".
> Also, what happens if struct sample also has a field called "x"? More
> importantly, suppose that after you've got lots of code that uses .x on
> sample structs, that struct now acquires its own .x field? Would use of
> 'default' now be an error? Trouble is that you (and possibly dozens of
> other people) how now got a pile of code that needs to be revised!
As I would propose things, the "default" keyword would be ignored except
when the compiler encounters a situation where a struct is used in a
syntactically-invalid fashion. In that case, the compiler would try to
insert ".name" with the name of each default-tagged field to see if the
result would be syntactically valid. If there is exactly one field where
the substitution works, the compiler would proceed from there. If there
are none, or more than one, the syntax error would remain.
With regard to "what would happen if names get duplicated"--the purpose of
the feature would be to avoid the need to duplicate the contents of the inner
type as an anonymous structure within a union. In the event that naming
conflicts would prevent the use of the feature in that way, code could still
use a union to alias a named structure with an anonymous structure that
included the desired field names, but in most cases being able to have
structure fields exposed into the outer type would be less inelegant.
BTW, another place this feature could be helpful would be if bitfields could
be aliased to one or more parts of other fields and could also be usable as
"default", then it would be possible to say:
typedef struct {
unsigned char b0,b1,b2,b3;
signed default value @ {b3.0:8, b2.0:8, b1.0:8, b0.0:8};
} big_endian_32;
and then use big_endian_32 as a big-endian 32-bit value whose storage layout
would be rigidly defined regardless of machine endian-ness or the number
of bits in "char" [if "char" is 16 bits, then "big_endian_32" would use the
lower 8 bits of each of four "char" values]. Such types would make it
possible to use code written for machines with one memory layout on platforms
with another. The resulting program might not run wonderfully efficiently,
but in situations where ease of porting matters more than execution speed
such types could be very useful.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-09 23:31 +0000 |
| Message-ID | <n1ra83$s2o$1@dont-email.me> |
| In reply to | #75522 |
On 09/11/2015 22:41, supercat@casperkitty.com wrote:
> On Monday, November 9, 2015 at 3:36:09 PM UTC-6, Bart wrote:
>> In another language (not C), I used a simple mechanism to alias fields;
>> C-style:
>>
>> struct {
>> int a, b, c;
>> int x @ b;
>> }
>
> I've long thought the usefulness of bitfields could be enormously improved
> if there were a way of defining a bitfield alias to a specified part of
> another field in the structure. As it is, the Standard specifies the layout
> of bitfields with enough detail to forbid what would otherwise be some useful
> layouts (e.g. a three-byte structure holding eight 3-bit fields) but not
> enough to let code do much of anything it couldn't do if the spec had left
> the layout up to the implementation.
I've never used bitfields in C and have never implemented them in a
C-class language, as they are tricky.
But also I believe it is better, as bitfields in structs are a rather
narrow area, to have more bit and bitfield operations in the language.
Ones that go beyond the shifting and masking that are usually necessary.
So, instead of:
struct {
int a:1;
int b:1;
int c:2;
int d:4;
} x;
with the bitfields taking up one byte, you could simply have:
char x; // if there are no other non-bit fields
To access the 'a' field, the syntax might be:
x.[0] // bit 0
and for d, it could be:
x.[4..7] // or x.[7..4], yielding a value 0..15
Of course you'd use #defines to replace 0 and 4..7.
The advantage is that this works across the language, and not just the
odd field in a struct. And the same byte or int can be reinterpreted in
different ways.
> I should have been clearer about the intended usage case:
> there exists a structure like:
>
> typedef struct { int x,y; char *z; } FOO;
>
> Later a need emerges to be able to be able to pass a pointer to that struct
> to code that only needs to work with x and y, and also needs to accommodate
> structures that only have x and y. One approach would be to define a new
> structure type
>
> typedef struct { int x,y; } XY_ONLY;
>
> and redefine foo as
>
> typedef struct { xy_only xy; char *z; } FOO;
You're starting to lose me again. Why redefine foo? Leave FOO as
(x,y,*z) and XY_ONLY as (x,y). Then you can continue to use P.x or P.y
whether P is a FOO or a XY_ONLY.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-09 16:33 -0800 |
| Message-ID | <391889da-4925-49f9-9183-37a652dac56e@googlegroups.com> |
| In reply to | #75531 |
On Monday, November 9, 2015 at 5:31:32 PM UTC-6, Bart wrote: > To access the 'a' field, the syntax might be: > > x.[0] // bit 0 > > and for d, it could be: > > x.[4..7] // or x.[7..4], yielding a value 0..15 > > Of course you'd use #defines to replace 0 and 4..7. Using #define macros for such things is nasty because macro substitutions are processed without regard for context. Otherwise, one would need to use something like: x.FOO_Q = 23; rather than just x.q=23; > The advantage is that this works across the language, and not just the > odd field in a struct. And the same byte or int can be reinterpreted in > different ways. Bit-field aliases would achieve the same thing. > You're starting to lose me again. Why redefine foo? Leave FOO as > (x,y,*z) and XY_ONLY as (x,y). Then you can continue to use P.x or P.y > whether P is a FOO or a XY_ONLY. Because of a rather annoying rule which should never have been part of any version of C, even though fields x and y are guaranteed to have the same layout in both FOO and XY_ONLY, a compiler is allowed to do anything it likes with code that uses a variable as a FOO and then passes a pointer to it to something that uses it as an XY_ONLY, unless one type contains the other. Since XY_ONLY can't contain FOO, the only legitimate ways defined by the Standard to achieve defined behavior would be to either: 1. Have code which receives the pointer use memcpy() to copy the data to an object of type XY_ONLY, which would be rather annoying and clunky. 2. Define "FOO" in such a way as to contain a structure of type XY_ONLY. To be sure, one might argue that a more practical approach than either of those is (3) use a compiler which can be made to behave as though the rule in question never existed, but if the authors of the Standard want people to actually follow the standard, they should make it possible to write practical conforming code.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-10 11:16 +0100 |
| Message-ID | <n1sg22$38q$2@dont-email.me> |
| In reply to | #75504 |
On 09/11/15 21:04, Ian Collins wrote: > Morten W. Petersen wrote: >> On 09.11.2015 20:55, Ian Collins wrote: >>> I wouldn't worry about Microsoft, their aim of C++14 compliance will >>> bring their compiler a lot closer to C99 compliance. >> >> Yeah, well I just hope it isn't difficult to support their compiler, >> seeing how they've played games before and wasted a lot of developer >> time. > > They are publicly and practically committed to C++14 compliance. > I believe they are also now shipping clang in order to get modern C11 compliance too.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-11-11 08:04 +1300 |
| Message-ID | <daetd4F7r8hU1@mid.individual.net> |
| In reply to | #75564 |
David Brown wrote: > On 09/11/15 21:04, Ian Collins wrote: >> Morten W. Petersen wrote: >>> On 09.11.2015 20:55, Ian Collins wrote: > >>>> I wouldn't worry about Microsoft, their aim of C++14 compliance will >>>> bring their compiler a lot closer to C99 compliance. >>> >>> Yeah, well I just hope it isn't difficult to support their compiler, >>> seeing how they've played games before and wasted a lot of developer >>> time. >> >> They are publicly and practically committed to C++14 compliance. >> > > I believe they are also now shipping clang in order to get modern C11 > compliance too. Well the clang front end at least. They have managed to marry the clang front end with their code generating back end. An elegant solution in my opinion. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-10 18:04 +0000 |
| Message-ID | <5642319a.11998843@news.xs4all.nl> |
| In reply to | #75504 |
Ian Collins <ian-news@hotmail.com> wrote: > Morten W. Petersen wrote: > > On 09.11.2015 20:55, Ian Collins wrote: > >> I wouldn't worry about Microsoft, their aim of C++14 compliance will > >> bring their compiler a lot closer to C99 compliance. > > > > Yeah, well I just hope it isn't difficult to support their compiler, > > seeing how they've played games before and wasted a lot of developer > > time. > > They are publicly and practically committed to C++14 compliance. They were also publicly and practically committed to HTML compliance. Richard
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-10 18:03 +0000 |
| Message-ID | <5642310a.11855296@news.xs4all.nl> |
| In reply to | #75501 |
Ian Collins <ian-news@hotmail.com> wrote: > I wouldn't worry about Microsoft, their aim of C++14 compliance I find your lack of scepticism disturbing. Richard
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-11-11 08:23 +1300 |
| Message-ID | <daeuhaF7r8hU2@mid.individual.net> |
| In reply to | #75644 |
Richard Bos wrote: > Ian Collins <ian-news@hotmail.com> wrote: > >> I wouldn't worry about Microsoft, their aim of C++14 compliance > > I find your lack of scepticism disturbing. It is based on the people involved in the project, not the company. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-09 13:41 +0100 |
| Message-ID | <n1q45e$scs$1@dont-email.me> |
| In reply to | #75385 |
On 08/11/15 22:59, Morten W. Petersen wrote: > On 08.11.2015 22:16, Ian Collins wrote: >> Malcolm McLean wrote: >>> On Sunday, November 8, 2015 at 8:57:14 PM UTC, Ian Collins wrote: >>>> >>>> Just stick with contemporary C (C99), there's a very slim chance anyone >>>> will want an XML parser on a system without a C99 compiler. >>>> >>> The chance that someone will want to drop an XML parser into a >>> Microsoft Visual Studio program is pretty high. You can of course >>> obtain an C99 compiler for Windows. But unless the XML parser is >>> a vital core component, a developer will be unwilling to switch >>> compilers just so he can use one XML system. >> >> His code as it stands won't compile as C90, but with one minor nit, it >> does as C99. It also contains at least one POSIX function (fileno). > > Well I'm aware of fileno, it triggers a warning. But what other nit > did you find? > > I downloaded a VirtualBox image of CentOS 6.6, which has an older GCC > version, this made me aware of the issues with nested structures, and > I don't quite like surprises like that. > A key issue is that you are referring to /unnamed/, or /anonymous/ nested structures. These were only standardised in C11 - but have been available as an extension in gcc since its early days. So this has nothing to do with the version of gcc you are using, but the "-pedantic" flag.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-08 13:24 -0800 |
| Message-ID | <f36a287a-0e65-412b-afe5-f0714e5216ca@googlegroups.com> |
| In reply to | #75374 |
On Sunday, November 8, 2015 at 3:06:17 PM UTC-6, Malcolm McLean wrote: > On Sunday, November 8, 2015 at 8:57:14 PM UTC, Ian Collins wrote: > > > > Just stick with contemporary C (C99), there's a very slim chance anyone > > will want an XML parser on a system without a C99 compiler. > > > The chance that someone will want to drop an XML parser into a > Microsoft Visual Studio program is pretty high. A number of the features that were added in C99 have been incorporated into many compilers which do not support all of C99, including the "fixed-size- but- not-fixed-meaning" integer types and the "//" comments. Given that code can generally provide its own emulation of the integer types if needed and that "//" are widely supported, I see no reason for code to avoid using those even though other features of C99 like the ability to define types with non-constant sizes are not as widely supported.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-11-08 23:00 +0100 |
| Message-ID | <n1oglu$5vo$2@speranza.aioe.org> |
| In reply to | #75374 |
On 08.11.2015 22:06, Malcolm McLean wrote: > On Sunday, November 8, 2015 at 8:57:14 PM UTC, Ian Collins wrote: >> >> Just stick with contemporary C (C99), there's a very slim chance anyone >> will want an XML parser on a system without a C99 compiler. >> > The chance that someone will want to drop an XML parser into a > Microsoft Visual Studio program is pretty high. You can of course > obtain an C99 compiler for Windows. But unless the XML parser is > a vital core component, a developer will be unwilling to switch > compilers just so he can use one XML system. Does Visual C / Studio support specifying the version of C used? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-08 15:18 -0800 |
| Message-ID | <89acaee3-4f87-4115-95fe-63ec34a84b55@googlegroups.com> |
| In reply to | #75386 |
On Sunday, November 8, 2015 at 10:00:45 PM UTC, Morten W. Petersen wrote: > On 08.11.2015 22:06, Malcolm McLean wrote: > > Does Visual C / Studio support specifying the version of C used? > Essentially no. There are various flags you can pass, but there's no equivalent of gcc -std.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-11-09 00:35 +0100 |
| Message-ID | <n1om7v$i9u$1@speranza.aioe.org> |
| In reply to | #75400 |
On 09.11.2015 00:18, Malcolm McLean wrote: > On Sunday, November 8, 2015 at 10:00:45 PM UTC, Morten W. Petersen wrote: >> On 08.11.2015 22:06, Malcolm McLean wrote: >> >> Does Visual C / Studio support specifying the version of C used? >> > Essentially no. There are various flags you can pass, but there's > no equivalent of gcc -std. OK. Well I guess that narrows the "common subset" down further, my approach will be to build according to C90 and for now enable the extension that enables nested unions/structs to ease the development and debugging until things have been hashed out. I feel OK about that, as there are tests now and will be many more, so any accidental breakage changing the internal storage structure should be caught. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-08 17:03 -0800 |
| Message-ID | <lnpozkyoe9.fsf@kst-u.example.com> |
| In reply to | #75400 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Sunday, November 8, 2015 at 10:00:45 PM UTC, Morten W. Petersen wrote:
>> On 08.11.2015 22:06, Malcolm McLean wrote:
>>
>> Does Visual C / Studio support specifying the version of C used?
>>
> Essentially no. There are various flags you can pass, but there's
> no equivalent of gcc -std.
Presumably that's because it doesn't support any standard other than
C89/C90.
--
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 | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-11-09 12:42 +0000 |
| Message-ID | <slrnn4156i.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #75413 |
On Mon, 2015-11-09, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> On Sunday, November 8, 2015 at 10:00:45 PM UTC, Morten W. Petersen wrote: >>> On 08.11.2015 22:06, Malcolm McLean wrote: >>> >>> Does Visual C / Studio support specifying the version of C used? >>> >> Essentially no. There are various flags you can pass, but there's >> no equivalent of gcc -std. > > Presumably that's because it doesn't support any standard other than > C89/C90. With gcc, -std is also a way to say "please disable any compiler-specific extensions to the language". Like gcc, the MS compilers have such extensions, so they /could/ have made use of such an option. But presumably there are other ways to control that. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-08 17:51 -0800 |
| Message-ID | <lnh9kwym6t.fsf@kst-u.example.com> |
| In reply to | #75341 |
"Morten W. Petersen" <morphex@gmail.com> writes:
> OK, so I'm inching along on my XML parser Smash XML, and thought
> I'd give developing on CentOS a go.
>
> I quickly ran into problems there though, as gcc wouldn't accept
> the -std=c90 command line argument. I glanced at the man page and
> found that -ansi could be an option.
In recent versions of gcc, the options '-ansi', '-std=c89', '-std=c90',
and '-std=iso9899:1990' are all equivalent. (1989 was the publication
date of the original ANSI standard; 1990 was the date of the equivalent
ISO standard that officially replaced it.)
Earlier versions of gcc didn't have '-std=90'. The '-ansi' spelling is
probably the oldest and therefore most portable. (The name is strictly
speaking a misnomer, since ANSI has officially adopted the 2011 ISO C
standard, but the 1989/1990 standard is still commonly referred to as
"ANSI C".)
> But when using -ansi, the compiler doesn't recognize the nested
> struct elements.. the man page says that turning on -ansi shuts
> down some GCC extensions that conflict with C90, so GCC has some
> non-standard ways of defining structs then I assume.
>
> How can I handle this?
Read the section gcc manual that discusses standards (section 2).
Each "-std=cNN" option has a corresponding "-std=gnuNN" option that
implements the specified standard plus GNU-specific extensions.
I see you're using the fileno function. That's defined by POSIX,
not by C. If you get a warning about an implicit declaration then
you're compiling in a mode in which it's not declared, which is a
bad idea. Read the manual for "fileno" to find out how to enable it.
For example:
gcc -ansi -D_POSIX_SOURCE
is likely to work.
As for nested structures, it's not clear what you mean. Defining
structures as members of other structures is perfectly portable,
and you shouldn't get a warning about. *Anonymous* structures are
a common extension, and are fully supported in C11. If you want to
write portable code, replace any anonymous structures by explicitly
named structures.
> Project code, today's version, is here:
>
> https://github.com/morphex/smash_xml/tree/1fade93c3f69f14ef90860f88f99170bfc37bfb7
>
> -Morten
--
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 | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-11-09 12:20 -0600 |
| Message-ID | <n1qnp5$ctr$1@dont-email.me> |
| In reply to | #75341 |
Morten W. Petersen wrote:
> Hi there. :)
>
> OK, so I'm inching along on my XML parser Smash XML, and thought
> I'd give developing on CentOS a go.
>
> I quickly ran into problems there though, as gcc wouldn't accept
> the -std=c90 command line argument. I glanced at the man page and
> found that -ansi could be an option.
>
> But when using -ansi, the compiler doesn't recognize the nested
> struct elements.. the man page says that turning on -ansi shuts
> down some GCC extensions that conflict with C90, so GCC has some
> non-standard ways of defining structs then I assume.
>
> How can I handle this?
>
> Project code, today's version, is here:
>
> https://github.com/morphex/smash_xml/tree/1fade93c3f69f14ef90860f88f99170bfc37bfb7
>
>
> -Morten
You can completely and very safely drop the use of nested struct/union
declarations from your codebase and you won't have to worry as
much about toolchains any more.
Rather than:
typedef struct {
...
typedef struct b {
} x;
...
} a;
you can:
typedef struct {
...
} b;
typedef struct {
...
b x;
...
} a;
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-11-09 19:36 +0100 |
| Message-ID | <n1qp2k$cq6$2@speranza.aioe.org> |
| In reply to | #75475 |
On 09.11.2015 19:20, Les Cargill wrote:
[...]
> You can completely and very safely drop the use of nested struct/union
> declarations from your codebase and you won't have to worry as
> much about toolchains any more.
>
>
> Rather than:
>
> typedef struct {
> ...
> typedef struct b {
> } x;
> ...
> } a;
>
> you can:
>
> typedef struct {
> ...
> } b;
> typedef struct {
>
> ...
> b x;
> ...
> } a;
Ah yes, I was wondering how I could do that, and I'll give this a go.
-Morten
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-09 18:47 +0000 |
| Message-ID | <n1qpkc$l2n$1@dont-email.me> |
| In reply to | #75475 |
On 09/11/2015 18:20, Les Cargill wrote:
> You can completely and very safely drop the use of nested struct/union
> declarations from your codebase and you won't have to worry as
> much about toolchains any more.
>
>
> Rather than:
>
> typedef struct {
> ...
> typedef struct b {
> } x;
> ...
> } a;
That's a nested typedef, which I don't think is allowed anyway.
Actual nested structs and unions (defined within another struct or
union), I rarely used if they are named. As you say, you just define the
struct or union outside (although it will need a tag, or be wrapped in a
typedef).
But anonymous structs and unions I use all the time, and those are more
difficult to more outside.
BartC
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-11-11 00:55 -0600 |
| Message-ID | <n1uoku$5rl$1@dont-email.me> |
| In reply to | #75341 |
On 08-Nov-15 09:49, Morten W. Petersen wrote: > OK, so I'm inching along on my XML parser Smash XML, and thought I'd > give developing on CentOS a go. > > I quickly ran into problems there though, as gcc wouldn't accept the > -std=c90 command line argument. I glanced at the man page and found > that -ansi could be an option. GCC 4.5.x added "-std=c90" as an alias for "-std=c89" (or "-ansi") accepted by previous versions. > But when using -ansi, the compiler doesn't recognize the nested > struct elements.. the man page says that turning on -ansi shuts > down some GCC extensions that conflict with C90, so GCC has some > non-standard ways of defining structs then I assume. Some GCC extensions are available with "-std=cXX" as long as you don't also use "-pedantic"; others are only available with "-std=gnuXX". It's also possible that your (apparently rather old) GCC has a bug. > How can I handle this? First, decide exactly what flavor of C you're targeting. Once you know that, how to get GCC to help you do so should be fairly obvious. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web