Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #110518 > unrolled thread
| Started by | joel.rees@gmail.com |
|---|---|
| First post | 2017-05-23 18:46 -0700 |
| Last post | 2017-05-25 02:21 -0700 |
| Articles | 20 on this page of 250 — 24 participants |
Back to article view | Back to comp.lang.c
conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-23 18:46 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-24 03:18 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-23 19:47 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-24 11:54 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-24 13:16 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-23 20:02 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-24 14:17 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-24 17:40 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-26 16:24 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-05-23 22:10 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-23 20:52 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-24 12:22 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-24 12:00 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-24 04:10 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-24 14:28 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-24 14:17 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-24 16:36 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-24 16:02 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-24 17:43 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Thiago Adams <thiago.adams@gmail.com> - 2017-05-25 05:27 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-25 14:17 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 09:10 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-24 09:55 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 10:02 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-24 10:46 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-25 07:33 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-24 15:43 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-25 08:05 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-24 16:15 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-25 17:52 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-25 11:55 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-26 08:42 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-25 16:50 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-26 08:58 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-25 17:10 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-26 20:07 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-26 11:34 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") raltbos@xs4all.nl (Richard Bos) - 2017-06-03 10:19 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-25 15:04 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-26 20:06 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-25 09:00 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-26 08:24 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-25 14:43 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-26 20:09 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-26 09:37 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-27 08:43 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-26 17:01 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-26 14:38 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ike Naar <ike@iceland.freeshell.org> - 2017-05-25 05:54 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-05-24 15:15 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 14:14 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ian Collins <ian-news@hotmail.com> - 2017-05-25 17:55 +1200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-24 23:52 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-25 20:59 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 08:59 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-24 18:30 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-24 21:46 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-24 22:48 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-25 01:10 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-25 01:51 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-25 03:41 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-25 12:18 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-25 22:26 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-25 23:25 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-25 17:03 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-26 01:09 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-26 13:29 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") raltbos@xs4all.nl (Richard Bos) - 2017-06-03 10:24 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-06-04 16:35 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-26 03:41 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-26 11:51 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-26 13:43 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-26 09:29 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-28 22:20 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Gareth Owen <gwowen@gmail.com> - 2017-05-29 07:51 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-30 06:40 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-29 11:37 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-30 06:25 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-30 16:06 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Kleinecke <dkleinecke@gmail.com> - 2017-05-30 15:11 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-26 13:26 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-26 11:58 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-26 09:44 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-24 04:06 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Melzzzzz <Melzzzzz@zzzzz.com> - 2017-05-24 11:14 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-24 14:58 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-24 15:48 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-24 18:54 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 16:58 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-24 18:19 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 18:58 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-25 21:45 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-26 17:06 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ike Naar <ike@iceland.freeshell.org> - 2017-05-25 08:51 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-24 17:22 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 18:51 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-25 21:38 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-05-26 23:02 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-27 12:52 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-06-01 11:47 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-01 10:45 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-06-02 00:05 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-02 00:11 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-06-02 00:51 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-06-02 02:21 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:59 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-06-03 13:03 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-03 20:32 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-06-03 15:16 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-03 22:44 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-06-03 17:16 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-03 11:43 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-06-03 17:34 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-04 17:32 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-06-04 16:37 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Philip Lantz <prl@canterey.us> - 2017-05-25 21:08 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Philip Lantz <prl@canterey.us> - 2017-05-25 21:11 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-26 03:33 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 08:52 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 09:53 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-25 22:05 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-24 13:21 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-25 22:07 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-25 14:46 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-29 08:57 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-29 15:47 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-25 18:44 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-05-25 22:29 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-05-26 15:05 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-26 09:44 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-26 23:46 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-27 11:39 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-27 13:11 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-27 13:26 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-28 00:57 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-28 08:42 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-28 18:52 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-28 15:08 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-29 01:52 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-29 16:02 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-28 05:24 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-28 13:51 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-28 15:12 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-28 15:43 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-29 15:52 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-28 17:51 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-28 20:45 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-29 01:11 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-05-29 05:24 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-29 06:02 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-29 17:13 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-29 19:26 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-29 14:19 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-29 15:45 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Gareth Owen <gwowen@gmail.com> - 2017-05-30 07:01 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-30 09:31 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-05-27 16:22 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-27 14:41 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-28 06:53 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-28 09:28 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-05-29 03:58 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-29 01:44 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-29 13:48 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-29 06:46 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-29 15:46 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-05-29 15:40 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-29 17:18 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-05-29 15:08 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-29 20:40 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") luser droog <luser.droog@gmail.com> - 2017-05-30 00:49 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-30 11:54 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-05-30 09:48 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-30 07:49 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-30 10:20 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-30 14:50 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") scott@slp53.sl.home (Scott Lurndal) - 2017-05-30 19:16 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-30 12:07 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-30 20:15 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") raltbos@xs4all.nl (Richard Bos) - 2017-06-03 11:01 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-29 11:25 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-27 14:27 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") raltbos@xs4all.nl (Richard Bos) - 2017-06-03 10:32 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") asetofsymbols@gmail.com - 2017-06-03 03:50 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-03 11:28 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") raltbos@xs4all.nl (Richard Bos) - 2017-06-03 18:54 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-03 12:51 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-06-11 23:34 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-06-12 07:17 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-12 08:12 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") jameskuyper@verizon.net - 2017-06-12 09:01 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-12 09:34 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-06-13 22:45 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-06-14 09:42 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-06-14 17:53 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-06-15 03:28 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-15 07:49 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-14 07:46 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-06-14 20:19 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-06-04 16:44 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-04 19:00 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-06-05 11:48 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-05 08:44 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-05 10:37 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") scott@slp53.sl.home (Scott Lurndal) - 2017-06-05 18:05 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") David Brown <david.brown@hesbynett.no> - 2017-06-05 21:31 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-06-05 13:04 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-05-24 14:50 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-24 13:06 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-05-24 15:22 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-24 13:30 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-24 08:15 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 09:38 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-26 17:24 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-26 18:37 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-28 18:44 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-26 17:28 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-26 18:37 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 08:43 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-24 14:08 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-24 17:17 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-25 02:39 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 18:48 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-25 15:13 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-25 14:34 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-25 16:44 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ike Naar <ike@iceland.freeshell.org> - 2017-05-25 15:02 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-25 17:19 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-25 17:18 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-25 18:58 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-25 18:24 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-25 20:36 +0200
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-25 16:06 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-26 16:37 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-26 16:54 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 08:46 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-24 13:33 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-24 13:12 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-24 17:52 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") bartc <bc@freeuk.com> - 2017-05-25 02:00 +0100
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Keith Thompson <kst-u@mib.org> - 2017-05-24 18:53 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ike Naar <ike@iceland.freeshell.org> - 2017-05-25 09:34 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Robert Wessel <robertwessel2@yahoo.com> - 2017-05-26 23:08 -0500
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ike Naar <ike@iceland.freeshell.org> - 2017-05-27 16:40 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-24 19:36 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") James Kuyper <jameskuyper@verizon.net> - 2017-05-24 23:16 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-24 21:28 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-25 15:45 -0400
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") supercat@casperkitty.com - 2017-05-25 14:27 -0700
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") Ike Naar <ike@iceland.freeshell.org> - 2017-05-25 05:50 +0000
Re: conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer") joel.rees@gmail.com - 2017-05-25 02:21 -0700
Page 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-25 09:00 -0700 |
| Message-ID | <lnr2zdudsd.fsf@kst-u.example.com> |
| In reply to | #110616 |
Ian Collins <ian-news@hotmail.com> writes:
> On 05/25/17 08:15 AM, James R. Kuyper wrote:
>> On 05/24/2017 04:05 PM, Ian Collins wrote:
>>> On 05/25/17 07:43 AM, James R. Kuyper wrote:
>>>> On 05/24/2017 03:33 PM, Ian Collins wrote:
>>>>> On 05/25/17 04:10 AM, Keith Thompson wrote:
>>>>>> David Brown <david.brown@hesbynett.no> writes:
[...]
>>>>>>> C++ got it right by making string literals "const".
>>>>>>
>>>>>> Yes -- and I would argue that C got it right by *not* making string
>>>>>> literals "const".
>>>>>>
>>>>>> C and C++ had different goals. C++ was a new language, with
>>>>>> some concern for compatibility with C, but it wasn't an absolute
>>>>>> requirement -- and in the case of this particular feature,
>>>>>> overloading was also a consideration. Making string literals const
>>>>>> in C would have broken existing code.
>>>>>
>>>>> Broken existing broken code!
>>>>
>>>> The existing code that would have been broken by that change was, by
>>>> definition, written before 'const' had been added to the language. That
>>>> being the case, what was broken about that code?
>>>
>>> Modifying string literals has never been a good idea.
>>
>> I'm referring to code like the following, which does NOT involve
>> modifying a string literal:
>>
>> char *greeting = "Hello";
>
> It does if you pass the pointer to something (such as strtok) that does...
Consider this pre-ANSI C program:
#include <stdio.h>
int main() {
char *greeting = "Hello";
printf("%s\n", greeting);
}
That's a perfectly valid program that does not attempt to modify a
string literal. Making string literals const would have broken that
program, and many others like it. That's the point.
In C89 or later, it's a good idea to replace
char *greeting = "Hello";
by
const char *greeting = "Hello";
to detect errors in other possible uses of `greeting`. But pre-ANSI C
didn't allow that, and ANSI/ISO C doesn't require it.
ANSI C added "const" without breaking existing pre-ANSI code
(as long as that code didn't use "const" as an identifier), but
it was able to do so only by *not* making string literals const.
(C++ did make string literals const, and thereby broke C programs
like the one above.)
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-05-26 08:24 +1200 |
| Message-ID | <eooss2Fha6pU6@mid.individual.net> |
| In reply to | #110641 |
On 05/26/17 04:00 AM, Keith Thompson wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> On 05/25/17 08:15 AM, James R. Kuyper wrote:
>>> On 05/24/2017 04:05 PM, Ian Collins wrote:
>>>> On 05/25/17 07:43 AM, James R. Kuyper wrote:
>>>>> On 05/24/2017 03:33 PM, Ian Collins wrote:
>>>>>>
>>>>>> Broken existing broken code!
>>>>>
>>>>> The existing code that would have been broken by that change was, by
>>>>> definition, written before 'const' had been added to the language. That
>>>>> being the case, what was broken about that code?
>>>>
>>>> Modifying string literals has never been a good idea.
>>>
>>> I'm referring to code like the following, which does NOT involve
>>> modifying a string literal:
>>>
>>> char *greeting = "Hello";
>>
>> It does if you pass the pointer to something (such as strtok) that does...
>
> Consider this pre-ANSI C program:
>
> #include <stdio.h>
> int main() {
> char *greeting = "Hello";
> printf("%s\n", greeting);
> }
>
> That's a perfectly valid program that does not attempt to modify a
> string literal. Making string literals const would have broken that
> program, and many others like it. That's the point.
As I said else thread, I should have said broken and booby trapped code.
Yes a little stand alone program is safe, but as soon as you have a
larger application with pointers being passed around, the clock starts
ticking..
How many posts have there been here over the years where someone posts
some code that modifies a string literal and wonders why the program
crashes? Now what if the code that caused a crash was only called on a
rare condition? It may well (and older code often wasn't very
thoroughly tested, especially in the corners) have escaped into the wild
only to crash months or even years later. That code was broken.
> In C89 or later, it's a good idea to replace
> char *greeting = "Hello";
> by
> const char *greeting = "Hello";
> to detect errors in other possible uses of `greeting`. But pre-ANSI C
> didn't allow that, and ANSI/ISO C doesn't require it.
>
> ANSI C added "const" without breaking existing pre-ANSI code
> (as long as that code didn't use "const" as an identifier), but
> it was able to do so only by *not* making string literals const.
> (C++ did make string literals const, and thereby broke C programs
> like the one above.)
Because it also broke C++ code, that was one of the boldest decisions
the C++ committee made. I was at the last ACCU conference before the
C++ standard was released and this was a hotly debated issue. I'm sure
most who where there came away agreeing the gains outweighed the cost,
which was breaking dangerous code...
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-25 14:43 -0700 |
| Message-ID | <lnmva0vch2.fsf@kst-u.example.com> |
| In reply to | #110652 |
Ian Collins <ian-news@hotmail.com> writes:
> On 05/26/17 04:00 AM, Keith Thompson wrote:
[...]
>> Consider this pre-ANSI C program:
>>
>> #include <stdio.h>
>> int main() {
>> char *greeting = "Hello";
>> printf("%s\n", greeting);
>> }
>>
>> That's a perfectly valid program that does not attempt to modify a
>> string literal. Making string literals const would have broken that
>> program, and many others like it. That's the point.
>
> As I said else thread, I should have said broken and booby trapped code.
> Yes a little stand alone program is safe, but as soon as you have a
> larger application with pointers being passed around, the clock starts
> ticking..
The point is that, prior to ANSI C and the introduction of "const",
there was no way to unbreak and un-booby-trap such code. It was
not possible to enforce read-only semantics for an object or
via a pointer. (I suppose you could have hidden accesses behind
function calls, but the language provided no way to ensure that
those functions were written correctly.)
Such code was "broken" only in the sense that it was written in a
language that provided no way to unbreak it. That is, of course,
why "const" was introduced.
[...]
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-05-26 20:09 +1200 |
| Message-ID | <eoq663Fjb4rU3@mid.individual.net> |
| In reply to | #110659 |
On 05/26/17 09:43 AM, Keith Thompson wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> On 05/26/17 04:00 AM, Keith Thompson wrote:
> [...]
>>> Consider this pre-ANSI C program:
>>>
>>> #include <stdio.h>
>>> int main() {
>>> char *greeting = "Hello";
>>> printf("%s\n", greeting);
>>> }
>>>
>>> That's a perfectly valid program that does not attempt to modify a
>>> string literal. Making string literals const would have broken that
>>> program, and many others like it. That's the point.
>>
>> As I said else thread, I should have said broken and booby trapped code.
>> Yes a little stand alone program is safe, but as soon as you have a
>> larger application with pointers being passed around, the clock starts
>> ticking..
>
> The point is that, prior to ANSI C and the introduction of "const",
> there was no way to unbreak and un-booby-trap such code. It was
> not possible to enforce read-only semantics for an object or
> via a pointer. (I suppose you could have hidden accesses behind
> function calls, but the language provided no way to ensure that
> those functions were written correctly.)
>
> Such code was "broken" only in the sense that it was written in a
> language that provided no way to unbreak it. That is, of course,
> why "const" was introduced.
>
> [...]
I don't dispute that. Where we disagree appears to be whether it would
have been worth while breaking existing code by making string literals
const. My arguments in favour were in the bits of my last post you
snipped...
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-26 09:37 -0700 |
| Message-ID | <ln1srbvaji.fsf@kst-u.example.com> |
| In reply to | #110680 |
Ian Collins <ian-news@hotmail.com> writes:
> On 05/26/17 09:43 AM, Keith Thompson wrote:
[...]
>> Such code was "broken" only in the sense that it was written in a
>> language that provided no way to unbreak it. That is, of course,
>> why "const" was introduced.
>>
>> [...]
>
> I don't dispute that. Where we disagree appears to be whether it would
> have been worth while breaking existing code by making string literals
> const. My arguments in favour were in the bits of my last post you
> snipped...
I snipped that part because I wasn't discussing those arguments.
I personally tend to think that leaving string literals non-const was
the right decision by the ANSI C committee in the late 1980s, but it's
not a strong opinion and I'm very sympathetic to the counterargument
that making string literals "const" (perhaps gradually) would have been
a better choice.
I was disputing your claim that pre-ANSI C code that didn't use "const"
*because it didn't exist* was "broken". It was the language's fault,
not the code's fault.
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-05-27 08:43 +1200 |
| Message-ID | <eoriaoFqj75U1@mid.individual.net> |
| In reply to | #110729 |
On 05/27/17 04:37 AM, Keith Thompson wrote: > Ian Collins <ian-news@hotmail.com> writes: >> On 05/26/17 09:43 AM, Keith Thompson wrote: > [...] >>> Such code was "broken" only in the sense that it was written in a >>> language that provided no way to unbreak it. That is, of course, >>> why "const" was introduced. >>> >>> [...] >> >> I don't dispute that. Where we disagree appears to be whether it would >> have been worth while breaking existing code by making string literals >> const. My arguments in favour were in the bits of my last post you >> snipped... > > I snipped that part because I wasn't discussing those arguments. > > I personally tend to think that leaving string literals non-const was > the right decision by the ANSI C committee in the late 1980s, but it's > not a strong opinion and I'm very sympathetic to the counterargument > that making string literals "const" (perhaps gradually) would have been > a better choice. > > I was disputing your claim that pre-ANSI C code that didn't use "const" > *because it didn't exist* was "broken". It was the language's fault, > not the code's fault. You were disputing a claim I didn't make, which is probably why this discussion has gone round in circles... If you look back at your post that started it all, you made no explicit mention of pre-ANSI C code, just whether or not making string literals const would have been a good idea. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-05-26 17:01 -0400 |
| Message-ID | <6288319f-9c7e-f833-3010-164993e953c5@verizon.net> |
| In reply to | #110762 |
On 05/26/2017 04:43 PM, Ian Collins wrote: ... > If you look back at your post that started it all, you made no explicit > mention of pre-ANSI C code, just whether or not making string literals > const would have been a good idea. On 05/24/2017 12:10 PM, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: ... >> C++ got it right by making string literals "const". > > Yes -- and I would argue that C got it right by *not* making string > literals "const". > > C and C++ had different goals. C++ was a new language, with > some concern for compatibility with C, but it wasn't an absolute > requirement -- and in the case of this particular feature, > overloading was also a consideration. Making string literals const > in C would have broken existing code. Agreed: there is no explicit mention of pre-ANSI code in that message. However, since the C89 standard was what added "const" to the C language, that standard was also the first opportunity anyone had to make string literals "const" in C. Therefore, C89 is obviously what Keith was referring to when he said that 'C got it right by *not* making string literals "const".' Once that decision was made in C89, it was unlikely to be reversed in any later version of the standard, and that has indeed been the case. C has also "gotten it right" by not doing so in C99 and C2011, but C89 was the first and most important time that "C got it right", and therefore the existing code that Keith was referring to which would have been broken by that decision was pre-C89 code. Note: using "ANSI" to identify a particular version of the C standard doesn't work - all three versions of the C standard have been adopted as ANSI standards, even the two versions that started out as ISO standards.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-26 14:38 -0700 |
| Message-ID | <lno9ufti26.fsf@kst-u.example.com> |
| In reply to | #110762 |
Ian Collins <ian-news@hotmail.com> writes:
> On 05/27/17 04:37 AM, Keith Thompson wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>> On 05/26/17 09:43 AM, Keith Thompson wrote:
>> [...]
>>>> Such code was "broken" only in the sense that it was written in a
>>>> language that provided no way to unbreak it. That is, of course,
>>>> why "const" was introduced.
>>>>
>>>> [...]
>>>
>>> I don't dispute that. Where we disagree appears to be whether it would
>>> have been worth while breaking existing code by making string literals
>>> const. My arguments in favour were in the bits of my last post you
>>> snipped...
>>
>> I snipped that part because I wasn't discussing those arguments.
>>
>> I personally tend to think that leaving string literals non-const was
>> the right decision by the ANSI C committee in the late 1980s, but it's
>> not a strong opinion and I'm very sympathetic to the counterargument
>> that making string literals "const" (perhaps gradually) would have been
>> a better choice.
>>
>> I was disputing your claim that pre-ANSI C code that didn't use "const"
>> *because it didn't exist* was "broken". It was the language's fault,
>> not the code's fault.
>
> You were disputing a claim I didn't make, which is probably why this
> discussion has gone round in circles...
>
> If you look back at your post that started it all, you made no explicit
> mention of pre-ANSI C code, just whether or not making string literals
> const would have been a good idea.
I wrote:
C and C++ had different goals. C++ was a new language, with
some concern for compatibility with C, but it wasn't an absolute
requirement -- and in the case of this particular feature,
overloading was also a consideration. Making string literals
const in C would have broken existing code.
When I wrote that, I *thought* it was sufficiently obvious that I
was referring to the idea of ANSI C89 making string literals const,
and that the "existing code" was code written in pre-ANSI C that
could not use const because it didn't exist. I think it's unfair
to call such code "broken", which I thought was what you were doing.
Such code was, as far as I know, the only reason not to make string
literals const -- and I expressed the opinion that that was a
sufficient reason at the time.
Perhaps that wasn't as clear as I thought it was, but that exact
point has been made several times in this thread since then.
If you've acknowledged it, it must have been in a followup that I
didn't read closely enough.
--
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 | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2017-05-25 05:54 +0000 |
| Message-ID | <slrn3vfsoicsiv.sqi.ike@iceland.freeshell.org> |
| In reply to | #110581 |
On 2017-05-24, Ian Collins <ian-news@hotmail.com> wrote: > Modifying string literals has never been a good idea. All of the modern > compilers I'm aware of default to placing string literals in a write > only segment, so they are effectively const. A write only segment, or a read only segment?
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-24 15:15 -0500 |
| Message-ID | <bbqbicpr9ktp063cjjlbrk4dquhe8t07i1@4ax.com> |
| In reply to | #110576 |
On Thu, 25 May 2017 07:33:27 +1200, Ian Collins <ian-news@hotmail.com> wrote: >On 05/25/17 04:10 AM, Keith Thompson wrote: >> David Brown <david.brown@hesbynett.no> writes: >> [...] >>> No, they often cannot be modified in any way. The compiler knows that, >>> and takes advantage of it. That is a good thing. There is no advantage >>> to the programmer in being able to modify a string literal, and there is >>> great advantage in getting more efficient code. >>> >>> C++ got it right by making string literals "const". >> >> Yes -- and I would argue that C got it right by *not* making string >> literals "const". >> >> C and C++ had different goals. C++ was a new language, with >> some concern for compatibility with C, but it wasn't an absolute >> requirement -- and in the case of this particular feature, >> overloading was also a consideration. Making string literals const >> in C would have broken existing code. > >Broken existing broken code! But it also would have broken code that was *not* broken. Just because a non-const pointer to a string literal was created, does not require that such be actually used to update the literal. The constraint is related to the actual modification of the literal.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-24 14:14 -0700 |
| Message-ID | <lno9uivtxr.fsf@kst-u.example.com> |
| In reply to | #110583 |
Robert Wessel <robertwessel2@yahoo.com> writes:
[...]
> But it also would have broken code that was *not* broken. Just
> because a non-const pointer to a string literal was created, does not
> require that such be actually used to update the literal. The
> constraint is related to the actual modification of the literal.
Yet another annoying nitpick:
This is true if you're using "constraint" in its common English sense.
Attempting to modify a string literal (more precisely the array object
corresponding to a string literal) has undefined behavior; it's not a
constraint violation.
char *s = "hello";
s[0] = 'H'; /* UB, no constraint violation */
You can turn many such instances of undefined behavior into constraint
violations (thus catching errors sooner) by judicious use of "const":
const char *s = "hello";
s[0] = 'H'; /* constraint violation */
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-05-25 17:55 +1200 |
| Message-ID | <eon9vcFha6pU5@mid.individual.net> |
| In reply to | #110583 |
On 05/25/17 08:15 AM, Robert Wessel wrote: > On Thu, 25 May 2017 07:33:27 +1200, Ian Collins <ian-news@hotmail.com> > wrote: > >> On 05/25/17 04:10 AM, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> [...] >>>> No, they often cannot be modified in any way. The compiler knows that, >>>> and takes advantage of it. That is a good thing. There is no advantage >>>> to the programmer in being able to modify a string literal, and there is >>>> great advantage in getting more efficient code. >>>> >>>> C++ got it right by making string literals "const". >>> >>> Yes -- and I would argue that C got it right by *not* making string >>> literals "const". >>> >>> C and C++ had different goals. C++ was a new language, with >>> some concern for compatibility with C, but it wasn't an absolute >>> requirement -- and in the case of this particular feature, >>> overloading was also a consideration. Making string literals const >>> in C would have broken existing code. >> >> Broken existing broken code! > > > But it also would have broken code that was *not* broken. Just > because a non-const pointer to a string literal was created, does not > require that such be actually used to update the literal. Until the next maintainer see the pointer as pointing to mutable data and tries to change it. Maybe I should have said broken and booby trapped code. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2017-05-24 23:52 -0700 |
| Message-ID | <og5uo1$l6v$1@dont-email.me> |
| In reply to | #110618 |
On 5/24/2017 10:55 PM, Ian Collins wrote: > On 05/25/17 08:15 AM, Robert Wessel wrote: >> On Thu, 25 May 2017 07:33:27 +1200, Ian Collins <ian-news@hotmail.com> >> wrote: >> >>> On 05/25/17 04:10 AM, Keith Thompson wrote: >>>> David Brown <david.brown@hesbynett.no> writes: >>>> [...] >>>>> No, they often cannot be modified in any way. The compiler knows >>>>> that, >>>>> and takes advantage of it. That is a good thing. There is no >>>>> advantage >>>>> to the programmer in being able to modify a string literal, and >>>>> there is >>>>> great advantage in getting more efficient code. >>>>> >>>>> C++ got it right by making string literals "const". >>>> >>>> Yes -- and I would argue that C got it right by *not* making string >>>> literals "const". >>>> >>>> C and C++ had different goals. C++ was a new language, with >>>> some concern for compatibility with C, but it wasn't an absolute >>>> requirement -- and in the case of this particular feature, >>>> overloading was also a consideration. Making string literals const >>>> in C would have broken existing code. >>> >>> Broken existing broken code! >> >> >> But it also would have broken code that was *not* broken. Just >> because a non-const pointer to a string literal was created, does not >> require that such be actually used to update the literal. > > Until the next maintainer see the pointer as pointing to mutable data > and tries to change it. > > Maybe I should have said broken and booby trapped code. > Yikes!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-25 20:59 +0200 |
| Message-ID | <og79ct$qok$1@dont-email.me> |
| In reply to | #110556 |
On 24/05/17 18:10, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> No, they often cannot be modified in any way. The compiler knows that, >> and takes advantage of it. That is a good thing. There is no advantage >> to the programmer in being able to modify a string literal, and there is >> great advantage in getting more efficient code. >> >> C++ got it right by making string literals "const". > > Yes -- and I would argue that C got it right by *not* making string > literals "const". > > C and C++ had different goals. C++ was a new language, with > some concern for compatibility with C, but it wasn't an absolute > requirement -- and in the case of this particular feature, > overloading was also a consideration. Making string literals const > in C would have broken existing code. > > It certainly would have been better to make string literal "const" > from the beginning, but that wasn't a possibility, and there's > been no good time to make the change. (I was in the process of writing exactly the same thing, in similar words, before reading that paragraph.) > And if you want a language > that's just like C except that C literals are const, you can use > "-Wwrite-strings" (if you happen to be using a gcc-compatible > compiler). > Yes. It is a little odd for a warning option, in that it changes the type of something (string literals). But it gives people the option to choose the behaviour they would like here.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-24 08:59 -0700 |
| Message-ID | <lna862xn31.fsf@kst-u.example.com> |
| In reply to | #110539 |
bartc <bc@freeuk.com> writes:
> On 24/05/2017 13:28, David Brown wrote:
>> On 24/05/17 13:00, bartc wrote:
>> Repeated const is not helpful here,
>
> Why is it even allowed?
>
>>> Conclusion: C type declarations are still a mess.
>>
>> No, the conclusion is that /you/ find C type declarations hard to
>> understand.
>
> No, many people do. Hence the need for cdecl.org.
Yes, C declarations can be confusing, and I occasionally use
cdecl myself. David is trying to help by explaining how they work.
You then jump in and stir things up by complaining about how horrible
they are, offering deliberately confusing examples.
You're not helping.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-24 18:30 +0100 |
| Message-ID | <QqjVA.104628$s26.35121@fx38.am4> |
| In reply to | #110555 |
On 24/05/2017 16:59, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> On 24/05/2017 13:28, David Brown wrote:
>>> On 24/05/17 13:00, bartc wrote:
>>> Repeated const is not helpful here,
>>
>> Why is it even allowed?
>>
>>>> Conclusion: C type declarations are still a mess.
>>>
>>> No, the conclusion is that /you/ find C type declarations hard to
>>> understand.
>>
>> No, many people do. Hence the need for cdecl.org.
>
> Yes, C declarations can be confusing, and I occasionally use
> cdecl myself. David is trying to help by explaining how they work.
> You then jump in and stir things up by complaining about how horrible
> they are, offering deliberately confusing examples.
>
> You're not helping.
I gave examples highlighting what can easily be seen in real code.
DB didn't say anything about const T being equivalent to T const, which
might lead someone, who's only used const T, to think that T const * was
the same as T * const.
And such examples are everywhere. The very first example of 'const*' I
looked for in an application gave me this (part of a function param list):
int argc, const char *const*argv,
Here's another example:
(void*const*,
and another:
const char*, char const**,
I believe that in both of these, it is that char that is const, not any
of the pointers, even though that 'const' has been moved from one side
to the other between the two.
Given the ability to do so, being able to put 'const' just anywhere, and
as many times as you like, then people will do just that.
Anyway if people are genuinely confused by this stuff, then I think it
is better if they knew it was more the language's fault rather than they
being stupid. As seems to be often implied by the posters here.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-05-24 21:46 +0100 |
| Message-ID | <87lgpmt23f.fsf@bsb.me.uk> |
| In reply to | #110568 |
bartc <bc@freeuk.com> writes: > On 24/05/2017 16:59, Keith Thompson wrote: >> bartc <bc@freeuk.com> writes: >>> On 24/05/2017 13:28, David Brown wrote: >>>> On 24/05/17 13:00, bartc wrote: >>>> Repeated const is not helpful here, >>> >>> Why is it even allowed? >>> >>>>> Conclusion: C type declarations are still a mess. >>>> >>>> No, the conclusion is that /you/ find C type declarations hard to >>>> understand. >>> >>> No, many people do. Hence the need for cdecl.org. >> >> Yes, C declarations can be confusing, and I occasionally use >> cdecl myself. David is trying to help by explaining how they work. >> You then jump in and stir things up by complaining about how horrible >> they are, offering deliberately confusing examples. >> >> You're not helping. > > I gave examples highlighting what can easily be seen in real code. > > DB didn't say anything about const T being equivalent to T const, > which might lead someone, who's only used const T, to think that T > const * was the same as T * const. Is there a missing "not" in that paragraph. If T stands for some symbols designating a type, the const T and T const are *not* the same, so DB not saying anything about them being the same was a good thing. His not saying anything about them being the same should not lead someone to think they are. > And such examples are everywhere. The very first example of 'const*' I > looked for in an application gave me this (part of a function param > list): > > int argc, const char *const*argv, You know you can just read this in a linear fashion like the type notation you prefer? It's right to left, but that's not hard to get you head around. > Here's another example: > > (void*const*, That's a syntax error, but if we imagine a valid context for it: void f(void*const*,...); what's puzzling about it? (Again, it reads simply from right to left.) > and another: > > const char*, char const**, > > I believe that in both of these, it is that char that is const, not > any of the pointers, even though that 'const' has been moved from one > side to the other between the two. Yes. Whilst one can image some bizarre distinction between a const char and a char const, C does not. > Given the ability to do so, being able to put 'const' just anywhere, > and as many times as you like, then people will do just that. They will. They put braces and parentheses and such like all over the place too. One day, I'll get to tell them the right way, but for now I must quietly accept the anarchy... > Anyway if people are genuinely confused by this stuff, then I think it > is better if they knew it was more the language's fault rather than > they being stupid. As seems to be often implied by the posters here. Sometimes it's partly the fault of people who prefer to obfuscate rather than explain. Next time, whilst exercising your right to moan about C's types, why not also explain how the types are read and written so as to reduce the total amount of confusion in the world? C isn't going away, and its types won't be changed anytime soon, so why not engage in what (as the public health experts call it) some harm reduction? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-24 22:48 +0100 |
| Message-ID | <OcnVA.87942$O8.33804@fx47.am4> |
| In reply to | #110587 |
On 24/05/2017 21:46, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: >> DB didn't say anything about const T being equivalent to T const, >> which might lead someone, who's only used const T, to think that T >> const * was the same as T * const. > > Is there a missing "not" in that paragraph. If T stands for some > symbols designating a type, the const T and T const are *not* the same, This T is the type that goes on the left of a declaration, before any * or [], for example when T is char, then 'char const' and 'const char': > Yes. Whilst one can image some bizarre distinction between a const > char and a char const, C does not. > so DB not saying anything about them being the same was a good thing. > His not saying anything about them being the same should not lead > someone to think they are. > >> And such examples are everywhere. The very first example of 'const*' I >> looked for in an application gave me this (part of a function param >> list): >> >> int argc, const char *const*argv, > > You know you can just read this in a linear fashion like the type > notation you prefer? It's right to left, but that's not hard to get you > head around. That can happen sometimes, but this is example is not about that. KT said I was making up deliberately confusing examples (with a stream of mixed const and *) and yet the first real example I look at gives me exactly that. And it is still not completely clear what each const applies to. RTL, I assume the right-most 'const' applies to the * to its left, but what about the other one? If it's written like this with numbers to help: const1 char2 *3 const4 *5 then presumably the actual type is: pointer5 to const4 pointer3 of const1 char2. > C isn't going away, and its types won't be changed anytime soon, so why > not engage in what (as the public health experts call it) some harm > reduction? A stricter subset can be defined without changing the language, and that would work with the same compilers, although it would be better if some tools enforced the subset. (There was a post I made recently about things that could be left out of C; a lot of this sort of freedom featured on it, as you don't really need to be able to write this: const char const const typedef unsigned ((const * const (fred))); I don't think it would be too onerous to have to use a canonical form: typedef const unsigned char * const fred; ) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-05-25 01:10 +0100 |
| Message-ID | <87fuftu778.fsf@bsb.me.uk> |
| In reply to | #110592 |
bartc <bc@freeuk.com> writes: > On 24/05/2017 21:46, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: <snip> >>> And such examples are everywhere. The very first example of 'const*' I >>> looked for in an application gave me this (part of a function param >>> list): >>> >>> int argc, const char *const*argv, >> >> You know you can just read this in a linear fashion like the type >> notation you prefer? It's right to left, but that's not hard to get you >> head around. > > That can happen sometimes, but this is example is not about that. KT > said I was making up deliberately confusing examples (with a stream of > mixed const and *) and yet the first real example I look at gives me > exactly that. > > And it is still not completely clear what each const applies to. RTL, > I assume the right-most 'const' applies to the * to its left, but what > about the other one? "argv is a pointer to a const pointer to char const". How can you be confused by that? argv is not const. It points to something (a pointer as it happens) that is const, and that pointer also points to something that is const. > If it's written like this with numbers to help: > > const1 char2 *3 const4 *5 > > then presumably the actual type is: > > pointer5 to const4 pointer3 of const1 char2. I don't know what all these numbers means, but if you find them helpful, (and you get the right result) go for it. But since you claim to be confused by this type, maybe you need to find another way to explain it? I just read the type from the right to the left. <snip> > (There was a post I made recently about things that could be left out > of C; a lot of this sort of freedom featured on it, as you don't > really need to be able to write this: > > const char const const typedef unsigned ((const * const (fred))); Just as well you can't then :-) This wouldn't be a case of you making up a deliberately confusing example, would it? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-25 01:51 +0100 |
| Message-ID | <jUpVA.159611$3w1.155524@fx41.am4> |
| In reply to | #110598 |
On 25/05/2017 01:10, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: >> If it's written like this with numbers to help: >> >> const1 char2 *3 const4 *5 >> >> then presumably the actual type is: >> >> pointer5 to const4 pointer3 of const1 char2. > > I don't know what all these numbers means, but if you find them helpful, > (and you get the right result) go for it. But since you claim to be > confused by this type, maybe you need to find another way to explain it? > I just read the type from the right to the left. I've numbered the elements 12345, left to right. Right-to-left, the digits should be 54321. They're actually 54312. Even for a type spec that is just a chain of pointers, there is some ambiguity. > <snip> >> (There was a post I made recently about things that could be left out >> of C; a lot of this sort of freedom featured on it, as you don't >> really need to be able to write this: >> >> const char const const typedef unsigned ((const * const (fred))); > > Just as well you can't then :-) Actually you've highlighted another problem. I normally post code that compiles, but made some changes then transcribed then wrongly. The version that compiles is this: const char const unsigned const typedef const ((* const (fred))); But the problem is this: how many can really tell the difference between the two? I mean how many can tell which one is legal, and which one is illegal? Language syntax simply shouldn't be that much of a mystery! As for making things up, this illustrates several of these issues in one example: * typedef can occur anywhere (as each full type declaration consists of of part I and II, typedef can occur anywhere within part I) * 'const' can occur either before or after the type in part I, or after a "*" in part II * 'const' can be repeated as many times as you like * Elements such as 'unsigned', 'long' and 'int' can occur in any combination * 'int' can be left out * Some compilers even allow 'typedef' to be repeated, as well as attributes such as 'extern'. * Unnecessary parentheses can be added - in the right places, another mystery - to as many levels as you like. To all that, can be added arbitrary macros, __attribute__()s, __declspecs()s, all mixed up with the elements defining the type. Maybe it's only me that can see that all that can result in a problem when you want readable and consistent code when it is trying to declare the same thing. > This wouldn't be a case of you making up a deliberately confusing > example, would it? You think I'm exaggerating with my examples, but believe me I'm toning them down, compared with real ones I've seen! There is just too much variability. You use one style for a long time, then see another one you've never used, and are confused. Some long-term C coders even expressed surprise that you could do this, with the parentheses: int (a); I expect some will also be surprised at this: (a,b); With my restrictions, they would be written as: int a; int a,b; Fewer surprises. -- bartc
[toc] | [prev] | [next] | [standalone]
Page 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web