Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #65653 > unrolled thread
| Started by | doctor@doctor.nl2k.ab.ca (The Doctor) |
|---|---|
| First post | 2015-07-15 20:40 +0000 |
| Last post | 2015-07-16 09:55 +1200 |
| Articles | 20 on this page of 182 — 21 participants |
Back to article view | Back to comp.lang.c
SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-15 20:40 +0000
Re: SQL filesortcc question Paavo Helde <myfirstname@osa.pri.ee> - 2015-07-15 16:08 -0500
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-15 17:15 -0400
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-15 23:22 +0000
Re: SQL filesortcc question jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-16 18:35 +0200
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-16 17:48 +0100
Re: SQL filesortcc question jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-16 19:38 +0200
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 19:48 +0000
Re: SQL filesortcc question jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-16 22:17 +0200
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-16 21:44 +0100
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 23:51 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-17 09:05 +1200
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 23:52 +0000
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-17 11:36 -0400
Re: SQL filesortcc question The Doctor <doctor@doctor.nl2k.ab.ca> - 2015-07-17 22:22 +0000
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-17 18:44 -0400
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-18 11:13 +1200
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-16 22:06 +0100
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 23:52 +0000
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:24 +0100
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-17 00:26 +0000
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 23:50 +0000
Re: SQL filesortcc question John Bode <jfbode1029@gmail.com> - 2015-07-31 13:39 -0700
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 19:48 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-17 09:07 +1200
Re: SQL filesortcc question Philip Lantz <prl@canterey.us> - 2015-07-16 16:05 -0700
Re: SQL filesortcc question David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:28 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 11:13 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-20 19:27 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-21 08:46 +1200
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-07-22 15:12 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 11:55 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 15:01 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 11:51 +1200
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 10:02 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-27 23:35 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-28 14:16 +1200
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-28 04:49 +0100
Re: SQL filesortcc question Martin Shobe <martin.shobe@yahoo.com> - 2015-07-27 23:25 -0500
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-07-28 09:32 +0000
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-28 10:22 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-27 22:33 -0400
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-28 04:57 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-28 16:38 +1200
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-28 00:51 -0400
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-28 07:06 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-28 20:32 +1200
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-28 10:02 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-28 22:08 +1200
Re: SQL filesortcc question David Kleinecke <dkleinecke@gmail.com> - 2015-07-28 18:17 -0700
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-29 12:14 -0400
Re: SQL filesortcc question Martin Shobe <martin.shobe@yahoo.com> - 2015-07-29 11:27 -0500
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-29 13:01 -0400
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-29 17:33 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-29 21:07 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-29 16:33 -0400
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-29 22:12 +0100
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-29 23:50 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 00:13 +0100
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-30 01:49 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 02:07 +0100
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-30 03:04 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 08:25 +0100
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-07-30 09:15 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 17:17 +0100
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-30 17:00 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 17:12 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-30 15:12 -0400
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-30 23:13 -0700
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-31 10:29 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-31 08:10 -0400
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-31 11:12 -0700
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-31 22:56 +0100
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-31 18:34 -0700
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-01 13:55 +0100
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 07:13 -0700
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-01 15:36 +0100
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 09:19 -0700
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-08-01 18:16 -0400
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 15:30 -0700
Re: SQL filesortcc question Richard Damon <Richard@Damon-Family.org> - 2015-08-02 09:00 -0400
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-08-02 09:19 -0400
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-08-09 14:23 +0000
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-02 06:35 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-02 19:11 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-02 10:28 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-03 09:04 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-03 00:19 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-03 13:55 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-03 07:03 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-03 16:53 +0200
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 09:19 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-09-06 21:20 +0200
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 14:07 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-09-06 12:24 +0200
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 13:49 +0100
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-09-06 15:41 +0200
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-07 07:24 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-09-07 17:04 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-02 06:48 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 08:00 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 08:52 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 11:56 -0700
Re: SQL filesortcc question Richard Damon <Richard@Damon-Family.org> - 2015-08-04 23:45 -0400
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-08-05 08:45 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 12:00 -0700
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-08-01 13:17 -0700
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-08-01 16:11 -0400
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 14:00 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-08-02 10:40 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 16:20 -0700
Re: SQL filesortcc question Rosario19 <Ros@invalid.invalid> - 2015-08-22 08:24 +0200
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-08-22 19:26 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-22 05:39 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 13:51 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-08-02 10:38 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 16:14 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-02 01:15 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 16:24 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-02 02:32 +0200
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-08-02 12:57 +1200
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-08-01 22:23 -0700
Re: SQL filesortcc question Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 01:21 -0500
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-02 19:21 +0200
Re: SQL filesortcc question Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 14:05 -0500
Re: SQL filesortcc question Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 01:24 -0500
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 23:56 -0700
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-08-09 14:25 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-30 14:19 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-29 19:53 -0700
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-07-29 23:45 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-30 04:22 -0700
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 13:13 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 13:27 +0100
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 13:57 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 14:11 +0100
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 14:39 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 15:05 +0100
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 14:03 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-30 11:22 -0400
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-07-29 18:32 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-30 14:38 +1200
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-30 10:56 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-30 22:28 +1200
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 10:57 +0100
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-03 08:02 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-03 08:33 -0700
Re: SQL filesortcc question Richard Damon <Richard@Damon-Family.org> - 2015-08-03 20:50 -0400
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 04:52 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 06:08 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 14:20 +0100
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 06:45 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 12:15 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-08-03 19:09 +0100
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 06:09 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 14:40 +0100
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 13:24 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-09-05 21:51 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-09-05 17:16 -0400
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-09-05 19:59 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-09-06 07:51 +0100
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 17:32 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 10:04 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-07-21 13:23 +0200
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-07-22 15:14 +0000
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 15:25 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 11:31 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 17:10 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 13:29 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 23:51 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 20:24 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 03:02 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-27 09:22 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 15:04 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-27 10:32 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 16:49 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-27 21:46 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-27 04:53 -0700
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-07-26 14:58 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 15:15 -0700
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 19:47 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-16 09:55 +1200
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-04 08:00 -0700 |
| Message-ID | <kfnvbcv6qvd.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66687 |
Richard Damon <Richard@Damon-Family.org> writes: > [snip] > > Use of uint8_t when not needed is a problem. This statement I agree with. > It make the program not > compile if CHAR_BIT isn't 8, but maybe that is a good thing, as > someone who uses uint8_t instead of unsigned char when they don't need > to likely has a lot of other portability issues hiding in their code. I can't really agree with this. It's like saying two wrongs make a right. If a program depends on CHAR_BIT == 8 that should be tested explicitly in a pre-processor conditional (or static assertion if that is one's preference), and any developer who neglects to do so should be boiled in oil during code review (metaphorically speaking, of course). Also it promotes the idea that CHAR_BIT == 8 implies that uint8_t must be present, which is not a valid conclusion. > Now since uint8_t is just a typedef for unsigned char (not said > directly in the standard, but it seems to follow by necessity), no > cast is needed between the two types, or pointers to them. The Standard does not require, either directly or indirectly, that uint8_t by the same type as unsigned char, even in cases where CHAR_BIT == 8 and where uint8_t is supplied by the implementation (which again is not necessarily so). This is possible by having uint8_t be an extended integer type rather than a synonym for unsigned char, and there are at least a couple of reasons why one might want to do that, to wit, to provide more stringent type checking, and to present more optimization opportunities (and potential perfomance improvements) by virtue of reducing the set of aliasing constraints. The character types occupy a distinguished position among the set of C integer types; it's a bad idea to treat any type name as a synonym for a character type unless it is guaranteed to be a synonym for one of the character types. That is not the case for any of the types in <stdint.h>.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-04 08:52 -0700 |
| Message-ID | <638f8d92-bf41-4079-b460-6d7c1e74d9a4@googlegroups.com> |
| In reply to | #66859 |
On Tuesday, August 4, 2015 at 4:00:18 PM UTC+1, Tim Rentsch wrote: > Richard Damon <Richard@Damon-Family.org> writes: > > > [snip] > > > > Use of uint8_t when not needed is a problem. > > This statement I agree with. > > > It make the program not > > compile if CHAR_BIT isn't 8, but maybe that is a good thing, as > > someone who uses uint8_t instead of unsigned char when they don't need > > to likely has a lot of other portability issues hiding in their code. > > I can't really agree with this. It's like saying two wrongs make > a right. If a program depends on CHAR_BIT == 8 that should be > tested explicitly in a pre-processor conditional (or static > assertion if that is one's preference), and any developer who > neglects to do so should be boiled in oil during code review > (metaphorically speaking, of course). Also it promotes the > idea that CHAR_BIT == 8 implies that uint8_t must be present, > which is not a valid conclusion. > The tiff loader returns unsigned char *rgba. So we've got (currently) red, green, and blue channels in the range 0-255, and place to put alpha when the that support goes in. Obviously the scheme is#designed with CHAR_BIT 8 machines in mind. But if CHAR_BIT isn't 8, what should be do? You can argue that if CHAR_BIT is 32, then we should be returning a single width*height array, with the pixels packed. But that would make the code quite fiddly. Should it fail if CHAR_BIT is not 8? On the face of it, that doesn't seem very sensible. Sure it's better to waste a bit of space than to refuse to load an image at all. But, what if there's a bug in my code, such that when CHAR_BIT isn't 8, some of the channels go above 255? There's a missing &? We can check that by exhaustively testing with CHAR_BIT 32 and so on machines. But I don't have such a machine available, we're completely dependent on someone who doe shave such a machine taking an interest in the project and running the tests for us. Now, what's worse, to refuse to load an image at all, or to return an image with some of the pixel values over 255? There's not an easy answer to that. Is the tiff loader being used in medical imaging attached to an automatic surgery machine, or for a video game? We don't know, there is no answer, but the more cautious strategy is to break the compile. > > The Standard does not require, either directly or indirectly, > that uint8_t by the same type as unsigned char, even in cases > where CHAR_BIT == 8 and where uint8_t is supplied by the > implementation (which again is not necessarily so). This is > possible by having uint8_t be an extended integer type rather > than a synonym for unsigned char, and there are at least a couple > of reasons why one might want to do that, to wit, to provide more > stringent type checking, and to present more optimization > opportunities (and potential perfomance improvements) by virtue > of reducing the set of aliasing constraints. The character types > occupy a distinguished position among the set of C integer types; > it's a bad idea to treat any type name as a synonym for a > character type unless it is guaranteed to be a synonym for one of > the character types. That is not the case for any of the types > in <stdint.h>. > There's a tension between keeping the number of types down and making it easier to no-alias. It's also an unfortunate historical accident what should be "byte" is called "unsigned char".There's also the trap representation issue, again, most people aren't very aware of it because such platforms are rare. But for practical purposes, uint8_t and unsigned char can stand in for each other. You'll use one of the two for bit buffers.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-05 11:56 -0700 |
| Message-ID | <kfnio7owv80.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66866 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Tuesday, August 4, 2015 at 4:00:18 PM UTC+1, Tim Rentsch wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> [snip]
>>>
>>> Use of uint8_t when not needed is a problem.
>>
>> This statement I agree with.
>>
>>> It make the program not
>>> compile if CHAR_BIT isn't 8, but maybe that is a good thing, as
>>> someone who uses uint8_t instead of unsigned char when they don't need
>>> to likely has a lot of other portability issues hiding in their code.
>>
>> I can't really agree with this. It's like saying two wrongs make
>> a right. If a program depends on CHAR_BIT == 8 that should be
>> tested explicitly in a pre-processor conditional (or static
>> assertion if that is one's preference), and any developer who
>> neglects to do so should be boiled in oil during code review
>> (metaphorically speaking, of course). Also it promotes the
>> idea that CHAR_BIT == 8 implies that uint8_t must be present,
>> which is not a valid conclusion.
[some extra blank lines added]
>
> The tiff loader returns unsigned char *rgba. So we've got
> (currently) red, green, and blue channels in the range 0-255, and
> place to put alpha when the that support goes in. Obviously the
> scheme is designed with CHAR_BIT 8 machines in mind.
>
> But if CHAR_BIT isn't 8, what should be do? You can argue that if
> CHAR_BIT is 32, then we should be returning a single width*height
> array, with the pixels packed. But that would make the code quite
> fiddly. Should it fail if CHAR_BIT is not 8? On the face of it,
> that doesn't seem very sensible. Sure it's better to waste a bit of
> space than to refuse to load an image at all.
>
> But, what if there's a bug in my code, such that when CHAR_BIT isn't
> 8, some of the channels go above 255? There's a missing &? We can
> check that by exhaustively testing with CHAR_BIT 32 and so on
> machines. But I don't have such a machine available, we're
> completely dependent on someone who doe shave such a machine taking
> an interest in the project and running the tests for us.
>
> Now, what's worse, to refuse to load an image at all, or to return
> an image with some of the pixel values over 255? There's not an
> easy answer to that. Is the tiff loader being used in medical
> imaging attached to an automatic surgery machine, or for a video
> game? We don't know, there is no answer, but the more cautious
> strategy is to break the compile.
Do this:
#include <limits.h>
#if CHAR_BIT != 8
#error Sorry, jughead - I need CHAR_BIT == 8
#endif
Adding these four lines of code to any .c file that depends
on CHAR_BIT == 8 will prevent successful compilation.
>> The Standard does not require, either directly or indirectly,
>> that uint8_t by the same type as unsigned char, even in cases
>> where CHAR_BIT == 8 and where uint8_t is supplied by the
>> implementation (which again is not necessarily so). This is
>> possible by having uint8_t be an extended integer type rather
>> than a synonym for unsigned char, and there are at least a couple
>> of reasons why one might want to do that, to wit, to provide more
>> stringent type checking, and to present more optimization
>> opportunities (and potential perfomance improvements) by virtue
>> of reducing the set of aliasing constraints. The character types
>> occupy a distinguished position among the set of C integer types;
>> it's a bad idea to treat any type name as a synonym for a
>> character type unless it is guaranteed to be a synonym for one of
>> the character types. That is not the case for any of the types
>> in <stdint.h>.
>
> There's a tension between keeping the number of types down and
> making it easier to no-alias. It's also an unfortunate historical
> accident what should be "byte" is called "unsigned char".There's
> also the trap representation issue, again, most people aren't very
> aware of it because such platforms are rare.
> But for practical purposes, uint8_t and unsigned char can stand in
> for each other. You'll use one of the two for bit buffers.
I prefer to write code that I'm sure will work, not code that
(today) probably works. Whenever I hear the phrase "for practical
purposes", a big red flag goes up because the odds are very good
that the code in question will cause problems in the future. I
consider this kind of corner cutting anathema to good software
development. Moreover the right way to do it is straightfoward
and not at all burdensome. Only a fool buys trouble for himself
when the alternative is so easy and inexpensive.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-08-04 23:45 -0400 |
| Message-ID | <IFfwx.52229$0S7.24043@fx21.iad> |
| In reply to | #66859 |
On 8/4/15 11:00 AM, Tim Rentsch wrote: > The Standard does not require, either directly or indirectly, > that uint8_t by the same type as unsigned char, even in cases > where CHAR_BIT == 8 and where uint8_t is supplied by the > implementation (which again is not necessarily so). This is > possible by having uint8_t be an extended integer type rather > than a synonym for unsigned char, and there are at least a couple > of reasons why one might want to do that, to wit, to provide more > stringent type checking, and to present more optimization > opportunities (and potential perfomance improvements) by virtue > of reducing the set of aliasing constraints. The character types > occupy a distinguished position among the set of C integer types; > it's a bad idea to treat any type name as a synonym for a > character type unless it is guaranteed to be a synonym for one of > the character types. That is not the case for any of the types > in <stdint.h>. > There is an indirect requirement due to conversion rank. 6.3.1.1p1 Bullet 5 says: — The rank of any standard integer type shall be greater than the rank of any extended integer type with the same width. Thus unsigned char / signed char / char must have the highest conversion rank of any CHAR_BIT type. from 6.2.5p8 8 For any two integer types with the same signedness and different integer conversion rank (see 6.3.1.1), the range of values of the type with smaller integer conversion rank is a subrange of the values of the other type. Since uint8_t uses the full range possible for an 8 bit type, it must have the highest conversion rank for its size, thus it must be unsigned char (or char if it is unsigned). It can not be an extended integer type, as that would need to have a lower conversion rank than unsigned char, and thus only a subrange of the values, and thus not qualify as an exact sized type.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-05 08:45 -0700 |
| Message-ID | <lnr3nhg2mt.fsf@kst-u.example.com> |
| In reply to | #66901 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 8/4/15 11:00 AM, Tim Rentsch wrote:
>
>> The Standard does not require, either directly or indirectly,
>> that uint8_t by the same type as unsigned char, even in cases
>> where CHAR_BIT == 8 and where uint8_t is supplied by the
>> implementation (which again is not necessarily so). This is
>> possible by having uint8_t be an extended integer type rather
>> than a synonym for unsigned char, and there are at least a couple
>> of reasons why one might want to do that, to wit, to provide more
>> stringent type checking, and to present more optimization
>> opportunities (and potential perfomance improvements) by virtue
>> of reducing the set of aliasing constraints. The character types
>> occupy a distinguished position among the set of C integer types;
>> it's a bad idea to treat any type name as a synonym for a
>> character type unless it is guaranteed to be a synonym for one of
>> the character types. That is not the case for any of the types
>> in <stdint.h>.
>>
>
> There is an indirect requirement due to conversion rank.
>
> 6.3.1.1p1
>
> Bullet 5 says:
>
> -- The rank of any standard integer type shall be greater than the rank
> of any extended integer type with the same width.
>
> Thus unsigned char / signed char / char must have the highest conversion
> rank of any CHAR_BIT type.
Agreed.
> from 6.2.5p8
>
> 8 For any two integer types with the same signedness and different
> integer conversion rank (see 6.3.1.1), the range of values of the type
> with smaller integer conversion rank is a subrange of the values of the
> other type.
>
> Since uint8_t uses the full range possible for an 8 bit type, it must
> have the highest conversion rank for its size, thus it must be unsigned
> char (or char if it is unsigned). It can not be an extended integer
> type, as that would need to have a lower conversion rank than unsigned
> char, and thus only a subrange of the values, and thus not qualify as an
> exact sized type.
You're misreading the word "subrange". It needn't be a *proper*
subrange; a range is a subrange of itself. Otherwise it wouldn't
be legal for int and long, or long and long long, to have the same
range, since they have different integer conversion ranks.
If an implementation defines an extended integer type __uint8,
with exactly the same range and representation as unsigned char
(both 0 .. 255), then __uint8 has a lower integer conversion rank
than unsigned char, but that doesn't prevent uint8_t being defined
as a typedef for __uint8.
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-05 12:00 -0700 |
| Message-ID | <kfnegicwv2l.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66901 |
Richard Damon <Richard@Damon-Family.org> writes: > On 8/4/15 11:00 AM, Tim Rentsch wrote: > >> The Standard does not require, either directly or indirectly, >> that uint8_t by the same type as unsigned char, even in cases >> where CHAR_BIT == 8 and where uint8_t is supplied by the >> implementation (which again is not necessarily so). This is >> possible by having uint8_t be an extended integer type rather >> than a synonym for unsigned char, and there are at least a couple >> of reasons why one might want to do that, to wit, to provide more >> stringent type checking, and to present more optimization >> opportunities (and potential perfomance improvements) by virtue >> of reducing the set of aliasing constraints. The character types >> occupy a distinguished position among the set of C integer types; >> it's a bad idea to treat any type name as a synonym for a >> character type unless it is guaranteed to be a synonym for one of >> the character types. That is not the case for any of the types >> in <stdint.h>. > > There is an indirect requirement due to conversion rank. > > 6.3.1.1p1 > > Bullet 5 says: > > ? The rank of any standard integer type shall be greater than the rank > of any extended integer type with the same width. > > Thus unsigned char / signed char / char must have the highest > conversion rank of any CHAR_BIT type. > > from 6.2.5p8 > > 8 For any two integer types with the same signedness and different > integer conversion rank (see 6.3.1.1), the range of values of the type > with smaller integer conversion rank is a subrange of the values of > the other type. > > Since uint8_t uses the full range possible for an 8 bit type, it must > have the highest conversion rank for its size, thus it must be > unsigned char (or char if it is unsigned). It can not be an extended > integer type, as that would need to have a lower conversion rank than > unsigned char, and thus only a subrange of the values, and thus not > qualify as an exact sized type. I agree with Keith Thompson's analysis: the Standard allows uint8_t to be an extended integer type with integer conversion rank less than that of unsigned character, making it a distinct type.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-01 13:17 -0700 |
| Message-ID | <lnzj2akbkj.fsf@kst-u.example.com> |
| In reply to | #66635 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, August 1, 2015 at 1:55:53 PM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> > That particular "weakness" is a fair enough point.
>>
>> Right. So, just to be clear, you have now withdrawn both of the points
>> you raised. When James said:
>>
> No, because it's a fair enough principle that input-only parameters
> should be marked "const". There are also reasons for not so doing,
> such as to maintain compatibility with pre-const compilers, to
> reduce visual clutter, and because const tends to lead to lead
> to programming errors which are hard to correct, when something is
> const-qualified accidentally. There's also the point that C const
> doesn't do what it says on the tin.
Can you expand on that last point? What "tin" are you referring to, and
how does const violate it? Are you referring to the fact that "const"
doesn't mean "constant"?
> The question is whether the legitimate position that const should be
> ignored is undermined by the existence of the const extension to
> the language. The answer is yes. If you dislike const, for whatever
> reason, it's not a valid counter-argument that "it's there for people
> who find it useful, it doesn't have to affect you".
It's odd to refer to something that's been in the language for 26 years
as an "extension". It's true that it was added to a language that did
not previously had it, but by now it's a fundamental feature. Hardly
any "pre-const compilers" are still in use.
[...]
--
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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-01 16:11 -0400 |
| Message-ID | <55BD27E3.4080902@verizon.net> |
| In reply to | #66647 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, August 1, 2015 at 1:55:53 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> That particular "weakness" is a fair enough point. >> >> Right. So, just to be clear, you have now withdrawn both of the points >> you raised. When James said: >> > No, because it's a fair enough principle that input-only parameters > should be marked "const". ... And what in the world does that have to do with my comment, which was about differences between C90 and later versions? Nothing you've talked about is different between C90 and later versions. > ... There are also reasons for not so doing, > such as to maintain compatibility with pre-const compilers, to > reduce visual clutter, and because const tends to lead to lead > to programming errors which are hard to correct, when something is > const-qualified accidentally. There's also the point that C const > doesn't do what it says on the tin. That doesn't match my experience. 'const', used properly, helps you identify programming errors that would otherwise have gone unnoticed. It's not particularly easy to accidentally const-qualify something, and the error messages that come up when you do generally make it easy to identify what correction is needed. Either the const-qualification or the code that was inconsistent with the const-qualification need to be removed - it's just a matter of deciding whether the thing protected by the const-qualification should, or should not, be protected from being changed through the relevant identifier. If it shouldn't be protected, remove the 'const'. If it should be protected, remove the offending code, and figure out a way to do what needs to be done without violating that protection. Only on rare occasions is the correct solution a cast that changes the const-qualification of a type. > The question is whether the legitimate position that const should be > ignored is undermined by the existence of the const extension to What do you mean by "the const extension"? "const" has been a part of the standard-defined language for as long as there has been a standard. it cannot by any stretch of the imagination be described as an extension to the language. > the language. The answer is yes. If you dislike const, for whatever > reason, it's not a valid counter-argument that "it's there for people > who find it useful, it doesn't have to affect you". That part, at least, is correct. If you insist on not using it, you're going to have to insert const-changing casts all over the place so your code can get away with interacting incorrectly with code that uses 'const' correctly. Anyone who claims it won't affect people who are dumb enough to not want to use it, is lying. Do you claim to have received such advice from anyone? If so, from whom, and in what context?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-01 14:00 -0700 |
| Message-ID | <e4d4f2ed-746a-4afe-9be9-b3b623ceedde@googlegroups.com> |
| In reply to | #66650 |
On Saturday, August 1, 2015 at 9:11:24 PM UTC+1, James Kuyper wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > That doesn't match my experience. 'const', used properly, helps you > identify programming errors that would otherwise have gone unnoticed. > It's not particularly easy to accidentally const-qualify something, and > the error messages that come up when you do generally make it easy to > identify what correction is needed. > My experience is that, yes, it does help catch some bugs early, but they tend to be the sort of bug that will come out early in testing anyway. But when someone makes a mistake, and const- poisons code, the problems are either very intractable, or are solved undesirably by casting const away. Const correctness is also bad from an object encapsulation point of view, it's usually not the caller's business whether a getter is caching data or not. That's led C++ to introduce "mutable" to override const, the next logical step is to have "immutable" to specify a super const that overrides mutable. You can see where this is leading.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-08-02 10:40 +1200 |
| Message-ID | <d2506mF55bbU1@mid.individual.net> |
| In reply to | #66655 |
Malcolm McLean wrote: > On Saturday, August 1, 2015 at 9:11:24 PM UTC+1, James Kuyper wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> That doesn't match my experience. 'const', used properly, helps you >> identify programming errors that would otherwise have gone unnoticed. >> It's not particularly easy to accidentally const-qualify something, and >> the error messages that come up when you do generally make it easy to >> identify what correction is needed. >> > My experience is that, yes, it does help catch some bugs early, > but they tend to be the sort of bug that will come out early > in testing anyway. No, they are the kind of bugs that bite you in the arse when the code is deployed in a new environment, built with a different compiler or even compiled with the same compiler with different options. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-01 16:20 -0700 |
| Message-ID | <6435c725-9117-45a6-87f5-ace8acb0a13c@googlegroups.com> |
| In reply to | #66661 |
On Saturday, August 1, 2015 at 11:40:31 PM UTC+1, Ian Collins wrote: > Malcolm McLean wrote: > > > My experience is that, yes, it does help catch some bugs early, > > but they tend to be the sort of bug that will come out early > > in testing anyway. > > No, they are the kind of bugs that bite you in the arse when the code is > deployed in a new environment, built with a different compiler or even > compiled with the same compiler with different options. > Any bug can be nasty. But only rarely do I get a longstanding bug that is caused by a write to an input parameter. The reason is that if it happens, usually the write should have been to the output instead. So that bug is picked up on practically the first test.
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2015-08-22 08:24 +0200 |
| Message-ID | <oc5gta5q4h6vmj34t6ubfeg1rc0t3l5kap@4ax.com> |
| In reply to | #66661 |
On Sun, 02 Aug 2015 10:40:20 +1200, Ian Collins wrote: >Malcolm McLean wrote: >> On Saturday, August 1, 2015 at 9:11:24 PM UTC+1, James Kuyper wrote: >>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> >>> That doesn't match my experience. 'const', used properly, helps you >>> identify programming errors that would otherwise have gone unnoticed. >>> It's not particularly easy to accidentally const-qualify something, and >>> the error messages that come up when you do generally make it easy to >>> identify what correction is needed. >>> >> My experience is that, yes, it does help catch some bugs early, >> but they tend to be the sort of bug that will come out early >> in testing anyway. > >No, they are the kind of bugs that bite you in the arse when the code is >deployed in a new environment, built with a different compiler or even >compiled with the same compiler with different options. so you change your opinion const is good? if i remember well i was alone in think const is un-usefull...
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-08-22 19:26 +1200 |
| Message-ID | <d3qmgbFed1gU4@mid.individual.net> |
| In reply to | #67985 |
Rosario19 wrote: > On Sun, 02 Aug 2015 10:40:20 +1200, Ian Collins wrote: >> Malcolm McLean wrote: >>> On Saturday, August 1, 2015 at 9:11:24 PM UTC+1, James Kuyper wrote: >>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>>> >>>> That doesn't match my experience. 'const', used properly, helps you >>>> identify programming errors that would otherwise have gone unnoticed. >>>> It's not particularly easy to accidentally const-qualify something, and >>>> the error messages that come up when you do generally make it easy to >>>> identify what correction is needed. >>>> >>> My experience is that, yes, it does help catch some bugs early, >>> but they tend to be the sort of bug that will come out early >>> in testing anyway. >> >> No, they are the kind of bugs that bite you in the arse when the code is >> deployed in a new environment, built with a different compiler or even >> compiled with the same compiler with different options. > > so you change your opinion const is good? No, why do you say that? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-22 05:39 -0700 |
| Message-ID | <f9a7545d-1699-4670-a73d-4cea52f0e95d@googlegroups.com> |
| In reply to | #67985 |
On Saturday, August 22, 2015 at 7:24:41 AM UTC+1, Rosario19 wrote: > On Sun, 02 Aug 2015 10:40:20 +1200, Ian Collins wrote: > >Malcolm McLean wrote: > >> On Saturday, August 1, 2015 at 9:11:24 PM UTC+1, James Kuyper wrote: > >>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >>> > >>> That doesn't match my experience. 'const', used properly, helps you > >>> identify programming errors that would otherwise have gone unnoticed. > >>> It's not particularly easy to accidentally const-qualify something, and > >>> the error messages that come up when you do generally make it easy to > >>> identify what correction is needed. > >>> > >> My experience is that, yes, it does help catch some bugs early, > >> but they tend to be the sort of bug that will come out early > >> in testing anyway. > > > >No, they are the kind of bugs that bite you in the arse when the code is > >deployed in a new environment, built with a different compiler or even > >compiled with the same compiler with different options. > > so you change your opinion const is good? > if i remember well i was alone in think const is un-usefull... > I think you're confusing me with Ian Collins. I'm a const sceptic. I don't think it's useless in all circumstances, but I think the benefits are small in relation to the effect it has on the language, and think the disadvantages are often skated over. Ian Collins doesn't share those views.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-01 13:51 -0700 |
| Message-ID | <8555af32-f891-45fa-aa18-fea51ccfa022@googlegroups.com> |
| In reply to | #66647 |
On Saturday, August 1, 2015 at 8:34:54 PM UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> There's also the point that C const
> > doesn't do what it says on the tin.
>
> Can you expand on that last point? What "tin" are you referring to, and
> how does const violate it? Are you referring to the fact that "const"
> doesn't mean "constant"?
>
consider this
int foo(const int *x, int *xalias)
{
*xalias = 42;
return *x;
}
int main(void)
{
int x = 0;
int y;
foo(&x, &x);
printf("Y %d\n", y);
exit( (y == 0 && x == 42) ? EXIT_SUCCESS: EXIT_FAILURE);
}
Then this
typedef struct
{
char *name;
double salary;
int payrollid;
}
int payroll(const char *employee)
{
// Naughty hacker trying to pay himself instead of legitimate employee
strcpy(employee->name, "Fred");
employee->payrollid = FREDSPAYROLLID;
return 0;
}
One hack gets caught, the other doesn't.
>
> It's odd to refer to something that's been in the language for 26 years
> as an "extension". It's true that it was added to a language that did
> not previously had it, but by now it's a fundamental feature. Hardly
> any "pre-const compilers" are still in use.
>
It was the start of the slide from a language that was nearly
perfect into one that is tainted with ugliness and undesireable
complications. It was done in the wrong way. Had the committee
devised a better suntax, like using ? for a const pointer
so double mean(double ?x, int N) meant x is const, and
int getlongeststring(char ??str, int N) meant a double const
pointer, and setlongeststringtoempty(char ?*str, int N) meant
the list was constant but the string mutable, and
setlongeststringtonull(char *?str, int N) meant that the strings
were constant but the list was mutable, then it would have been
easier, once you got over the unusualness of C pointers being
introduced by operators with other meanings. Whilst they were at
it, Chinese hat could have meant a "handle", or a pointer which
must be allocated with malloc() (no point making such a pointer
constant, the whole reason is that you might want to free it).
The other weakness is that it's an error to pass a const-qualified
pointer to a subroutine that takes a non-const qualified pointer.
This gives rise to a whole philosophy of const correctness. But
whilst actually solving the problem of whether a variable is
written is akin to solving the halting problem, automatically marking
possible writes is not. That puts the burden of const where it
belongs, at the point someone for whatever reason chooses to mark
a variable as const, not giving programmers writing perfectly
routine and everyday functions another thing to worry about.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-08-02 10:38 +1200 |
| Message-ID | <d2502lF55b9U2@mid.individual.net> |
| In reply to | #66654 |
Malcolm McLean wrote: > > The other weakness is that it's an error to pass a const-qualified > pointer to a subroutine that takes a non-const qualified pointer. s/weakness/strength/ > This gives rise to a whole philosophy of const correctness. But > whilst actually solving the problem of whether a variable is > written is akin to solving the halting problem, automatically marking > possible writes is not. That puts the burden of const where it > belongs, at the point someone for whatever reason chooses to mark > a variable as const, not giving programmers writing perfectly > routine and everyday functions another thing to worry about. You don't appear to have a grasp of what a const qualified parameter cost is telling the caller. It is telling the user that the function won't modify the data the pointer points to. In doing so, it saves programmers from having to check so they have one less thing to worry about. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-01 16:14 -0700 |
| Message-ID | <2dfa35fa-01e4-4243-ae62-2879262d7ac6@googlegroups.com> |
| In reply to | #66660 |
On Saturday, August 1, 2015 at 11:38:29 PM UTC+1, Ian Collins wrote: > Malcolm McLean wrote: > > You don't appear to have a grasp of what a const qualified parameter > cost is telling the caller. It is telling the user that the function > won't modify the data the pointer points to. In doing so, it saves > programmers from having to check so they have one less thing to worry > about. > Crucial information for any function is the interface - what bits am I passing, what arrangement of bits do I get back. in / out is implicit in that interface, which has to be documented anyway. I not saying that it's never helpful to have copy_employee(EMPLOYEE *d, const EMPLOYEE *s) that tell you that the second parameter is the source. But a sensible person will write dest and src rather than "d" and "s", and he'll say what the parameters are - is so basic that it's unlikely to be forgotten. const does gain you something, but not much. If we write copy_employee(&existing, &clone) and existing is const-qualified, we'll get an error, which is good. But it's not something we can rely on, because often existing employee won't be const qualified in caller's scope. What's likely to really matter is whether copy_employee performs a shallow or a deep copy. We've got to document that, and in the process, we implicitly document which parameter is which. const isn't a hard concept to grasp and really I don't think I'm so simplistic that I can't see the reasons people think it's a good idea. I don't myself think it's inherently bad in every language. But in the C family of languages, const causes subtle difficulties that aren't obvious at first sight. A perfect example is strtod. Should the end return pointer be const qualified or not? What's your view on that and why?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-02 01:15 +0200 |
| Message-ID | <mpjjr8$e0p$1@dont-email.me> |
| In reply to | #66552 |
On 30/07/15 09:25, Richard Heathfield wrote: > I think the real danger is that, if C90 is left far enough behind, > people will stop producing C90 compilers for new machines as and when > they come along, and then we'll /all/ have a problem with portability. > But don't mind me. > For new machines, there are normally only two realistic, economically viable ways of making a C compiler. You port gcc to the new target, or you port llvm to the new target. I don't expected the C90 parsers of gcc or clang to disappear any time soon. I also have a hard time thinking of systems that have C90 compilers but not C99 compilers - the only ones I know (in the embedded world) are either obsolete long ago, or so weird that any code written for the chips is special and non-portable anyway. Of course, just because a processor or system is obsolete does not mean no one uses it, but personally I don't want my current programming options to be limited by chips that went out of production 10 years ago.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-01 16:24 -0700 |
| Message-ID | <962a506b-98f7-4c0a-902d-6796a8be9bc0@googlegroups.com> |
| In reply to | #66665 |
On Sunday, August 2, 2015 at 12:15:27 AM UTC+1, David Brown wrote: > > For new machines, there are normally only two realistic, economically > viable ways of making a C compiler. You port gcc to the new target, or > you port llvm to the new target. I don't expected the C90 parsers of > gcc or clang to disappear any time soon. > > I also have a hard time thinking of systems that have C90 compilers but > not C99 compilers - the only ones I know (in the embedded world) are > either obsolete long ago, or so weird that any code written for the > chips is special and non-portable anyway. Of course, just because a > processor or system is obsolete does not mean no one uses it, but > personally I don't want my current programming options to be limited by > chips that went out of production 10 years ago. > The elephant is Windows. Microsoft withheld C99 support from its compiler for a long time. In the hosted world, any routine that purports to be portable but won't compile under a Microsoft system is useless.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-02 02:32 +0200 |
| Message-ID | <mpjobo$q72$1@dont-email.me> |
| In reply to | #66667 |
On 02/08/15 01:24, Malcolm McLean wrote: > On Sunday, August 2, 2015 at 12:15:27 AM UTC+1, David Brown wrote: >> >> For new machines, there are normally only two realistic, economically >> viable ways of making a C compiler. You port gcc to the new target, or >> you port llvm to the new target. I don't expected the C90 parsers of >> gcc or clang to disappear any time soon. >> >> I also have a hard time thinking of systems that have C90 compilers but >> not C99 compilers - the only ones I know (in the embedded world) are >> either obsolete long ago, or so weird that any code written for the >> chips is special and non-portable anyway. Of course, just because a >> processor or system is obsolete does not mean no one uses it, but >> personally I don't want my current programming options to be limited by >> chips that went out of production 10 years ago. >> > The elephant is Windows. > Microsoft withheld C99 support from its compiler for a long time. > In the hosted world, any routine that purports to be portable but > won't compile under a Microsoft system is useless. > For a lot of "portable" code, that elephant was irrelevant - for a great deal of C code, the biggest issue with MSVC is lack of POSIX rather than lack of C99. And when you want your C99 code to run on Windows you could always use gcc (mingw or cygwin), clang, or even Borland. But fortunately, that particular MSVC elephant is pretty much dead now, as far as I understand it, with C99 support in current versions.
[toc] | [prev] | [next] | [standalone]
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web