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 4 of 13 — ← Prev page 1 2 3 [4] 5 6 … 13 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-05-25 03:41 +0100 |
| Message-ID | <874lw9u08v.fsf@bsb.me.uk> |
| In reply to | #110602 |
bartc <bc@freeuk.com> writes: > 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. No, left to right they are 54321. You can complicate it if you like (and I know you do like to complicate it), but the simplest reading is in sequence. <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! The syntax is published for anyone who wants to remove sense of 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) So *not* anywhere, in fact. You could use the terms used in the grammar and thereby help educate readers, but, no, you'd rather make up "part I and II" to maintain as much confusion in readers as possible. > * '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. No. Why do you think that? >> 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! I think you are exaggerating how complex the first declaration is (the one with the simple linear reading). But I do also think you made up that other example to be deliberately confusing. That does not mean I think you are exaggerating with it (you may well have found repeated consts and redundant parentheses in real examples), just that you made it up to be deliberately (and otherwise pointlessly) confusing. > 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); It's certainly much better to avoid writing that. I don't write (1) where 1 would do either. > I expect some will also be surprised at this: > > (a,b); Eh? In what version of C is that a declaration? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-25 12:18 +0100 |
| Message-ID | <P3zVA.152600$op5.7903@fx39.am4> |
| In reply to | #110612 |
On 25/05/2017 03:41, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
>
>> 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.
>
> No, left to right they are 54321.
Left to right they are 12345 because I numbered them like that:
const1 char2 *3 const4 *5
Or, since, you are pretending not to understand:
const char * const *
1 2 3 4 5
You would probably express this as:
pointer to const pointer to const char
5 4 3 1 2
The numbers below the elements (do I really have to spell this out?)
link each element here with the elements in the type spec in C. Notice
the sequence is 54312. So my point (a small one but it's taken some
effort to put it across) is that a pure right-to-left reading doesn't
quite work.
> You can complicate it if you like
> (and I know you do like to complicate it), but the simplest reading is
> in sequence.
So, pointer to const pointer to char const? What if someone had instead
written char const * const * instead? They would get a slightly
different answer. The same if any const was repeated. It seems some
normalisation has to take place on top of the right to left reading.
>> 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!
>
> The syntax is published for anyone who wants to remove sense of mystery.
OK, let get me this right. You are suggesting it doesn't matter how
unnecessarily complicated or convoluted someone makes any syntax for a
language, provided it is properly written up?
BTW, even K&R2 disagrees with you. On page 122, it says: "C is sometimes
castigated for the syntax of its declarations. .... it can be confusing
for the harder ones, because declarations cannot be read left to right,
and because parentheses are over-used.
The points I'm making are that even /with/ C declarations are they are,
the language allows them to be written in an even more complicated
manner, or with more variability than is needed. Type declarations are
NOT expressions. (Obviously /your/ brain is wired differently so the two
are interchangeable.)
>> 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)
>
> So *not* anywhere, in fact.
> You could use the terms used in the grammar and thereby help educate
> readers, but, no, you'd rather make up "part I and II" to maintain as
> much confusion in readers as possible.
So, how would /you/ explain the different places that typedef is allowed?
How would /you/ explain, of the type of Z in this declaration, namely
'const int*[10]', why half of is at the start of the line, and half at
the end?
const int U, V, W, X, Y, *Z[10];
How would /you/ explain, in the following example, why typedef is
allowed at the first three points marked ¦, but not the last three?
¦ const ¦ int ¦ * ¦ Z ¦ [10] ¦;
All those elements contribute towards declaring the type of Z. Yet some
are specially blessed with the ability of having typedef (or static
etc), and others aren't.
And referring to some chapter and verse in a reference manual is not an
answer.
> I think you are exaggerating how complex the first declaration is (the
> one with the simple linear reading). But I do also think you made up
> that other example to be deliberately confusing.
Yes, examples are sometimes made up to highlight a point. In this case,
even though C type specs can be complicated enough, C also allows them
to be written chaotically.
Of all the lurkers reading this sub-thread, hands up those who never
even knew that typedef could be anywhere but at the start of a
declaration? (Hands up obviously won't work; you might have to actually
post a reply!)
Actually, a few might even be surprised that typedef can declare several
/different/ types in the same statement. It's not that common, so seeing
it is confusing:
typedef struct pt {int x,y;} point, *Point, point3[3];
> That does not mean I
> think you are exaggerating with it (you may well have found repeated
> consts and redundant parentheses in real examples), just that you made
> it up to be deliberately (and otherwise pointlessly) confusing.
I've found all sorts of things in real examples. Here's gcc's
declaration of 'printf' in the stdio.h it uses:
__mingw_ovr
__attribute__((__format__ (gnu_printf, 1, 2))) __MINGW_ATTRIB_NONNULL(1)
int printf (const char *__format, ...)
{
register int __retval;
__builtin_va_list __local_argv; __builtin_va_start( __local_argv,
__format );
__retval = __mingw_vprintf( __format, __local_argv );
__builtin_va_end( __local_argv );
return __retval;
}
Here's how I might declare it:
int printf(char*, ...);
How on earth did something so simple turn into the above? (BTW that was
the same printf declaration that doesn't work with %zu.)
> Some
>> long-term C coders even expressed surprise that you could do this,
>> with the parentheses:
>>
>> int (a);
>
> It's certainly much better to avoid writing that. I don't write (1)
> where 1 would do either.
People are used to seeing (x) instead of x - in an expression. In fact
they are used to seeing parentheses in expressions, full stop.
They are not used to seeing them in simple declarations. (This example
comes up when a typedef is used, then they might well see f(a); highly
confusing.)
>> I expect some will also be surprised at this:
>>
>> (a,b);
>
> Eh? In what version of C is that a declaration?
I mixed up two things. (See, when nearly everything is allowed, you can
no longer see the boundaries.)
This:
(a);
b,c;
compiles at filescope with either just warnings, or not even that.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-05-25 22:26 +0100 |
| Message-ID | <87shjssk4l.fsf@bsb.me.uk> |
| In reply to | #110624 |
bartc <bc@freeuk.com> writes:
> On 25/05/2017 03:41, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>>
>>> 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.
<snip>
> const1 char2 *3 const4 *5
>
> Or, since, you are pretending not to understand:
No, I am not pretending anything.
> const char * const *
> 1 2 3 4 5
>
> You would probably express this as:
>
> pointer to const pointer to const char
> 5 4 3 1 2
No. Why on Earth would I do that? The whole point that the declaration
is not complex -- it can be read simply in sequence. For some reason
you keep insisting that 1 and 2 must be swapped. First you seemed to
suggest it was just the thing to do, now you are suggest that I'd
express it that way.
> The numbers below the elements (do I really have to spell this out?)
> link each element here with the elements in the type spec in C.
Sigh. Of course not. I get the numbering. I just don't know why you
won't read it the simple way. I assume it's because you have a lot
invested that all being so very difficult.
> Notice
> the sequence is 54312.
Yes. I noticed it many posts ago and still don't know why want to use
it. As I said, you are free to number things that way and the flip the
last two but I can't see why you would do that.
> So my point (a small one but it's taken some
> effort to put it across) is that a pure right-to-left reading doesn't
> quite work.
It works fine. You've never said why it does not work.
<snip>
>>> 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!
>>
>> The syntax is published for anyone who wants to remove sense of mystery.
>
> OK, let get me this right. You are suggesting it doesn't matter how
> unnecessarily complicated or convoluted someone makes any syntax for a
> language, provided it is properly written up?
No. I meant what I wrote. You should probably try to read less into it
that you do.
> BTW, even K&R2 disagrees with you. On page 122, it says: "C is
> sometimes castigated for the syntax of its declarations. .... it can
> be confusing for the harder ones, because declarations cannot be read
> left to right, and because parentheses are over-used.
Why do you think that is a point of disagreement?
> The points I'm making are that even /with/ C declarations are they
> are, the language allows them to be written in an even more
> complicated manner, or with more variability than is needed. Type
> declarations are NOT expressions. (Obviously /your/ brain is wired
> differently so the two are interchangeable.)
>
>>> 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)
>>
>> So *not* anywhere, in fact.
>
>> You could use the terms used in the grammar and thereby help educate
>> readers, but, no, you'd rather make up "part I and II" to maintain as
>> much confusion in readers as possible.
>
> So, how would /you/ explain the different places that typedef is
> allowed?
A declaration contains a syntactic form called a declarator. It's handy
to know what that is because its the part that has the name and that
gets all the decoration about pointers, arrays and functions. It's what
lets you declare multiple objects of the same type (int a, b, c;) and
what let's you (horrors!) declare objects of some derived types without
repeating what are called the declaration specifiers (int a, *b, c[3];).
It's a rough sketch, but it's better that "part I and II".
> How would /you/ explain, of the type of Z in this declaration, namely
> 'const int*[10]', why half of is at the start of the line, and half at
> the end?
>
> const int U, V, W, X, Y, *Z[10];
Declaration specifiers (const int) are followed by a list of
declarators. Five are a simple as they can be, and the sixth is *Z[10];
Each declarator describes the relationship between the declared object
and the declaration specifiers. The simples ones you just read as
"is". The last one you read as "is an array of ten pointers to".
> How would /you/ explain, in the following example, why typedef is
> allowed at the first three points marked ¦, but not the last three?
>
> ¦ const ¦ int ¦ * ¦ Z ¦ [10] ¦;
I would first remove the markings you';ve added because they are they
due to either your misunderstand or your desire to obfuscate the
example.
There are declaration specifiers, and a single declarator with no
initialisation:
const int *Z[10] ;
The declarator is a tiny expression grammar so *Z[10] means *(Z[10]) (or
even (*((Z)[10])) if you want it fully bracketed). This little
expression grammar is why Z is and array of pointers and not a pointer
to an array. To get the other meaning you must use brackets: (*Z)[10].
I would not try to explain the whole thing at once because, due to C's
long evolution, the grammar is now very fussy, but the basic separation
of declaration specifiers followed by a (possible) list of declarators
(with optional initialisation) has remained at the heart of the grammar.
> All those elements contribute towards declaring the type of Z. Yet
> some are specially blessed with the ability of having typedef (or
> static etc), and others aren't.
Yup.
> And referring to some chapter and verse in a reference manual is not
> an answer.
Not for students, no, but it surely is for you since you are a compiler
writer. The C standard should be your definitive reference for this
stuff.
<snip>
> Of all the lurkers reading this sub-thread, hands up those who never
> even knew that typedef could be anywhere but at the start of a
> declaration? (Hands up obviously won't work; you might have to
> actually post a reply!)
I wonder if anyone else reads these exchanges!
> Actually, a few might even be surprised that typedef can declare
> several /different/ types in the same statement. It's not that common,
> so seeing it is confusing:
>
> typedef struct pt {int x,y;} point, *Point, point3[3];
Indeed. And few people know you can typedef a function type and declare
functions using it:
typedef int bin_op(int, int);
bin_op add, subtract, multiply, divide, remainder;
There's a lot of mental cut-and-paste C programming going on. People
copy what they've seen and just change the names.
>> That does not mean I
>> think you are exaggerating with it (you may well have found repeated
>> consts and redundant parentheses in real examples), just that you made
>> it up to be deliberately (and otherwise pointlessly) confusing.
>
> I've found all sorts of things in real examples. Here's gcc's
> declaration of 'printf' in the stdio.h it uses:
>
> __mingw_ovr
> __attribute__((__format__ (gnu_printf, 1, 2))) __MINGW_ATTRIB_NONNULL(1)
> int printf (const char *__format, ...)
> {
> register int __retval;
> __builtin_va_list __local_argv; __builtin_va_start( __local_argv, __format );
> __retval = __mingw_vprintf( __format, __local_argv );
> __builtin_va_end( __local_argv );
> return __retval;
> }
>
> Here's how I might declare it:
>
> int printf(char*, ...);
You know that's wrong? Using the wrong type just a wind-up, right?
And you know you showed a *defintion* of printf, not just a declaration,
yes?
And can you explain why each part of the declaration you quoted is
there and thus why you can dispense with it?
> How on earth did something so simple turn into the above? (BTW that
> was the same printf declaration that doesn't work with %zu.)
No declaration can fix Microsoft's printf. If it could, then %zu would
have been working with MS's C runtime a long time ago.
>> Some
>>> long-term C coders even expressed surprise that you could do this,
>>> with the parentheses:
>>>
>>> int (a);
>>
>> It's certainly much better to avoid writing that. I don't write (1)
>> where 1 would do either.
>
> People are used to seeing (x) instead of x - in an expression. In fact
> they are used to seeing parentheses in expressions, full stop.
I think all C programmers are used to seeing parentheses in declarations
or they would not have been able to write any functions.
> They are not used to seeing them in simple declarations. (This example
> comes up when a typedef is used, then they might well see f(a); highly
> confusing.)
Yes, highly confusing. Make a note to yourself to always use that exact
type name and spacing in future posts.
>>> I expect some will also be surprised at this:
>>>
>>> (a,b);
>>
>> Eh? In what version of C is that a declaration?
>
> I mixed up two things. (See, when nearly everything is allowed, you
> can no longer see the boundaries.)
No, I *can* see the boundaries. But then I'm old-school. I try to
learn, and then refer to, the grammars of the programming languages I
use. It's not done these days I know, but I can't help it -- I like to
know what I can and can't write.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-25 23:25 +0100 |
| Message-ID | <1RIVA.116182$hr1.64576@fx15.am4> |
| In reply to | #110657 |
On 25/05/2017 22:26, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
> There are declaration specifiers, and a single declarator with no
> initialisation:
>
> const int *Z[10] ;
>
> The declarator is a tiny expression grammar so *Z[10] means *(Z[10]) (or
> even (*((Z)[10])) if you want it fully bracketed). This little
> expression grammar is why Z is and array of pointers and not a pointer
> to an array. To get the other meaning you must use brackets: (*Z)[10].
>
> I would not try to explain the whole thing at once because, due to C's
> long evolution, the grammar is now very fussy, but the basic separation
> of declaration specifiers followed by a (possible) list of declarators
> (with optional initialisation) has remained at the heart of the grammar.
So you have a type that is put together using a declaration specifier,
and a declarator.
I think it would have been difficult to have chosen two names more
confusing (look away for a second and you've instantly forgotten which
is which). Then you have abstract declarators and direct abstract
declarators. And, sometimes, declarations.
Note that the grammar in the C standard most likely is for machine
processing. I don't think it is intended to be a reference for humans.
Anyway, I just call them part I and part II, as part I comes first. I
found that a LOT easier to work with.
But when all is done however, and you have your type, then the
distinction disappears: the resulting type is one chain of elements with
no joins.
The two parts are an artefact of the syntax.
> Not for students, no, but it surely is for you since you are a compiler
> writer. The C standard should be your definitive reference for this
> stuff.
I found it poor. The nomenclature is not friendly with many names all
sounding the same. The stuff about the preprocessor I've already
expressed my views on.
> Indeed. And few people know you can typedef a function type and declare
> functions using it:
>
> typedef int bin_op(int, int);
>
> bin_op add, subtract, multiply, divide, remainder;
Don't go giving people ideas!
>> I've found all sorts of things in real examples. Here's gcc's
>> declaration of 'printf' in the stdio.h it uses:
>>
>> __mingw_ovr
>> __attribute__((__format__ (gnu_printf, 1, 2))) __MINGW_ATTRIB_NONNULL(1)
>> int printf (const char *__format, ...)
>> {...
>> Here's how I might declare it:
>>
>> int printf(char*, ...);
>
> You know that's wrong? Using the wrong type just a wind-up, right?
How can it be wrong? It's in header belonging to the implementation;
that can decide how it is to be declared.
> And you know you showed a *defintion* of printf, not just a declaration,
> yes?
Well, it looks more like a wrapper, but whatever it is, it apparently
ends up calling exactly the same *printf() function in msvcrt.dll that
my declaration does.
> And can you explain why each part of the declaration you quoted is
> there and thus why you can dispense with it?
There's no reason why it's like that, except that gcc (or whoever is
responsible for the stdio.h it uses) likes to make things complicated.
Someone tried to explain that it tells gcc that this marks iy as a
special *printf family function that then lets it apply format-checking.
But it turned out you could remove this stuff (replace #include
<stdio.h> with 'int printf(char*,...);', and it still did all that.
>> I mixed up two things. (See, when nearly everything is allowed, you
>> can no longer see the boundaries.)
>
> No, I *can* see the boundaries. But then I'm old-school. I try to
> learn, and then refer to, the grammars of the programming languages I
> use. It's not done these days I know, but I can't help it -- I like to
> know what I can and can't write.
And I'm of a different school (with experience of technical support) and
I can see what things are likely to be confusing.
So, a language allows a simple declaration to look like a function call.
My reaction: don't allow it. Yours: no-one's going to do that so it
doesn't matter. But in that case, why does it matter if it's not allowed?
It's one less thing to check when faced with a baffling declaration, if
it IS a declaration.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-25 17:03 -0700 |
| Message-ID | <lninkov614.fsf@kst-u.example.com> |
| In reply to | #110662 |
bartc <bc@freeuk.com> writes:
[...]
> There's no reason why it's like that, except that gcc (or whoever is
> responsible for the stdio.h it uses) likes to make things complicated.
[...]
It's not gcc. Why do you continue to claim that printf is provided by
gcc when it's been explained to you countless times that that's not the
case, as well as why it's not the case?
--
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-26 01:09 +0100 |
| Message-ID | <WmKVA.142762$lN5.31448@fx40.am4> |
| In reply to | #110664 |
On 26/05/2017 01:03, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: > [...] >> There's no reason why it's like that, except that gcc (or whoever is >> responsible for the stdio.h it uses) likes to make things complicated. > [...] > > It's not gcc. Why do you continue to claim that printf is provided by > gcc when it's been explained to you countless times that that's not the > case, as well as why it's not the case? Didn't I state that it was whoever was responsible for it? Although if that stdio.h really is NOTHING to do with gcc [the Windows version] then it makes you wonder which compiler it might have been aimed at with things like '__mingw_ovr' and __attribute__((__format__.... which I doubt make much sense anywhere else. Would you really expect all that in a compiler-neutral [not OS-neutral] header? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-26 13:29 +0200 |
| Message-ID | <og93d8$rrj$1@dont-email.me> |
| In reply to | #110665 |
On 26/05/17 02:09, bartc wrote: > On 26/05/2017 01:03, Keith Thompson wrote: >> bartc <bc@freeuk.com> writes: >> [...] >>> There's no reason why it's like that, except that gcc (or whoever is >>> responsible for the stdio.h it uses) likes to make things complicated. >> [...] >> >> It's not gcc. Why do you continue to claim that printf is provided by >> gcc when it's been explained to you countless times that that's not the >> case, as well as why it's not the case? > > Didn't I state that it was whoever was responsible for it? > > Although if that stdio.h really is NOTHING to do with gcc [the Windows > version] then it makes you wonder which compiler it might have been > aimed at with things like '__mingw_ovr' and > __attribute__((__format__.... which I doubt make much sense anywhere else. > > Would you really expect all that in a compiler-neutral [not OS-neutral] > header? > Is it so hard for you to comprehend that this header was written to be used with gcc, but not written /by/ the gcc developers?
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-06-03 10:24 +0000 |
| Message-ID | <59328d83.274531@news.xs4all.nl> |
| In reply to | #110686 |
David Brown <david.brown@hesbynett.no> wrote: > On 26/05/17 02:09, bartc wrote: > > Although if that stdio.h really is NOTHING to do with gcc [the Windows > > version] then it makes you wonder which compiler it might have been > > aimed at with things like '__mingw_ovr' and > > __attribute__((__format__.... which I doubt make much sense anywhere else. > > > > Would you really expect all that in a compiler-neutral [not OS-neutral] > > header? > > Is it so hard for you to comprehend that this header was written to be > used with gcc, but not written /by/ the gcc developers? Is it so hard for _you_ and all the other GNU apologists to comprehend that, to the normal user-programmer, _it should not matter_? This is one of the few things on which bartc is, presumably by accident, correct. An implementation is an implementation. There is no such thing as "only a compiler" or "only the headers", to the Standard. There is only an implementation. That's how it ought to be to the end programmer, as well; and therefore, GNU's stance that "we only provide two halves, we barely speak to one another" is disingenuous. Richard
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-06-04 16:35 +0200 |
| Message-ID | <oh15k3$1kq$1@dont-email.me> |
| In reply to | #111345 |
On 03/06/17 12:24, Richard Bos wrote: > David Brown <david.brown@hesbynett.no> wrote: > >> On 26/05/17 02:09, bartc wrote: > >>> Although if that stdio.h really is NOTHING to do with gcc [the Windows >>> version] then it makes you wonder which compiler it might have been >>> aimed at with things like '__mingw_ovr' and >>> __attribute__((__format__.... which I doubt make much sense anywhere else. >>> >>> Would you really expect all that in a compiler-neutral [not OS-neutral] >>> header? >> >> Is it so hard for you to comprehend that this header was written to be >> used with gcc, but not written /by/ the gcc developers? > > Is it so hard for _you_ and all the other GNU apologists to comprehend > that, to the normal user-programmer, _it should not matter_? > > This is one of the few things on which bartc is, presumably by accident, > correct. An implementation is an implementation. There is no such thing > as "only a compiler" or "only the headers", to the Standard. There is > only an implementation. That's how it ought to be to the end programmer, > as well; and therefore, GNU's stance that "we only provide two halves, > we barely speak to one another" is disingenuous. > To some extent, I agree with you - certainly most programmers want a C implementation, not several bits of an implementation from different places. However, you are talking about what you think /should/ be the case - I am trying to get Bart to understand what /is/ the case. There is also a big distinction between what a C programmer might like, and what is appropriate for a system to have underneath. There are many good reasons for mixing and matching the compiler itself, and the library. For example, on Linux systems it is not uncommon to have both gcc and clang - and want to use the same library for both. But different Linux systems can have different libraries - a "normal" system will probably have glibc, but a small or embedded Linux system will want a library optimised for size rather than features. In my work, I use gcc for something like half a dozen different targets - and perhaps as many different C libraries. One of the key points about having the standard C library described in the C standards, without requiring it to be part of a specific compiler, is that you can do this - and still have confidence in the common set of features of the library. It requires that the library and the compiler work together to form a C implementation - but it does not require that they are made by the same people. From the end user's viewpoint, it is always easier if it is seen as a complete package - often along with a debugger, IDE, and other tools. And often that is how it is distributed. When you install mingw64 and msys2, you install a variety of bits and pieces written by different groups, but working together. The same applies when you do "apt-get install build-essentials", or download Freescale/NXP's "Kinetis Design Studio" for ARM-based microcontrollers. But that does /not/ mean that when you dig into the implementation details - the stuff that is usually hidden or ignored by most users - you should be surprised to find that the different parts are more general than needed for the particular combination that /you/ happen to be using!
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-05-26 03:41 +0100 |
| Message-ID | <87h908s5jp.fsf@bsb.me.uk> |
| In reply to | #110662 |
bartc <bc@freeuk.com> writes:
> On 25/05/2017 22:26, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>
>> There are declaration specifiers, and a single declarator with no
>> initialisation:
>>
>> const int *Z[10] ;
>>
>> The declarator is a tiny expression grammar so *Z[10] means *(Z[10]) (or
>> even (*((Z)[10])) if you want it fully bracketed). This little
>> expression grammar is why Z is and array of pointers and not a pointer
>> to an array. To get the other meaning you must use brackets: (*Z)[10].
>>
>> I would not try to explain the whole thing at once because, due to C's
>> long evolution, the grammar is now very fussy, but the basic separation
>> of declaration specifiers followed by a (possible) list of declarators
>> (with optional initialisation) has remained at the heart of the grammar.
>
> So you have a type that is put together using a declaration specifier,
> and a declarator.
>
> I think it would have been difficult to have chosen two names more
> confusing (look away for a second and you've instantly forgotten which
> is which).
Part I and part II are quite confusing since they imply a division that
is not really there. What is part II in "int a, b;"?
<snip>
> Anyway, I just call them part I and part II, as part I comes first. I
> found that a LOT easier to work with.
If, like your odd reading of a linear type, it helps you that's fine. I
would not use those terms.
> But when all is done however, and you have your type, then the
> distinction disappears: the resulting type is one chain of elements
> with no joins.
>
> The two parts are an artefact of the syntax.
The syntax is nested and some "parts" can be repeated so I don't think
naming them I and II is such a good idea, but provided you know that a
declaration can have several part IIs and nested part Is I don't think
you'll go too far wrong.
<snip>
>>> I've found all sorts of things in real examples. Here's gcc's
>>> declaration of 'printf' in the stdio.h it uses:
>>>
>>> __mingw_ovr
>>> __attribute__((__format__ (gnu_printf, 1, 2))) __MINGW_ATTRIB_NONNULL(1)
>>> int printf (const char *__format, ...)
>>> {...
>
>>> Here's how I might declare it:
>>>
>>> int printf(char*, ...);
>>
>> You know that's wrong? Using the wrong type just a wind-up, right?
>
> How can it be wrong? It's in header belonging to the implementation;
> that can decide how it is to be declared.
printf takes a const char *.
>> And you know you showed a *defintion* of printf, not just a declaration,
>> yes?
>
> Well, it looks more like a wrapper, but whatever it is, it apparently
> ends up calling exactly the same *printf() function in msvcrt.dll that
> my declaration does.
So is that a yes? You did know you quoted a whole definition? Was the
declaration not complex enough to make your point?
>> And can you explain why each part of the declaration you quoted is
>> there and thus why you can dispense with it?
>
> There's no reason why it's like that, except that gcc (or whoever is
> responsible for the stdio.h it uses) likes to make things complicated.
No, that's not it.
> Someone tried to explain that it tells gcc that this marks iy as a
> special *printf family function that then lets it apply
> format-checking. But it turned out you could remove this stuff
> (replace #include <stdio.h> with 'int printf(char*,...);', and it
> still did all that.
I missed that exchange. Do you happen to have link to it?
>>> I mixed up two things. (See, when nearly everything is allowed, you
>>> can no longer see the boundaries.)
>>
>> No, I *can* see the boundaries. But then I'm old-school. I try to
>> learn, and then refer to, the grammars of the programming languages I
>> use. It's not done these days I know, but I can't help it -- I like to
>> know what I can and can't write.
>
> And I'm of a different school (with experience of technical support)
> and I can see what things are likely to be confusing.
And you think I don't? I keep trying to explain that thing are not the
hopeless mess of confusion that you say they are. And I keep trying to
reduce the confusion you spread by your incorrect or peculiar
explanations. That then causes you to think I can't see what thing are
likely to be confusing. Having taught this material, I've got a very
clear idea of what's confusing about C.
> So, a language allows a simple declaration to look like a function
> call. My reaction: don't allow it. Yours: no-one's going to do that so
> it doesn't matter. But in that case, why does it matter if it's not
> allowed?
Your putting words into my mouth is getting very annoying. I know it's
just your rhetorical shtick, but it's tedious to have to keep correcting
it. You never reply to my requests for evidence to back-up they claims
you attribute to others, so I presume you know you are just making it up.
> It's one less thing to check when faced with a baffling declaration,
> if it IS a declaration.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-26 11:51 +0100 |
| Message-ID | <9MTVA.118475$hr1.102607@fx15.am4> |
| In reply to | #110669 |
On 26/05/2017 03:41, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
>> How can it be wrong? It's in header belonging to the implementation;
>> that can decide how it is to be declared.
>
> printf takes a const char *.
And 'restrict'.
But can a program break if a declaration uses char * instead of const
char *? Would the generated code be any different?
(You can't say the compiler might do this or that, because I'm the
implementer.)
>> Someone tried to explain that it tells gcc that this marks iy as a
>> special *printf family function that then lets it apply
>> format-checking. But it turned out you could remove this stuff
>> (replace #include <stdio.h> with 'int printf(char*,...);', and it
>> still did all that.
>
> I missed that exchange. Do you happen to have link to it?
I can't do links. The thread was "Is extern necessary", and the post
where that was first mentioned I think was by David Brown on 14-Feb-2017
08:28 UK time.
That example was about this declaration:
extern
__attribute__((__format__ (gnu_printf, 3, 0))) __MINGW_ATTRIB_NONNULL(3)
int __cdecl __mingw_vsnprintf(char * __restrict__ _DstBuf,size_t
_MaxCount,
const char * __restrict__ _Format,
va_list _ArgList);
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-26 13:43 +0200 |
| Message-ID | <og9468$uhg$1@dont-email.me> |
| In reply to | #110683 |
On 26/05/17 12:51, bartc wrote: > On 26/05/2017 03:41, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: > >>> How can it be wrong? It's in header belonging to the implementation; >>> that can decide how it is to be declared. >> >> printf takes a const char *. > > And 'restrict'. > > But can a program break if a declaration uses char * instead of const > char *? Would the generated code be any different? Yes: const char * format = "Hello, world\r\n"; printf(format); If printf is declared without "const", then using it like this will likely trigger a diagnostic or warning. The lack of "restrict" will not cause any issues or difference to the calling code. > > (You can't say the compiler might do this or that, because I'm the > implementer.) > >>> Someone tried to explain that it tells gcc that this marks iy as a >>> special *printf family function that then lets it apply >>> format-checking. But it turned out you could remove this stuff >>> (replace #include <stdio.h> with 'int printf(char*,...);', and it >>> still did all that. >> >> I missed that exchange. Do you happen to have link to it? > > I can't do links. The thread was "Is extern necessary", and the post > where that was first mentioned I think was by David Brown on 14-Feb-2017 > 08:28 UK time. > > That example was about this declaration: > > extern > __attribute__((__format__ (gnu_printf, 3, 0))) __MINGW_ATTRIB_NONNULL(3) > int __cdecl __mingw_vsnprintf(char * __restrict__ _DstBuf,size_t > _MaxCount, > const char * __restrict__ _Format, > va_list _ArgList); > I have almost certainly told you about the point of these attributes in previous threads - they exist to inform the compiler that it can do compile-time checking of the arguments, which is extremely useful. In the case of functions like "printf" that are defined in the C standards, on a hosted implementation, the compiler can assume that they work the way the standard says, and therefore do such checking even without the __attribute__ markers on the declaration. However, it may well be that in previous versions of gcc, the compiler did /not/ do this without the __attribute__ markers. It may also be that other compilers, such as clang, can do such checking only if the markers are there. And on freestanding implementations (such as usually used in embedded systems), a user can provide their own printf function - it does not have to conform to the standards. So someone using a freestanding build of gcc (or with the "-ffreestanding option", or perhaps the "-fno-builtin" option), might appreciate these attributes on the declaration. And of course, someone who reads these headers with an open mind and a reference to their compiler manual, can learn from them and make use of them in their own code.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-26 09:29 -0700 |
| Message-ID | <ln60gnvax2.fsf@kst-u.example.com> |
| In reply to | #110683 |
bartc <bc@freeuk.com> writes:
> On 26/05/2017 03:41, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>>> How can it be wrong? It's in header belonging to the implementation;
>>> that can decide how it is to be declared.
>>
>> printf takes a const char *.
>
> And 'restrict'.
>
> But can a program break if a declaration uses char * instead of const
> char *? Would the generated code be any different?
>
> (You can't say the compiler might do this or that, because I'm the
> implementer.)
Isn't it easier to declare it correctly (i.e., as specified by the
standard) than to drop qualifiers and then try to prove that it's
safe to do so?
--
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 | 2017-05-28 22:20 -0700 |
| Message-ID | <kfnvaokdyt5.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110662 |
bartc <bc@freeuk.com> writes: > Note that the grammar in the C standard most likely is for machine > processing. I don't think it is intended to be a reference for humans. I'm offering a bet of 1,000 dollars (US) that the people who wrote it would say otherwise.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-05-29 07:51 +0100 |
| Message-ID | <87efv840lf.fsf@gmail.com> |
| In reply to | #110847 |
Tim Rentsch <txr@alumni.caltech.edu> writes: > bartc <bc@freeuk.com> writes: > >> Note that the grammar in the C standard most likely is for machine >> processing. I don't think it is intended to be a reference for humans. > > I'm offering a bet of 1,000 dollars (US) that the people who > wrote it would say otherwise. Honestly, I have no idea why smart people continue to reply to Bartc. He's either entirely deviod of good faith, or dumber than a box of rocks.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-30 06:40 -0700 |
| Message-ID | <kfn1sr6ea3f.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110848 |
Gareth Owen <gwowen@gmail.com> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: > >> bartc <bc@freeuk.com> writes: >> >>> Note that the grammar in the C standard most likely is for machine >>> processing. I don't think it is intended to be a reference for humans. >> >> I'm offering a bet of 1,000 dollars (US) that the people who >> wrote it would say otherwise. > > Honestly, I have no idea why smart people continue to reply to Bartc. > He's either entirely deviod of good faith, or dumber than a box of rocks. I sometimes choose to interact with, oh, let me say people who are off the beaten path, to see if I can develop communication skills with unusual personality types. But you're probably right that I do so more than I should in some cases.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-29 11:37 +0100 |
| Message-ID | <yRSWA.159426$Ng5.136189@fx08.am4> |
| In reply to | #110847 |
On 29/05/2017 06:20, Tim Rentsch wrote:
> bartc <bc@freeuk.com> writes:
>
>> Note that the grammar in the C standard most likely is for machine
>> processing. I don't think it is intended to be a reference for humans.
>
> I'm offering a bet of 1,000 dollars (US) that the people who
> wrote it would say otherwise.
Naturally.
But the version of it from page 234 of K&R2 includes these preliminary
notes: "This grammar can be transformed mechanically into input
acceptable to an automatic parse generator." "...With one further
change... this grammar is acceptable to the YACC parser-generator".
That grammar starts off:
translation unit:
external-declaration
translation-unit external declaration
And the version in Appendix A for C11 contains exactly the same.
Even this very short extract shows the problem; what is this saying,
that a program (a 'translation unit') consists of a sequence of one or
more 'external declarations'? If so, then that's a roundabout way of
saying so.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-30 06:25 -0700 |
| Message-ID | <kfn60gieat6.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110859 |
bartc <bc@freeuk.com> writes: > On 29/05/2017 06:20, Tim Rentsch wrote: >> bartc <bc@freeuk.com> writes: >> >>> Note that the grammar in the C standard most likely is for machine >>> processing. I don't think it is intended to be a reference for humans. >> >> I'm offering a bet of 1,000 dollars (US) that the people who >> wrote it would say otherwise. > > Naturally. > > But the version of it from page 234 of K&R2 includes these preliminary > notes: "This grammar can be transformed mechanically into input > acceptable to an automatic parse generator." "...With one further > change... this grammar is acceptable to the YACC parser-generator". Any context free grammar can be transformed mechanically into input acceptable to an automatic parse generator. Indeed that is one of the advantages in using such a grammar as a reference intended for humans. > That grammar starts off: > > translation unit: > external-declaration > translation-unit external declaration > > And the version in Appendix A for C11 contains exactly the same. > > Even this very short extract shows the problem; what is this saying, > that a program (a 'translation unit') consists of a sequence of one or > more 'external declarations'? If so, then that's a roundabout way of > saying so. You are a stunningly ignorant man.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-30 16:06 +0100 |
| Message-ID | <bUfXA.196836$8r1.104005@fx42.am4> |
| In reply to | #110939 |
On 30/05/2017 14:25, Tim Rentsch wrote: > bartc <bc@freeuk.com> writes: >> That grammar starts off: >> >> translation unit: >> external-declaration >> translation-unit external declaration >> >> And the version in Appendix A for C11 contains exactly the same. >> >> Even this very short extract shows the problem; what is this saying, >> that a program (a 'translation unit') consists of a sequence of one or >> more 'external declarations'? If so, then that's a roundabout way of >> saying so. > > You are a stunningly ignorant man. Thank you. But what is it that I am ignorant about exactly? I'm saying this grammar could be have been more human-friendly, that is, clearer to ordinary programmers who might not quite be in the exalted ranks of the C experts here. (Who, of course, have never quibbled about the meaning of some detail of the C Standard because it is perfect, and 100% unambiguous.) For example, I might have written the above like this: translation-unit = external-decl |+ Of which: * It tells you directly that 'translation-unit' consists of one or more external-decls. * It doesn't need to use a recursive definition, because the actual syntactical construct that it defines in the source code, is not recursive or nested, but sequential. * 'translation-unit' and 'external-decl' both appear only once rather than twice, so you don't need to double check they are the same. * Because there are so many productions that end with -declaration, with the short -decl version, the prefix used is more dominant, making it easier to tell them apart. And it is shorter than 'declarator' so helps there too. And that's just the first three lines! (Which in the new version, are not even at the start. Nor at the end. They're somewhere in the middle...) But I understand that the C Standard is above criticism. Anyone who does so *must* be an ignorant bozo. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-30 15:11 -0700 |
| Message-ID | <da787fcf-86c9-4f06-a58d-3a68225c2f17@googlegroups.com> |
| In reply to | #110859 |
On Monday, May 29, 2017 at 3:37:29 AM UTC-7, Bart wrote: > On 29/05/2017 06:20, Tim Rentsch wrote: > > bartc <bc@freeuk.com> writes: > > > >> Note that the grammar in the C standard most likely is for machine > >> processing. I don't think it is intended to be a reference for humans. > > > > I'm offering a bet of 1,000 dollars (US) that the people who > > wrote it would say otherwise. > > Naturally. > > But the version of it from page 234 of K&R2 includes these preliminary > notes: "This grammar can be transformed mechanically into input > acceptable to an automatic parse generator." "...With one further > change... this grammar is acceptable to the YACC parser-generator". > > That grammar starts off: > > translation unit: > external-declaration > translation-unit external declaration > > And the version in Appendix A for C11 contains exactly the same. > > Even this very short extract shows the problem; what is this saying, > that a program (a 'translation unit') consists of a sequence of one or > more 'external declarations'? If so, then that's a roundabout way of > saying so. It's an artifact of the peculiar form of formal syntax they chose to use. I just translate it into what I consider a better form. I use explicit iteration. I could use '+' like a regexp user but, as I will explain in a moment, I prefer ... translation-unit = external declaration ... The reason for this is that there is another kind of iteration (which I call mediated) for separated lists: expression = assignment-expression COMMA .. Note - two periods this time, not three. Many of the apparent recursions in the standard formal grammar are eliminated this way - but not all.
[toc] | [prev] | [next] | [standalone]
Page 4 of 13 — ← Prev page 1 2 3 [4] 5 6 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web