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 12 of 13 — ← Prev page 1 … 10 11 [12] 13 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-05-25 02:39 +0100 |
| Message-ID | <87a861u32v.fsf@bsb.me.uk> |
| In reply to | #110599 |
joel.rees@gmail.com writes:
> On Wednesday, May 24, 2017 at 10:08:39 PM UTC+9, Ben Bacarisse wrote:
>> joel.rees@someplace writes:
>> <snip>
>> > https://sourceforge.net/p/bif-c/code/HEAD/tree/trunk/configs/makecelltype.c
>> <snip>
>> > I had the impression from my previous reading that (char *) was the base
>> > pointer type in C, and perhaps that is why I remembered malloc() as
>> > returning that type.
>>
>> In the days before C had void, malloc did return char *.
>
> Come to think of it, I probably left the cast out because I wanted to
> keep some degree of compatibility with compilers that had such
> libraries.
How does leaving out the cast help with that?
<snip>
>> > typedef unsigned char ubyte_t;
>> > typedef signed char sbyte_t;
>> >
>> > int probe_byte( FILE * outfile, typeBits_t * bits )
>> > { ubyte_t uch = (ubyte_t) -1;
>> > sbyte_t schmax = (sbyte_t) (uch >> 1);
>>
>> I prefer
>>
>> ubyte_t uch = -1;
>> sbyte_t schmax = uch >> 1;
>>
>> but to cover the full range of possibilities you need to use limits.h.
>> You say (in another post) that you want the support the widest range of
>> targets and yet you don't want to use limits.h that is designed to help
>> you do that.
>
> Well, to tell the truth, I'm trying, ultimately, to deal with compilers
> whose limits.h tell "white lies".
Such as?
>> > unsigned long memory = 0;
>> > int ui = 0;
>> > int status = 0;
>> >
>> > /* Must be identical to the two types declared above: */
>> > fputs( "typedef unsigned char ubyte_t;\n", outfile );
>> > fputs( "typedef signed char sbyte_t;\n", outfile );
>> > fputs( "/* For now, assuming two's complement: */\n", outfile );
>> > fprintf( outfile, "#define UBYTE_MAX ((ubyte_t) 0x%x)\n", uch );
>> > for ( uch = (ubyte_t) -1, ui = 0;
>> > ( ui <= 1024 ) && ( uch != 0 );
>> > )
>> > { memory = uch;
>> > uch <<= 1;
>> > ++ui;
>> > }
>>
>> Since you are not using the full for-loop, I'd write
>>
>> while (ui <= 1024 && uch != 0) {
>> memory = uch;
>> uch <<= 1;
>> ++ui;
>> }
>
> You know, I probably spent an hour or two playing with both approaches.
> I chose that one that seemed clearer to me at the time, and it still
> seems clearer to me now.
>
>> (don't worry about my choice of layout, but I would consider removing
>> the brackets as I have. Can you give 1024 and name? It would help
>> explain it.)
>
> Braces. Don't talk to me about my braces and I won't talk to you about
> yours. ;)
I didn't talk about your braces, but for some reason you want to talk
about mine!
> I know that all the fashionable tools expect the braces...
So why are you bringing this up?
>> > if ( ui != CHAR_BIT )
>> > { status = -1;
>> > fprintf( outfile, "#error \"*** C CHAR_BIT is %d but actual byte width is %d. ***\"\n", CHAR_BIT, ui );
>> > }
>> > bits->byteSize = ui;
>> > fprintf( outfile, "#define BITSPERBYTE %d\n", ui );
>> > fprintf( outfile, "#define BYTE_HIGH_BIT ((ubyte_t) 0x%x)\n",
>> > (ubyte_t) memory );
>>
>> These casts may be giving you a false sense of what's happening. They
>> certainly give me a false sense of what you expect.
>>
>> memory is in the range of ubyte_t so the cast of it has no effect on the
>> value. And it will get promoted to int with the cast and, technically,
>> %x needs an unsigned. Personally, I'd use the right format for its
>> type: %lx and drop the cast. I'd also drop the cast on the generated
>> define or explain with a comment why you need it.
>
> I think the cast on memory was probably a left-over habit from trying to
> get some compilers to refrain from sign-extending memory in the
> conversion to int. I don't remember which compilers did that, but there
> sure were some.
I think you are misremembering. How can an unsigned long whose value is
less that UCHAR_MAX sign extend when converted to int?
> Theoretically, that should just be a cast to unsigned, but some compilers
> I tried when I wrote this code were insisting that %x and unsigned did
> not match. MSB first architectures ended up printing the size as zero
> or something. Or maybe they printed the return address. I don't
> remember.
Why not use the right format, %lx, in the first place? Getting zero
used to be a a classic symptom of using %x rather than %lx.
>> > if ( ( schmax != ((ubyte_t) ~memory) )
>> > || ( ( ((ubyte_t) schmax) + 1 ) != memory ) ) /**** line 92 ***/
>> > { status = -1;
>> > fputs( "#error \"*** Not two's complement! Needs fixing. ***\"\n",
>> > outfile );
>>
>> I haven't checked all this but it seems to be designed to detect
>> non-two's complement implementations. A common way to detect the signed
>> integer representation is the look at the value of -3 % 3.
>
> There's a nice math puzzle. I'm wondering how different compiler choices
> about the way the modulo is calculated will complicate interpreting the
> result, however.
Sorry that was a typo. The intent was to mask with 3 -- the bottom two
bits of -3 tell you the representation being used.
>> > fprintf( outfile, "#error \"filled bit shifted right: %x, rollover: %x\"\n",
>> > schmax, ((ubyte_t) schmax) + 1 );
>> > fprintf( outfile, "#error \"1 max shifted left: %x, inverted: %x\"\n",
>> > ((ubyte_t) memory), ((ubyte_t) ~memory) );
>> > }
>> > fprintf( outfile, "#define SBYTE_MAX ((sbyte_t) 0x%x)\n",
>> > (ubyte_t) schmax );
>> > fputs( "#define SBYTE_MIN ((sbyte_t) BYTE_HIGH_BIT)\n\n\n", outfile );
>> > return status;
>> > }
>> > =============
>> >
>> > I need those bit patterns to be compared exactly, and I'm depending on
>> > C's type promotion to get this right.
>>
>> That's an odd way of putting it. It's up to you to get it right!
>
> Maybe I should say I'm hoping C's type promotion will refrain from
> misinterpreting what I wrote.
I think you'll find -3 & 3 easier to test and maintain. I don't think
there is any possibility of misinterpreting the intent.
>> > I'm not confident that I know the correct C++ cast to avoid unwanted
>> > sign extension or suppression.
>>
>> Pass. I think C++'s rules are the same, but I don't see the point in
>> worrying about getting your C code through a C++ compiler. (There are
>> reasons to do this, but I think you are just curious.)
>
> Well, actually, it helps me shine light on the various ways the code
> can be misinterpreted.
Not by C compilers, so what it the point? As it happens there is no
difference here, but what is there to gain from finding one in some
other area? For example, you found you had to add a cast. What does
that gain you other than writing worse C?
> I was talking about two or three architectures, but I'm trying to
> eventually produce code that I can compile without changes on modern
> and archaic compilers. I'm kind of hoping I can get it to even compile
> on dead 8-bit CPUs, but it may end up with object code that is too
> large to allow me to use it for bootstrapping a real Forth
> interpreter.
Using a C++ compiler won't help with that. The problems caused by
archaic compilers will be quite different. For a start, you'll have to
write K&R style functions. You'll have to stop using void. You will
have to stop using unsigned and long. How will you find out what
headers to include? (In old C there was malloc.h, alloc.h, string.h
strings.h and no doubt others I've managed to forget.)
>> > This code occurs several other times in this configuration file, for
>> > short, int, long, and long long. I'm getting this warning in each
>> > place.
>>
>> I'd have to look at the code because the promotion rules are type
>> dependent, but I can't see why you are not just doing
>>
>> (SCHAR_MAX >> 1) + 1
>>
>> to get the top value bit.
>
> Because I'm really not interested in what the C run-time wants to do.
Eh? Your code's behaviour is always determined by what the C run-time
wants to do. You can't avoid it. What do you gain from all the
bit-shifting that (SCHAR_MAX >> 1) + 1 does not give you?
>> > -------------
>> > makecelltype.c:294:54: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat]
>> > makecelltype.c:294:54: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long unsigned int’ [-Wformat]
>> > -------------
>> >
>> > =============
>> > fprintf( outfile, "#error \"*** sizeof ullongw_t == %d, sizeof ulongw_t == %d, not double! ***\"\n",
>> > sizeof (ullongw_t), sizeof (ulongw_t) );
>> > =============
>> >
>> > I suppose I should cast the result of sizeof to int, since I don't know
>> > what it will be compatible with on every target, and since I know it
>> > will fit in (int), even with 16-bit (int)s (and non-standard 8-bit ints):
>> >
>> > fprintf( outfile, "#error \"*** sizeof ullongw_t == %d, sizeof ulongw_t == %d, not double! ***\"\n",
>> > (int) sizeof (ullongw_t), (int) sizeof (ulongw_t) );
>> >
>> > (Or, really, change the format to %u and the cast to (unsigned) .)
>>
>> If you can rely on C99, you can use the format for size_t: %zu.
>
> Can't rely on that.
So what can you can rely on? Very old C did not even have fprintf, but
presumably you won't be going that far. Can you reply on unsigned?
What about long?
<snip>
>> > for ( i = 0; i < sizeof header / sizeof header[ 0 ] ; ++i )
>> > ==============
>> >
>> > Again, this must be the difference in type promotion between C and
>> > C++.
>>
>> I don't think so (in fact I'm pretty sure). Maybe you were not asking
>> for enough warnings from your C compiler?
>
> Well, I usually compile with "-Wall", but there are stricter warnings.
>
> But doesn't size_t divided by size_t get promoted to int?
>
> Now that I put it that way, I suppose not.
Indeed. It's of type size_t in both C and C++.
<snip>
> Thanks. I think I'm ready to move on to the interpreter itself.
Without knowing what archaic C you hope to support it's going to be hard
to give advice.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-24 18:48 -0700 |
| Message-ID | <lnbmqhwvty.fsf@kst-u.example.com> |
| In reply to | #110599 |
joel.rees@gmail.com writes:
> On Wednesday, May 24, 2017 at 10:08:39 PM UTC+9, Ben Bacarisse wrote:
>> joel.rees@someplace writes:
>> <snip>
>> > https://sourceforge.net/p/bif-c/code/HEAD/tree/trunk/configs/makecelltype.c
>> <snip>
>> > I had the impression from my previous reading that (char *) was the base
>> > pointer type in C, and perhaps that is why I remembered malloc() as
>> > returning that type.
>>
>> In the days before C had void, malloc did return char *.
>
> Come to think of it, I probably left the cast out because I wanted to
> keep some degree of compatibility with compilers that had such libraries.
>
> It's been a long time since I wrote that code, really.
That doesn't really make sense.
If malloc is defined with a return type of char*, then (a) the
implementation must be really old, pre-1989, and (b) if you're using a
compiler that enforces at least 1989-era rules, you'd *need* a cast.
int *p = malloc(sizeof *p);
(If you're not familiar with it, that's a common idiom for calling
malloc. Feel free to pretend I wrote `malloc(sizeof (int))` if you
prefer.)
If malloc returns void* (as it must any conforming C89 or later
implementation), then any conforming C89 or later compiler will do an
implicit conversion. A pre-C89 compiler might not know about the "void"
keyword. I suppose it's possible that a compiler might recognize
"void*" *and* not do the implicit conversion, but it seems unlikely.
If malloc returns char*, then you're dealing with a very old
implementation. A modern conforming compiler must at least warn about
assigning a char* value to an int* object. A very old pre-ANSI compiler
might be a bit promiscuous about implicit conversions and not complain.
Are you really trying to support pre-ANSI C implementations? If so,
just how far back do you want to go? The language changed quite a bit
between the mid-1970s and 1989.
[...]
> Well, to tell the truth, I'm trying, ultimately, to deal with compilers
> whose limits.h tell "white lies".
I'd be mildly astonished if any such compiler exists. Do you have an
example? What other "white lies" are you going to try to deal with?
Are you sure that 1 + 1 will yield 2?
[...]
> I know that all the fashionable tools expect the braces out on the
> right, but I find it much easier to use braces to show me whether my
> nesting is correct by putting the opening brace on the left where I
> can line them up by eyeballing them.
The two most common brace styles are K&R style:
if (condition) {
blah;
blah;
}
and:
if (condition)
{
blah;
blah;
}
A lot of people have a strong preference for one or the other.
(I certainly do, but I willingly use the other when coding standards
require it.)
Your style:
if (condition)
{ blah;
blah;
}
is a bit unusual. I personally find having code following the "{" on
the same line a bit jarring.
[...]
>> I'd have to look at the code because the promotion rules are type
>> dependent, but I can't see why you are not just doing
>>
>> (SCHAR_MAX >> 1) + 1
>>
>> to get the top value bit.
>
> Because I'm really not interested in what the C run-time wants to do.
I don't know what that means.
[...]
> But doesn't size_t divided by size_t get promoted to int?
>
> Now that I put it that way, I suppose not.
Almost certainly not. size_t is an unsigned type, and it's almost
always at least as wide as int, so a size_t dividied by a size_t yields
a size_t.
But in principle size_t could be narrower than int. For example,
imagine that size_t is 16 bits and int is 32 bits. Then divding a
size_t by a size_t would yield an int. (supercat posts about a similar
issue repeatedly.) Even on such an exotic system, it's unlikely to
cause a problem.
[...]
--
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 | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-25 15:13 +0200 |
| Message-ID | <20170525151322.22d038dbc0dc93a0a191ae49@gmail.com> |
| In reply to | #110607 |
On Wed, 24 May 2017 18:48:09 -0700
Keith Thompson <kst-u@mib.org> wrote:
> The two most common brace styles are K&R style:
>
> if (condition) {
> blah;
> blah;
> }
>
> and:
>
> if (condition)
> {
> blah;
> blah;
> }
Can you tell me where did you see the latter style in K&R?
> Your style:
>
> if (condition)
> { blah;
> blah;
> }
>
> is a bit unusual. I personally find having code following the "{" on
> the same line a bit jarring.
It is as jarring as the K&R style with non symmetric brackets.
Actually I prefer the Allman style but I would rather replace the K&R style with macros such as:
IF (condition) DO
ENDIF
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-25 14:34 +0100 |
| Message-ID | <v3BVA.109378$MA.90718@fx05.am4> |
| In reply to | #110632 |
On 25/05/2017 14:13, GOTHIER Nathan wrote:
>
> Actually I prefer the Allman style but I would rather replace the K&R style with macros such as:
>
> IF (condition) DO
> ENDIF
I tried to do this stuff with macros a few years ago, but it was too
limited. I needed to use an external preprocessor to turn input like this:
if (cond1) then
s1;
s2;
elsif (cond2) then
s3;
else
s4;
switch (x)
when c1, c2 then
s5;
s6;
when c3 then
s7;
elsesw
s8;
endsw
endif
into (preserving same line numbers and comments):
if (cond1) {
s1;
s2;
} else if (cond2) then {
s3;
} else {
s4;
switch (x) {
break; case c1: case c2:
s5;
s6;
break; case c3:
s7;
break; default:
s8;
}
}
It's rather ironic that C's otherwise crude preprocessor can do
if-then-else better than C can:
#if cond1
s1
s2
#elif cond2
s3
#else
s4
#endif
Look, no braces and no begin-end needed!
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-25 16:44 +0200 |
| Message-ID | <20170525164401.d9921fab2ac512e2ab19e2f2@gmail.com> |
| In reply to | #110634 |
On Thu, 25 May 2017 14:34:33 +0100
bartc <bc@freeuk.com> wrote:
> I tried to do this stuff with macros a few years ago, but it was too
> limited. I needed to use an external preprocessor to turn input like this:
>
> if (cond1) then
> s1;
> s2;
> elsif (cond2) then
> s3;
> else
> s4;
> switch (x)
> when c1, c2 then
> s5;
> s6;
> when c3 then
> s7;
> elsesw
> s8;
> endsw
> endif
I don't use else or elif because I find the logic broken. I prefer to
implicitly use else without any else syntax or to explicitly nest another if
expression which in my view is a clearer path to follow.
> into (preserving same line numbers and comments):
>
> if (cond1) {
> s1;
> s2;
> } else if (cond2) then {
> s3;
> } else {
> s4;
> switch (x) {
> break; case c1: case c2:
> s5;
> s6;
> break; case c3:
> s7;
> break; default:
> s8;
> }
> }
I would write instead:
if (cond1)
{
s1;
s2;
if (cond2)
{
s3;
}
}
s4;
if ((x == c1) || (x == c2))
{
s5;
s6;
}
if (x == c3)
{
s7;
}
s8;
> It's rather ironic that C's otherwise crude preprocessor can do
> if-then-else better than C can:
>
> #if cond1
> s1
> s2
> #elif cond2
> s3
> #else
> s4
> #endif
>
> Look, no braces and no begin-end needed!
I think you missed the purpose of the preprocessor. It can't evaluate any
expression at run-time. However I acknowledge the if syntax from the C
preprocessor is clearer since the style alternatives are more limited with a
start & stop structure.
Here is another alternative:
if (condition)
eval
{
}
The goal is to distinguish the if pattern from the function pattern with a
"dead" keyword (i.e. eval).
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2017-05-25 15:02 +0000 |
| Message-ID | <slrn3vfsoidsmn.ese.ike@iceland.freeshell.org> |
| In reply to | #110636 |
On 2017-05-25, GOTHIER Nathan <nathan.gothier@gmail.com> wrote:
> On Thu, 25 May 2017 14:34:33 +0100
> bartc <bc@freeuk.com> wrote:
>> I tried to do this stuff with macros a few years ago, but it was too
>> limited. I needed to use an external preprocessor to turn input like this:
>> [...]
>
> I don't use else or elif because I find the logic broken. I prefer to
> implicitly use else without any else syntax or to explicitly nest another if
> expression which in my view is a clearer path to follow.
>
>> into (preserving same line numbers and comments):
>>
>> if (cond1) {
>> s1;
>> s2;
>> } else if (cond2) then {
>> s3;
>> } else {
>> s4;
>> switch (x) {
>> break; case c1: case c2:
>> s5;
>> s6;
>> break; case c3:
>> s7;
>> break; default:
>> s8;
>> }
>> }
>
> I would write instead:
>
> if (cond1)
> {
> s1;
> s2;
>
> if (cond2)
> {
> s3;
> }
The rewrite has different semantics.
Bartc's code executes s3 when (!cond1 && cond2).
Your code executes s3 when (cond1 && cond2).
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-25 17:19 +0200 |
| Message-ID | <20170525171952.ed0a4c209deaf72c373fb075@gmail.com> |
| In reply to | #110637 |
On Thu, 25 May 2017 15:02:47 -0000 (UTC)
Ike Naar <ike@iceland.freeshell.org> wrote:
> On 2017-05-25, GOTHIER Nathan <nathan.gothier@gmail.com> wrote:
> > On Thu, 25 May 2017 14:34:33 +0100
> > bartc <bc@freeuk.com> wrote:
> >> I tried to do this stuff with macros a few years ago, but it was too
> >> limited. I needed to use an external preprocessor to turn input like this:
> >> [...]
> >
> > I don't use else or elif because I find the logic broken. I prefer to
> > implicitly use else without any else syntax or to explicitly nest another if
> > expression which in my view is a clearer path to follow.
> >
> >> into (preserving same line numbers and comments):
> >>
> >> if (cond1) {
> >> s1;
> >> s2;
> >> } else if (cond2) then {
> >> s3;
> >> } else {
> >> s4;
> >> switch (x) {
> >> break; case c1: case c2:
> >> s5;
> >> s6;
> >> break; case c3:
> >> s7;
> >> break; default:
> >> s8;
> >> }
> >> }
> >
> > I would write instead:
> >
> > if (cond1)
> > {
> > s1;
> > s2;
> >
> > if (cond2)
> > {
> > s3;
> > }
>
> The rewrite has different semantics.
> Bartc's code executes s3 when (!cond1 && cond2).
> Your code executes s3 when (cond1 && cond2).
Indeed I mixed else and if as elif. In my view the style isn't clear. :o)
I should have written something like:
if (cond1)
{
s1;
s2;
}
if (!cond1 && cond2)
{
s3;
}
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-25 17:18 +0100 |
| Message-ID | <YsDVA.166258$3w1.10177@fx41.am4> |
| In reply to | #110639 |
On 25/05/2017 16:19, GOTHIER Nathan wrote:
> On Thu, 25 May 2017 15:02:47 -0000 (UTC)
> Ike Naar <ike@iceland.freeshell.org> wrote:
>> The rewrite has different semantics.
>> Bartc's code executes s3 when (!cond1 && cond2).
>> Your code executes s3 when (cond1 && cond2).
>
> Indeed I mixed else and if as elif. In my view the style isn't clear. :o)
>
> I should have written something like:
>
> if (cond1)
> {
> s1;
> s2;
> }
>
> if (!cond1 && cond2)
> {
> s3;
> }
That still isn't quite the same. You're evaluating cond1 twice. cond1
may be a simple variable, or it could be an expression yielding true or
false but with possible other side-effects.
One of those could be, making cond2 false on the second evaluation.
Another could be something that changes the behaviour anyway compared
with evaluating cond1 only once.
What have you got against 'else'? It's only existed since 1958 or so.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-25 18:58 +0200 |
| Message-ID | <20170525185821.5ad516a3059f874602398065@gmail.com> |
| In reply to | #110642 |
On Thu, 25 May 2017 17:18:14 +0100
bartc <bc@freeuk.com> wrote:
> That still isn't quite the same. You're evaluating cond1 twice. cond1
> may be a simple variable, or it could be an expression yielding true or
> false but with possible other side-effects.
Whatever is cond1, it should be evaluated as a boolean expression by the if
structure. If you insist in evaluating cond1 once one could write this:
if (!cond1)
{
if (cond2)
{
s3;
}
}
s1;
s2;
But I have the sentiment you'll find another excuse to pretend your solution
is crystal clear though at least not for me.
> What have you got against 'else'? It's only existed since 1958 or so.
I don't like nested if-else like you did since the else-if sequence makes
confusion with elif and I prefer to rely on a clear minimal syntax. I think the
else statement isn't necessary and makes as much spaghetti code as crossed goto.
I always found a way to refactor my code in order to only use the if statement.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-25 18:24 +0100 |
| Message-ID | <RqEVA.102813$e57.55563@fx46.am4> |
| In reply to | #110643 |
On 25/05/2017 17:58, GOTHIER Nathan wrote:
> On Thu, 25 May 2017 17:18:14 +0100
> bartc <bc@freeuk.com> wrote:
>
>> That still isn't quite the same. You're evaluating cond1 twice. cond1
>> may be a simple variable, or it could be an expression yielding true or
>> false but with possible other side-effects.
>
> Whatever is cond1, it should be evaluated as a boolean expression by the if
> structure. If you insist in evaluating cond1 once one could write this:
>
> if (!cond1)
> {
> if (cond2)
> {
> s3;
> }
> }
>
> s1;
> s2;
>
> But I have the sentiment you'll find another excuse to pretend your solution
> is crystal clear though at least not for me.
You're right, because the above still doesn't do the same thing. The
above will conditionally execute s3 then /always/ execute s1;s2. Instead
of conditionally either s1;s2 or s3 or neither (according to my original
example).
>
>
>> What have you got against 'else'? It's only existed since 1958 or so.
>
> I don't like nested if-else like you did since the else-if sequence makes
> confusion with elif and I prefer to rely on a clear minimal syntax. I think the
> else statement isn't necessary and makes as much spaghetti code as crossed goto.
That's surprising to hear. if-else was considered to be an advance over
what was available in Fortran or in assembler. It's was called
'structured programming'.
It also matches what we say in English: if today is Tuesday we do X, if
it's Wednesday we do Y, otherwise we do Z.
We don't say, if it's Tuesday do X; if it's not Tuesday and it's
Wednesday then do Y and so on. We would combine those.
(There's also the consideration that if we do the first test at 23:59:59
on a Monday, so it's not Tuesday, then by the time of the next test, it
might BE Tuesday!)
> I always found a way to refactor my code in order to only use the if statement.
I've done that in a code generator that targetted 'C' source code. If
used no structured statements except single-level if and goto,
unconditional goto, and expressions.
It wasn't pretty:
if (!cond1) goto L1;
s1;
s2;
goto L4;
L1:
if (!cond2) goto L3
s3;
goto L4;
L3:
...
L4:
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-25 20:36 +0200 |
| Message-ID | <20170525203618.14672290920021b01971ab5e@gmail.com> |
| In reply to | #110644 |
On Thu, 25 May 2017 18:24:16 +0100
bartc <bc@freeuk.com> wrote:
> You're right, because the above still doesn't do the same thing. The
> above will conditionally execute s3 then /always/ execute s1;s2. Instead
> of conditionally either s1;s2 or s3 or neither (according to my original
> example).
Indeed. This should work better with:
if (!cond1)
{
if (cond2)
{
s3;
}
goto next;
}
s1;
s2;
next:
Usually my functions return a value at the end of a block.
> That's surprising to hear. if-else was considered to be an advance over
> what was available in Fortran or in assembler. It's was called
> 'structured programming'.
I like the assembler style code close to the architecture, it's basic and clear.
> It also matches what we say in English: if today is Tuesday we do X, if
> it's Wednesday we do Y, otherwise we do Z.
I'm a robot, what's not true is false. :o)
> We don't say, if it's Tuesday do X; if it's not Tuesday and it's
> Wednesday then do Y and so on. We would combine those.
I'm definately not english. ;-)
> It wasn't pretty:
>
> if (!cond1) goto L1;
> s1;
> s2;
> goto L4;
> L1:
> if (!cond2) goto L3
> s3;
> goto L4;
> L3:
> ...
> L4:
Are you english or italian? :-P
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-25 16:06 +0100 |
| Message-ID | <ZpCVA.137203$_f2.115145@fx35.am4> |
| In reply to | #110636 |
On 25/05/2017 15:44, GOTHIER Nathan wrote:
> On Thu, 25 May 2017 14:34:33 +0100
> bartc <bc@freeuk.com> wrote:
> I don't use else or elif because I find the logic broken. I prefer to
> implicitly use else without any else syntax or to explicitly nest another if
> expression which in my view is a clearer path to follow.
>
>> into (preserving same line numbers and comments):
>>
>> if (cond1) {
>> s1;
>> s2;
>> } else if (cond2) then {
>> s3;
>> } else {
>> s4;
>> switch (x) {
>> break; case c1: case c2:
>> s5;
>> s6;
>> break; case c3:
>> s7;
>> break; default:
>> s8;
>> }
>> }
>
> I would write instead:
>
> if (cond1)
> {
> s1;
> s2;
>
> if (cond2)
> {
> s3;
> }
> }
That logic is different. s3 should only be executed when cond1 is false
and cond2 is true. Here, it's when both cond1 and cond2 are true.
Furthermore, evaluation of s1 and s2 could change the value of cond2
before it gets to test it.
You can get away without 'else', but may need to use gotos. But then it
gets more more complicated to follow.
> s4;
>
> if ((x == c1) || (x == c2))
> {
> s5;
> s6;
> }
>
> if (x == c3)
> {
> s7;
> }
>
> s8;
Same thing here. After s5 and s6, you're done with testing x. Even if x
hasn't been modified to now be c3, you don't want to test another 150
values.
>> It's rather ironic that C's otherwise crude preprocessor can do
>> if-then-else better than C can:
>>
>> #if cond1
>> s1
>> s2
>> #elif cond2
>> s3
>> #else
>> s4
>> #endif
>>
>> Look, no braces and no begin-end needed!
>
> I think you missed the purpose of the preprocessor. It can't evaluate any
> expression at run-time. However I acknowledge the if syntax from the C
> preprocessor is clearer since the style alternatives are more limited with a
> start & stop structure.
Yes, the syntax is what I mean. It's very clear, but some people seem to
thing such clear statements are only for 'toy' scripting languages or
for preprocessors.
>
> Here is another alternative:
>
> if (condition)
> eval
> {
> }
>
> The goal is to distinguish the if pattern from the function pattern with a
> "dead" keyword (i.e. eval).
Or 'then'? With if-else, you have four things:
1 the condition to be tested
2 what to do if true
3 what to do if false (these two exclusive; only one must be evaluated)
4 That you are doing an 'if'
Everything else is the syntax and punctuation the language stipulates.
Here's one version:
(if a b c)
C uses if (a) b else c, but suffers from the fact that sometimes you
need braces (around sequences b and/or c), sometimes you don't, or if
you do they are written a dozen different ways; also that the 'else' is
optional so you can get a dangling else problem.
The sort of issues you might get in a language designed as a school
project. Not in a professional language that many of the world's IT
systems depend on. It's a bit scary really.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-26 16:37 -0700 |
| Message-ID | <kfn7f13gpg4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110599 |
joel.rees@gmail.com writes:
> Well, to tell the truth, I'm trying, ultimately, to deal with
> compilers whose limits.h tell "white lies".
What "white lies" are you talking about? What problem are you
trying to solve that you think some <limits.h> produces wrong
answers for?
>>> if ( ( schmax != ((ubyte_t) ~memory) )
>>> || ( ( ((ubyte_t) schmax) + 1 ) != memory ) ) /**** line 92 ***/
>>> { status = -1;
>>> fputs( "#error \"*** Not two's complement! Needs fixing. ***\"\n",
>>> outfile );
>>
>> I haven't checked all this but it seems to be designed to detect
>> non-two's complement implementations. A common way to detect the signed
>> integer representation is the look at the value of -3 % 3.
>
> There's a nice math puzzle. I'm wondering how different compiler choices
> about the way the modulo is calculated will complicate interpreting the
> result, however.
I'm pretty sure Ben meant 'and' (&), not 'modulo' (%). In any case
the expression -1 & 3 should let you test easily for two's
complement, and there is only one choice for how to calculate it
(ie, for each possible choice of how integers are represented).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-26 16:54 -0700 |
| Message-ID | <kfn37brgon5.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110538 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> joel.rees@gmail.com writes:
[...]
>
>> if ( ui != CHAR_BIT )
>> { status = -1;
>> fprintf( outfile, "#error \"*** C CHAR_BIT is %d but actual
>> byte width is %d. ***\"\n", CHAR_BIT, ui );
>> }
>> bits->byteSize = ui;
>> fprintf( outfile, "#define BITSPERBYTE %d\n", ui );
>> fprintf( outfile, "#define BYTE_HIGH_BIT ((ubyte_t) 0x%x)\n",
>> (ubyte_t) memory );
>
> These casts may be giving you a false sense of what's happening. They
> certainly give me a false sense of what you expect.
>
> memory is in the range of ubyte_t so the cast of it has no effect on the
> value. And it will get promoted to int with the cast and, technically,
> %x needs an unsigned.
I just want to note for the record that the Standard is not
completely clear on that, and there is a case to be made that an
int value will work fine with %x as long as the int value is
non-negative.
> Personally, I'd use the right format for its
> type: %lx and drop the cast. [...]
A cast potentially changes both the type and the value. As far
as types go I agree with this suggestion, but the question about
the value is more subtle. Perhaps this:
fprintf( outfile, "#define BYTE_HIGH_BIT ((ubyte_t) 0x%lx)\n",
memory & (ubyte_t)-1 );
Now the type is right and the value agrees with the earlier (ie,
casted) value.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-24 08:46 -0700 |
| Message-ID | <lninkqxnp5.fsf@kst-u.example.com> |
| In reply to | #110518 |
joel.rees@gmail.com writes:
[...]
> I need those bit patterns to be compared exactly, and I'm depending on
> C's type promotion to get this right.
>
> I'm not confident that I know the correct C++ cast to avoid unwanted
> sign extension or suppression.
You seem to be assuming that C and C++ have different type promotion
rules. As far as I know they're the same. You might get different
optional warnings from a C compiler and a C++ compiler, just as you
might get different optional warnings from two different C compilers.
[...]
> makecelltype.c:294:54: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat]
> makecelltype.c:294:54: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long unsigned int’ [-Wformat]
> -------------
>
> =============
> fprintf( outfile, "#error \"*** sizeof ullongw_t == %d, sizeof ulongw_t == %d, not double! ***\"\n",
> sizeof (ullongw_t), sizeof (ulongw_t) );
> =============
>
> I suppose I should cast the result of sizeof to int, since I don't know
> what it will be compatible with on every target, and since I know it
> will fit in (int), even with 16-bit (int)s (and non-standard 8-bit ints):
The correct printf format for size_t is "%zu". This was added in C99,
so you *might* run into a C implementation that doesn't support it. If
that's the case, you can cast to unsigned long and use "%lu".
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-05-24 13:33 -0400 |
| Message-ID | <6daef28c-2cb4-8bb3-1e89-0b018ee8fe24@verizon.net> |
| In reply to | #110552 |
On 05/24/2017 11:46 AM, Keith Thompson wrote: > joel.rees@gmail.com writes: > [...] >> I need those bit patterns to be compared exactly, and I'm depending on >> C's type promotion to get this right. >> >> I'm not confident that I know the correct C++ cast to avoid unwanted >> sign extension or suppression. > > You seem to be assuming that C and C++ have different type promotion > rules. As far as I know they're the same. ... I thought so too, but just to be sure, I checked. C++2011 has special rules for bool, char16_t, char32_t and wchar_t and values of enumerated types (4.5p2,3) that at least appear to be different from the rules in C. Those rules (and two of those types) didn't exist the last time I read the relevant section of the C++ standard. I haven't had time to analyze the differences to figure out what they really mean - but his code doesn't use any of those types.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-05-24 13:12 -0400 |
| Message-ID | <22e396c8-8190-09c3-dd27-2dbb7257fe1c@verizon.net> |
| In reply to | #110518 |
On 05/23/2017 09:46 PM, joel.rees@gmail.com wrote:
...
> The warnings:
>
> -------------
> makecelltype.c:28:1: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
> makecelltype.c:35:1: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
> -------------
>
> =============
> typedef char * prCharPtr_p;
> typedef void * prVoidPtr_p;
> typedef void (* icode_f)(void);
> /* The above type declarations as strings, MUST BE IDENTICAL: */
> char * prPtrTpDecs[] =
> {
> "char * prCharPtr_p",
> "void * prVoidPtr_p",
> "void (* icode_f )( void )"
> }; /* line 28 */
> /* The above type names as strings, MUST BE IDENTICAL: */
> char * prPtrTypes[] =
> {
> "prCharPtr_p",
> "prVoidPtr_p",
> "icode_f"
> }; /* line 35 */
> =============
In C, a string literal causes the creation of an unnamed array of char,
sufficiently long to contain all of the characters in the string plus a
terminating null character. The string literal itself is an lvalue of
type char[n] referring to that array, where n is the length of that
array. In most contexts, lvalues of array type get implicitly converted
into a pointer to the first element of the array; in this case, that
pointer has the type "char*".
A very important thing to know is that any attempt to modify the values
stored in that array has undefined behavior. For example:
prPrtTypes[1][0] = 'P';
would have undefined behavior, and most compilers would give you no
warning about it - particularly if that line occurred in a different
translation unit.
C++ invented the 'const' keyword. It should be used for any pointer that
might point at an object that can't (or at least, shouldn't) be
modified, include the contents of any string literal. If you had written
that as:
const char * prPtrTypes[] =
{
"prCharPtr_p",
"prVoidPtr_p",
"icode_f"
};
then the code
prPrtTypes[1][0] = 'P';
would have been a constraint violation, requiring a diagnostic message
that would have warned you of the problem.
The C committee thought that "const" was a good idea, and added it to C.
Therefore, using const to protect such code is a good idea in both
languages.
However, C++ went one step further. In C++, a string literal causes the
creation of an array of const char, not just char. The pointer that it
converts to therefore has the type "const char*". Note that this would
break all C code written before the adoption of "const" (and an awful
lot of C code, such as yours, that was (poorly) written after that
adoption). Therefore, to blunt the impact of that change, C++ allows the
pointer resulting from a string literal to be implicitly converted to
char*, but this conversion is deprecated. This means that a future
version of C++ may cease permitting such conversions. The designer of
C++ considered the safety provided by making string literals "const" to
be more important than the loss of backwards compatibility with C.
The C committee, on the other hand, while agreeing that this was a good
idea, considered backwards compatibility of C with itself to be more
important than it was for C++, and therefore did not adopt it.
Therefore, storing a string literal's pointer in a "const char*" is a
good idea in both languages, but it's only mandatory in C++. If you want
to write in the common subset, you need to change prPtrTypes to "const
char *" - but you should also do so even if you only ever intend to
compile this as C code.
...
> -------------
> makecelltype.c:92:44: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
> -------------
>
> I was thinking to just show the declarations and lines 91 and 92, but
> this is one of those places where context is everything:
>
> =============
> typedef unsigned char ubyte_t;
> typedef signed char sbyte_t;
>
> int probe_byte( FILE * outfile, typeBits_t * bits )
> { ubyte_t uch = (ubyte_t) -1;
> sbyte_t schmax = (sbyte_t) (uch >> 1);
UCHAR_MAX and SCHAR_MAX from <limits.h> are more direct ways to get the
values you're looking for.
> unsigned long memory = 0;
> int ui = 0;
> int status = 0;
>
> /* Must be identical to the two types declared above: */
> fputs( "typedef unsigned char ubyte_t;\n", outfile );
> fputs( "typedef signed char sbyte_t;\n", outfile );
> fputs( "/* For now, assuming two's complement: */\n", outfile );
> fprintf( outfile, "#define UBYTE_MAX ((ubyte_t) 0x%x)\n", uch );
> for ( uch = (ubyte_t) -1, ui = 0;
> ( ui <= 1024 ) && ( uch != 0 );
> )
> { memory = uch;
> uch <<= 1;
> ++ui;
> }
> if ( ui != CHAR_BIT )
> { status = -1;
> fprintf( outfile, "#error \"*** C CHAR_BIT is %d but actual byte width is %d. ***\"\n", CHAR_BIT, ui );
> }
There's not really much point in writing code like that. If you can't
count on CHAR_BIT being set to the right value, you're working with an
implementation of C so unreliable that you can't count on <<, ++, or
printf() working as they should, either.
...
> I need those bit patterns to be compared exactly, and I'm depending on
> C's type promotion to get this right.
>
> I'm not confident that I know the correct C++ cast to avoid unwanted
> sign extension or suppression.
C's rules for the integer promotions, the usual arithmetic conversions,
and conversion from one integer type to another are essentially
identical to those of C++, except that C++ has a few additional rules to
cover cases that never come up in pure C code (and are therefore not
relevant to code written in the common subset of C and C++).
...
> -------------
> makecelltype.c:294:54: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat]
> makecelltype.c:294:54: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘long unsigned int’ [-Wformat]
> -------------
>
> =============
> fprintf( outfile, "#error \"*** sizeof ullongw_t == %d, sizeof ulongw_t == %d, not double! ***\"\n",
> sizeof (ullongw_t), sizeof (ulongw_t) );
> =============
Your code uses "long long" and flexible array members, among other
features that were introduced in C99. If you're using a implementation
that is fully conforming to C99, you're entitled to assume that printf()
recognizes the "%zu" specifier, which was also introduced in that version.
However, as a practical matter of fact, for some reason I don't
understand (probably because all the machines I use run Linux), one of
the most popular "implementations" of C on Windows platforms is a gcc
compiler that implements C99, combined with the Windows version of the C
standard library, which does not. If your code needs to be compilable
when using such an malformed implementation, then it might be reasonable
to avoid "%zu", even in code that makes use of other C99 features.
However, in that case I would recommend using "%lu" and casting the
result of sizeof to (unsigned long), unless you're absolutely certain
that the numbers you are printing are all less than 65536. If you are
certain that they are that small, you should use "%u" and cast the
result of sizeof to (unsigned). You shouldn't use "int", because size_t
is required to be an unsigned type.
...
> --------------
> makecelltype.c:380:54: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
> --------------
>
> ==============
> char const * header[] = /* edited to char const * as mentioned above. */
> {
> "/*",
> "** %s",
> "** bif-c",
> "**",
> "** Template created by Joel Rees on 2013/06/18.",
> "** Copyright 2013 __Reiisi_Kenkyuu__. All rights reserved.",
> "**",
> "** Type information for cell proto-type.",
> "*/\n\n"
> };
> [...]
> for ( i = 0; i < sizeof header / sizeof header[ 0 ] ; ++i )
> ==============
>
> Again, this must be the difference in type promotion between C and C++.
It isn't. Those are just warnings. It's just about gcc being more picky
about such things when compiling C++ than when compiling C. The key
point is that 'i' has the type 'int' and the sizeof expressions have a
value of type size_t, which is unsigned. Comparison of unsigned and
signed values poses essentially the same dangers in both languages.
You don't need to pay attention to warning message, but if you want to,
you can avoid them by declaring i to have an unsigned type, preferably
size_t.
> Parenthesis:
>
> for ( i = 0; i < ( sizeof header / sizeof header[ 0 ] ) ; ++i )
>
> doesn't fix it.
That's because division has higher precedence than comparison for
relative order. The two languages have almost identical operator
precedence (?: is the key exception) for all operators that exist in
both languages.
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-24 17:52 -0700 |
| Message-ID | <7abafd90-dd48-47d8-a9ad-23624cf3c362@googlegroups.com> |
| In reply to | #110565 |
On Thursday, May 25, 2017 at 2:12:21 AM UTC+9, James R. Kuyper wrote: > On 05/23/2017 09:46 PM, joel.rees@dokoka wrote: > ... > > [...] > Your code uses "long long" and flexible array members, among other > features that were introduced in C99. If you're using a implementation > that is fully conforming to C99, you're entitled to assume that printf() > recognizes the "%zu" specifier, which was also introduced in that version. > [...] You might note, around line 237, that I have the use of long long buried in conditional compile: https://sourceforge.net/p/bif-c/code/HEAD/tree/trunk/configs/makecelltype.c#l235 -- Joel Rees Trying to re-invent the industry all by myself: http://defining-computers.blogspot.jp/
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-25 02:00 +0100 |
| Message-ID | <U0qVA.137037$lN5.51452@fx40.am4> |
| In reply to | #110565 |
On 24/05/2017 18:12, James R. Kuyper wrote:
> Your code uses "long long" and flexible array members, among other
> features that were introduced in C99. If you're using a implementation
> that is fully conforming to C99, you're entitled to assume that printf()
> recognizes the "%zu" specifier, which was also introduced in that version.
Not necessarily. If I try this:
#include <stdio.h>
int main(void) {
printf("%zu\n",sizeof(void*));
}
I get:
c:\c>\tdm\bin\gcc -std=c99 c.c -oc.exe
c:\c>c
zu
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-24 18:53 -0700 |
| Message-ID | <ln37btwvkb.fsf@kst-u.example.com> |
| In reply to | #110604 |
bartc <bc@freeuk.com> writes:
> On 24/05/2017 18:12, James R. Kuyper wrote:
>> Your code uses "long long" and flexible array members, among other
>> features that were introduced in C99. If you're using a implementation
>> that is fully conforming to C99, you're entitled to assume that printf()
>> recognizes the "%zu" specifier, which was also introduced in that version.
>
> Not necessarily.
Yes, necessarily.
> If I try this:
>
> #include <stdio.h>
>
> int main(void) {
> printf("%zu\n",sizeof(void*));
> }
>
> I get:
>
> c:\c>\tdm\bin\gcc -std=c99 c.c -oc.exe
>
> c:\c>c
> zu
Then you're using an implementation (in particular, the implementation's
printf function) that is BY DEFINITION not fully conforming to C99.
--
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]
Page 12 of 13 — ← Prev page 1 … 10 11 [12] 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web