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 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-05-29 03:58 -0400 |
| Message-ID | <oggk55$23h$1@dont-email.me> |
| In reply to | #110819 |
On 05/28/2017 09:53 AM, joel.rees@gmail.com wrote: > On Sunday, May 28, 2017 at 5:22:30 AM UTC+9, James Kuyper wrote: >> On 05/27/2017 02:46 AM, joel.rees@outinleftfield wrote: >>> On Friday, May 26, 2017 at 10:05:31 PM UTC+9, David Brown wrote: ... >>>> This has not changed. The only >>>> thing that changed was the effect produced by this undefined behaviour. >>>> gcc now produces slightly more efficient code in the case where the >>>> code is correct, but perhaps more unexpected code in the case where the >>>> code is wrong. It does not make correct code, or even code that is >>>> implementation-dependent, into incorrect code - it makes incorrect code >>>> into incorrect code with unexpected effects. >>> >>> There are two issues with what you are saying. >>> >>> First, there is no such thing as correct code, only code which passes >>> the compiler in use, which can be further subdivided by how closely >>> it follows the Standard. >> >> Perhaps - I suppose that depends upon what you mean by "correct code" - Certainty about the truth of any statement about the real world is a delusional state. It's not possible to collect enough information to have justified certainty about any such statement. The best you can do is collect enough information to justify having a sufficiently high level of confidence to justify behaving as if it were true, while being open to conflicting evidence that might change your mind about that. Therefore, I tend to be very dismissive about any argument that places too much emphasis on the fact that "you can't be certain of that". You can't be certain of anything, but that shouldn't prevent you from being able to take action. And you seem to be placing far too much emphasis on the fact that we can't be certain whether code is correct - so much, in fact, that you're incorrectly claiming that our lack of certainty means correct code can't exist. > I'm referring to the old platitude that there every program has bugs I think that it's very difficult to write a program of any significant size with no errors. It's even more difficult to collect sufficient information to have a reasonable level of confidence about your belief that a given program is bug-free. However, even if you never ever collect sufficient to justify believing it, I think that there's a small but finite chance that any given program might in fact be error free. To say that every program has bugs is a (slight) exaggeration. But even if that old platitude were perfectly true, it's the concept of a "correct program" that would still allow us to identify as a bug any feature of a real program that makes it's behavior different from that of a correct program. > ... and hinting broadly at the concept that standards are subject to the > same limitation. Standards are certainly capable of being defective, and most (possibly, but not necessarily, all) real world ones are. If you'd read any significant fraction of my messages on this newsgroup, you'd realize that I'm well aware of a number of defects in the C standard. However, if, for any particular standard, those defects are sufficiently few that none of them happen to be relevant to a particular program, then it's still possible to use that standard to define the concept of "correct program" that I described. It's not possible to have justified certainty that a given standard has no defects that are relevant to a given program, but that's just an inherent feature of reality that we have to deal with. It is possible (but difficult) to collect enough information to have a sufficiently high level of confidence in the matter to justify using the concept. >> what I mean by the term would certainly not be compiler-dependent. I realized after I wrote that, that I hadn't worded it quite correctly. What I should have said is that the correctness of a program can be compiler dependent only because, and only insofar as, the program's requirements are compiler-dependent. If a program's requirements specify that it must be compilable using a specific compiler, then whether or not that program is correct will, quite properly, depend upon whether it is correctly written to work around the defects of that compiler. Which can be very difficult to achieve, if a relevant defect is not actually known about - but again, that's just real life refusing to cooperate with us, not something that renders the concept of a "correct program" meaningless. > Surely you do not mean to say that correct code is code that has not > been compiled? No, I didn't say anything to suggest that compiling a program renders it incorrect. I did mean something that you might consider equally outrageous. If a program is correct, it remains correct even if it has never been compiled by any compiler that conforms fully to relevant standards, even is there is not now, never has been, and never will be any such compiler. All that matters is whether the relevant standard says that a compiler that did conform to that standard must give that source code behavior that matches the program's requirements. Note: I say "standard" because the requirements that govern most of my coding refer to official standards; depending upon the requirements that your code is written to, the relevant document might be the reference manual for a particular compiler, rather than a standard. There might not even be an appropriate document, just a requirement that your code work correctly when compiled by a compiler with no documentation (in which case you're facing some serious problems - I would tend to refuse such an assignment, but people with a more experimental bent seem to be willing to try working with systems they have no documentation for). Similarly, if a program is incorrect, it remains incorrect, even if every single compiler it's ever been tested on (and indeed, every compiler it ever could be tested on) happens to have a defect that renders it non-conforming in such a way that it balances a defect in the code, accidentally producing precisely the same behavior it was supposed to have. It's just that incorrect code + incorrect compiler has a small but finite chance of producing correct behavior. That doesn't make either the code or the compiler correct. >> For >> me, code is correct if what the relevant standards (which, for me, >> usually include the POSIX standard as well as the C standard) guarantee >> about the behavior of that code, when translated, correctly matches the >> program's requirements. > > Requirements? > > While I'm wearing my optimist's hat, I'll remember that systems and > module specifications have the same limitation about being bug-free > as programs and standards. Perfectly correct: any given requirements specification might fail to correctly specify the actual requirements, and it's possible that the actual requirements are not internally consistent, or are unachievable for some other reason. However, if the actual requirements happen to be achievable, any given program might happen to meet them, even if the requirements specification fails to correctly specify what they are. And if it does, it is a "correct program", even if no one ever collects sufficient information to have a reasonable level of confidence about that fact. >> If the code contains syntax errors, constraint >> violations, or other causes of undefined behavior, the C standard >> guarantees nothing, which makes it pretty difficult for the defined >> behavior to meet requirements. Note: I'm assuming above that conformance with the C standard is one of the requirements of the program, and that none of the other relevant standards defines the behavior of the code that is undefined as far as C itself is concerned. Obviously, a somewhat different statement would apply if the requirements specified the use of some other language. > And the compiler, being a program, has bugs, and will miss some > syntax errors, some constraint violations, etc., and generally knows > next to nothing about the specification, much less the requirements. A compiler's bugs are very relevant to the correctness of the compiler, and completely irrelevant to the correctness of a program, unless the program's requirements include being able to cope with that particular compiler's bugs. The fact that a compiler knows nothing about a program's requirements specifications is irrelevant to the correctness of the the program itself. It's sufficient that the developer knows what those requirements are. If the code is correct, it will instruct the compiler to generate an executable that meets those requirements, without the compiler needing to know anything other than what the source code tell it about those requirements. In principle, even that's not strictly necessary - by pure random chance a programmer might happen to write a program that correctly produces the required behavior, despite the developer not knowing what that behavior is. That's not a chance worth worrying about - but if it did happen, that would be a correct program. > While I'm wearing my optimist's hat. > >> The code in question has undefined behavior, and has always had >> undefined behavior. > > Actually, I could seriously quibble with you on both philosophical > and practical grounds on this point, but I don't really want to > argue the point. I'm totally agreed. That was one of the things > I never misunderstood about C, for all that I have misunderstood > a few other things. > > But there are literally a hundred thousand programmers out there > writing code who have not yet seen the light, if you must ignore the > issues of experience opportunities. The fact that there's a lot of programmers out there who don't know C perfectly is an unavoidable consequence of C being sufficiently powerful to be useful, and programmers not being perfect. It doesn't prevent the occasional programmer from producing a correct program, and even if it did, it wouldn't render the concept of a "correct program" meaningless. >> That's sufficient to justify failing to meet any >> expectations anyone may have erroneously formed about what the behavior >> of that code should have been. > > If you say so, but it is going to cause problems, That's life. Problems come with the territory. > ... unless you have the money and other resources to stop those > hundred thousand programmers in their tracks and train them in all > the ins and outs of the standards before they are allowed to write > another line of code. How could they possibly complete such training without writing another line of code? And why should I, personally, pay to improve their capabilities? Obtaining sufficient training is their own responsibility, and becoming better educated will reward them, not me. Their employers might have sufficient interest in the outcome to subsidize that education, but there's no reason for me to do so. ... > What was compiling yesterday at level three should not suddenly be > lopped silently at level three today. If you install a new version of a compiler, you should, in general, not expect it to behave exactly the same way as a previous version - if it did, there would be no need to deliver the new version. More generally, you cannot have ANY justified expectations about the behavior of code with undefined behavior unless something other than the C standard defines the behavior that C declares to be "undefined". It need not have the same behavior even when the same executable is executed with the same inputs twice in a row. That's a real-world possibility, which I've seen with my own eyes, not just some theoretical abstraction. ... > Being "programmer friendly" is not the same as being "user friendly". > > There are guards on band saws, for example, for a reason. Which do not render it impossible to cut yourself with one. There are diagnostic messages for compilers, many of them mandated by relevant standard - which do not prevent you from writing code that triggers none of those diagnostics, yet still has incorrect behavior. That's life. It's a problem that can be dealt with, but cannot be solved completely. So? >>>> Anyone who has programmed significantly knows that - you >>>> check for validity first, then use the data. >>> >>> Yep. Read back over that and tell me that even experienced programmers >>> might not understand that using an uninitialized pointer occurs well > before you try to use the data it doesn't point to. >> >> Experienced programmers should understand that; if they don't, they need >> more experience (or better yet, relevant education). > > ... education by you and who's army of seminar instructors? Well, my participation in this newsgroup is intended to be educational - and not just to myself, so I guess that part's accurate. That army of other instructors (most of them teaching classes, not seminars) does exist, too. That army might not but adequate to the task. Even if it is, there will still always be some programmers who had not yet learned any particular relevant fact, particularly since the set of relevant facts is constantly changing. > They need experience. How do they get experience except by writing code? That's precisely the process I recommend that they use. Your point? ... >>>> Some programming languages are a bit more forgiving of learners, but C >>>> expects the programmer to know what he/she/it is doing, and does not go >>>> out of its way to penalise the productivity of experts in order to help >>>> beginners. >>> >>> And, if I have to hammer this fact home, none of us are very much beyond >>> beginners, including the experts. >> >> I'm very much beyond being a beginner at C, as are most of the other >> experts monitoring this newsgroup. ... > As a programmer, though, and I am not trying to put you down, you are > not a lot further along than the rest of us. I'm afraid I must disagree with you about that. I am in fact a lot further along than most of you (only one person has ever accused me of excessive modesty, and as far as I can tell, he was crazy (I mean that literally)). > Unless you want to assert that the singularity has already occurred, > we, as an industry, and as a civilization, have hardly scratched the > surface. The fact that there's a lot more that could be learned doesn't mean that different people can't have vastly different levels of success in what they have learned. ... >> No, you used your compiler in a mode where it implements GnuC, not >> standard C. GnuC supports the syntax you used, standard C does not, so >> it wouldn't be appropriate for gcc to have even warned you, much less >> refuse to accept your code. > > Okay, I'd forgotten that I'd read somewhere, at 2:34 AM, that the > default for gcc is to compile by its own rules, which includes > extensions. Keep in mind that, in this regard, gcc is no different from most other C compilers, and probably most other compilers for any language. Unless you specifically tell them to do otherwise, they compile a language that is not entirely identical to that specified by any external standard. ... > Some people, not me, would say that gcc should by default compile as > close to the standard as they have been able to implement at any point > in time. Gcc's developers have chosen to have gcc, by default, compile a language that, in their opinion, is a significantly better language to use than C itself. Given that they feel that way, why shouldn't they make it the default? It also does a pretty good job of conforming to relevant standards, if you explicitly inform it that you want it to do so. That seems to me to provide the best of both worlds. > I kind of wish I'd been able to squeeze in a little more time to fully > understand flexible arrays before I started using them. That's a good general point to apply to use of any feature of any language. Keep it in mind for the future. You complain that it's hard work? Welcome to the world, where most things useful require hard work to achieve - the easy ones have already been achieved. ... >>> Can we call it the target standard? >> >> No. It's an actual standard, not a target one. > > If it's not a target standard, it's not a standard. That comment proves that I don't know what you mean by a target standard. To me, a target standard is a standard which is targeted for completion in the future. It might not have been published yet, it might not have been approved yet, it might not have even been written yet, but it is targeted for completion. All three of those things must have happened before I would consider it an actual standard. So you're clearly using the term "target standard" in some other sense. Would you care to define the term? >>> Culturally, we tend to think too much top-down in our organizing. We >>> need more bottom-up participation in the Standards processes. >> >> The committee is a volunteer organization that just about anybody can >> join (it costs a fair amount of money, but anyone sufficiently competent >> to serve on the committee should be earning enough money to afford the >> membership fees without much trouble). You can't get much more bottom-up >> than that. > > Money solves everything? No. But it's a relatively small amount of money for anyone sufficiently competent to contribute, while being large enough to discourage many people who aren't. Those fees aren't being collected for the purpose of providing such filtering, that's just a side-effect. They're being collected because this activity is so poorly funded that part of the funding needed to cover the costs of the process has to come from the volunteers. > Only the elite should have input? You have a problem with that? This isn't the kind of matter that should be decided by a vote in which everyone has equal weight. Different people have different skill levels. Things like official standards should be primarily be the work of people with above-average skill levels, as far above average as is feasible. ISO cannot afford to pay for the highest skill levels, and they don't have the option of being very selective when deciding which volunteers to accept. As far as I know, the only filter they apply is that any given organization (even Microsoft) can only be officially represented on the Committee by one member. However, you are permitted to specify that you represent the organization named "Self", and that's the only "organization" allowed to have multiple representatives :-). The fact that the standard is produced by volunteers who actually have to pay for the privilege of participating does tend to make them self-selected for high levels of motivation and confidence. They are, in fact, fairly well above average in their skill levels.
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-29 01:44 -0700 |
| Message-ID | <182d1db0-ba61-4f70-ad61-5929e458d27c@googlegroups.com> |
| In reply to | #110850 |
On Monday, May 29, 2017 at 4:59:10 PM UTC+9, James Kuyper wrote:
> On 05/28/2017 09:53 AM, joel.rees@dokoka wrote:
> > On Sunday, May 28, 2017 at 5:22:30 AM UTC+9, James Kuyper wrote:
> >> On 05/27/2017 02:46 AM, joel.rees@outinleftfield wrote:
> >>> On Friday, May 26, 2017 at 10:05:31 PM UTC+9, David Brown wrote:
> ...
> >>>> This has not changed. The only
> >>>> thing that changed was the effect produced by this undefined behaviour.
> >>>> gcc now produces slightly more efficient code in the case where the
> >>>> code is correct, but perhaps more unexpected code in the case where the
> >>>> code is wrong. It does not make correct code, or even code that is
> >>>> implementation-dependent, into incorrect code - it makes incorrect code
> >>>> into incorrect code with unexpected effects.
> >>>
> >>> There are two issues with what you are saying.
> >>>
> >>> First, there is no such thing as correct code, only code which passes
> >>> the compiler in use, which can be further subdivided by how closely
> >>> it follows the Standard.
> >>
> >> Perhaps - I suppose that depends upon what you mean by "correct code" -
>
> Certainty about the truth of any statement about the real world is a
> delusional state. It's not possible to collect enough information to
> have justified certainty about any such statement. The best you can do
> is collect enough information to justify having a sufficiently high
> level of confidence to justify behaving as if it were true, while being
> open to conflicting evidence that might change your mind about that.
> [...]
I did take time to read what you wrote. And I apologize for moving you
to take the time to write it.
I think we are basically arguing abstractly over how to set a sufficient
level of confidence to proceed, which is not going to be productive to
continue.
Can I ask one more question? And then I'll try to get my focus back on
my primary projects.
When I was responding to Keith's response to my going a little over the
top about #pragma packed structs in gcc being able to incur alignment
exceptions without a lot of care, I realized what is probably worrying
me the most about trying to write this interpreter in C.
I have a lot of primitives that look like this:
----------------------------
void ALLOT(void)
{ /* We don't have ROM in the high half of memory,
// so testing the high bit (sign) of DP would be wrong.
// Or would it? Trying to allocate negative, or more than 2 G?
// That should be picked up in HERERR, anyway,
// but does it make sense to check separately here for real nonsense?
*/
UP.task->dictionaryAllocationPointer.bytep += ( * SP++ ).integer;
HERERR;
}
----------------------------
I guess those global variables are not under the same requirement of
test-before-access as parameters are.
Otherwise, my entire interpreter might as well be lopped.
From what you know of the standard, do you think that's a safe
assumption relative to (reasonably) standard compliant compilers?
I'm hoping Keith will tell me his opinion, too, and between the two
opinions and my own, I can decide whether to abandon the thing or
try to deal with the flexible arrays.
--
Joel Rees
Delusions of being a novelist:
http://reiisi.blogspot.com/p/novels-i-am-writing.html
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-05-29 13:48 +0100 |
| Message-ID | <87wp8z3k2x.fsf@bsb.me.uk> |
| In reply to | #110852 |
joel.rees@gmail.com writes:
<snip>
> I have a lot of primitives that look like this:
>
> ----------------------------
> void ALLOT(void)
> { /* We don't have ROM in the high half of memory,
> // so testing the high bit (sign) of DP would be wrong.
> // Or would it? Trying to allocate negative, or more than 2 G?
> // That should be picked up in HERERR, anyway,
> // but does it make sense to check separately here for real nonsense?
> */
> UP.task->dictionaryAllocationPointer.bytep += ( * SP++ ).integer;
> HERERR;
> }
> ----------------------------
>
> I guess those global variables are not under the same requirement of
> test-before-access as parameters are.
The issue is not just testing before access. You can ensure the
accesses are safe by other means -- the more appropriate being to take
action when the allocation fails. If the pointers are not set by
allocation (for example if they point to declared objects), just make
sure they are set before use.
> Otherwise, my entire interpreter might as well be lopped.
I don't see the problem. Having all the code removed is going to flag
up the problem very clearly. In the old days we used to spend days
tracking down unset pointers. Getting the wrong results because the code
accesses garbage sometimes even went unnoticed -- until the customer
complained.
> From what you know of the standard, do you think that's a safe
> assumption relative to (reasonably) standard compliant compilers?
I think that's not really the right question. If you access an
indeterminate pointer (or one that is "known" but invalid) the code has
a serious flat that needs to be fixed. I don't see the point in trying
to work out if you can get away with something.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-29 06:46 -0700 |
| Message-ID | <75c8f648-24f9-4843-835d-074fa981db82@googlegroups.com> |
| In reply to | #110869 |
On Monday, May 29, 2017 at 9:48:35 PM UTC+9, Ben Bacarisse wrote:
> joel.rees@dokodem writes:
> <snip>
> > I have a lot of primitives that look like this:
> >
> > ----------------------------
> > void ALLOT(void)
> > { /* We don't have ROM in the high half of memory,
> > // so testing the high bit (sign) of DP would be wrong.
> > // Or would it? Trying to allocate negative, or more than 2 G?
> > // That should be picked up in HERERR, anyway,
> > // but does it make sense to check separately here for real nonsense?
> > */
> > UP.task->dictionaryAllocationPointer.bytep += ( * SP++ ).integer;
> > HERERR;
> > }
> > ----------------------------
> >
> > I guess those global variables are not under the same requirement of
> > test-before-access as parameters are.
>
> The issue is not just testing before access. You can ensure the
> accesses are safe by other means -- the more appropriate being to take
> action when the allocation fails.
If the allocation fails, I'm getting recursive calls thousands deep
somewhere. I won't say it isn't happening, but the intentionally heavily
recursing code is complete by the time it gives me a command line prompt,
and the segment faults occur after I get the prompt.
The stack is tested every pass through the inner interpreter, but there
is a lot of code that doesn't reach the inner interpreter.
Testing the stack in every primitive would close to double the code being executed. Or more than double, if I have to check for both underflow and
overflow. Stack space is allocated dynamically for both stacks, so the
limits to check against are also in globals.
> If the pointers are not set by
> allocation (for example if they point to declared objects), just make
> sure they are set before use.
>
> > Otherwise, my entire interpreter might as well be lopped.
>
> I don't see the problem.
The problem is communicating to the compiler the fact that these globals
are supposed to be known good by the time these primitives are called.
If the compiler doesn't trust globals used the way I'm using them, when
they are set in startup code in some other file, then I basically have
16,000 lines of trash, rather than a Forth interpreter that can be maybe
salvaged with some work.
Or maybe I can call it artwork instead of trash. :-/
> Having all the code removed is going to flag
> up the problem very clearly.
All that would say is that the compiler writers don't trust globals.
I guess that would flag up the problem clearly:
"C is no longer a language to write anything but fancy Pascal programs in."
> In the old days we used to spend days
> tracking down unset pointers. Getting the wrong results because the code
> accesses garbage sometimes even went unnoticed -- until the customer
> complained.
Well, I can't test code that doesn't exist.
> > From what you know of the standard, do you think that's a safe
> > assumption relative to (reasonably) standard compliant compilers?
>
> I think that's not really the right question.
What would the right question be?
> If you access an
> indeterminate pointer (or one that is "known" but invalid) the code has
> a serious flat that needs to be fixed. I don't see the point in trying
> to work out if you can get away with something.
If you're telling me that I should get busy and find out where the
segment errors are occurring, that would be great, because I would
understand that the way I've structured the interpreter as a bunch of
C function pointers is not a problem.
I can expect that the segfaults will be from some mishandling that is
separate from the way the primitives work.
If you are telling me that C compilers no longer trust global variables
that they don't see getting set, then you're saying I no longer have an
interpreter, that I have sixteen thousand lines of trash that cannot be
fixed.
--
Joel Rees
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-05-29 15:46 +0100 |
| Message-ID | <87lgpf3elt.fsf@bsb.me.uk> |
| In reply to | #110873 |
joel.rees@gmail.com writes:
> On Monday, May 29, 2017 at 9:48:35 PM UTC+9, Ben Bacarisse wrote:
>> joel.rees@dokodem writes:
>> <snip>
>> > I have a lot of primitives that look like this:
>> >
>> > ----------------------------
>> > void ALLOT(void)
>> > { /* We don't have ROM in the high half of memory,
>> > // so testing the high bit (sign) of DP would be wrong.
>> > // Or would it? Trying to allocate negative, or more than 2 G?
>> > // That should be picked up in HERERR, anyway,
>> > // but does it make sense to check separately here for real nonsense?
>> > */
>> > UP.task->dictionaryAllocationPointer.bytep += ( * SP++ ).integer;
>> > HERERR;
>> > }
>> > ----------------------------
>> >
>> > I guess those global variables are not under the same requirement of
>> > test-before-access as parameters are.
>>
>> The issue is not just testing before access. You can ensure the
>> accesses are safe by other means -- the more appropriate being to take
>> action when the allocation fails.
>
> If the allocation fails, I'm getting recursive calls thousands deep
> somewhere. I won't say it isn't happening, but the intentionally heavily
> recursing code is complete by the time it gives me a command line prompt,
> and the segment faults occur after I get the prompt.
I think we are talking at cross purposes.
I though you were asking if globals were exempt from the kind of
analysis that lead to the famous code-removal furor. I wanted to say
that it should not matter. If the code if correct, the compiler won't
be able to deduce that some code is effectively dead.
Anyway, some practical advice. Have you tries valgrind? I can't tell
you how much I would have paid to have valgrind in 80s. Also, gcc's
-fsanitize=undefined is pretty good too (as are the other more specific
-fsanitize options).
> The stack is tested every pass through the inner interpreter, but there
> is a lot of code that doesn't reach the inner interpreter.
>
> Testing the stack in every primitive would close to double the code
> being executed. Or more than double, if I have to check for both
> underflow and overflow. Stack space is allocated dynamically for both
> stacks, so the limits to check against are also in globals.
There may be ways to reduce the work, but you need to decide if you want
to take the risk of undefined accesses.
>> If the pointers are not set by
>> allocation (for example if they point to declared objects), just make
>> sure they are set before use.
>>
>> > Otherwise, my entire interpreter might as well be lopped.
>>
>> I don't see the problem.
>
> The problem is communicating to the compiler the fact that these globals
> are supposed to be known good by the time these primitives are called.
You do that by writing code that makes them good, then there is no way
any future compiler can deduce otherwise. Obviously you know this, so
to explore it any further I'd want to know what is you are doing now
that you know to be dodgy or think might be dodgy. If your code is
correct, the compiler won't mess with it (barring compiler bugs but you
can't plan for those).
> If the compiler doesn't trust globals used the way I'm using them, when
> they are set in startup code in some other file, then I basically have
> 16,000 lines of trash, rather than a Forth interpreter that can be maybe
> salvaged with some work.
>
> Or maybe I can call it artwork instead of trash. :-/
Why do you think the compiler might not trust them? What is it that you
are specifically worried about?
If you can execute *SP++ when SP does not point to correctly allocated
storage then why are you worrying about what the compiler will do? I'd
be worrying that the code is wrong.
>> Having all the code removed is going to flag
>> up the problem very clearly.
>
> All that would say is that the compiler writers don't trust globals.
> I guess that would flag up the problem clearly:
>
> "C is no longer a language to write anything but fancy Pascal
> programs in."
Eh? C was never a language where relying on some specific undefined
behaviour was a safe option in portable code. You can arrange
system-specific tricks, like memory mapping, to get signals when
accessing out-of-range pointers, but C has never provided any way to do
that sort of thing in portable code.
>> In the old days we used to spend days
>> tracking down unset pointers. Getting the wrong results because the code
>> accesses garbage sometimes even went unnoticed -- until the customer
>> complained.
>
> Well, I can't test code that doesn't exist.
>
>> > From what you know of the standard, do you think that's a safe
>> > assumption relative to (reasonably) standard compliant compilers?
>>
>> I think that's not really the right question.
>
> What would the right question be?
Just "is the code correct?", rather than "are these assumptions safe?".
>> If you access an
>> indeterminate pointer (or one that is "known" but invalid) the code has
>> a serious flat that needs to be fixed. I don't see the point in trying
>> to work out if you can get away with something.
>
> If you're telling me that I should get busy and find out where the
> segment errors are occurring, that would be great, because I would
> understand that the way I've structured the interpreter as a bunch of
> C function pointers is not a problem.
Yes, if you are getting errors then finding the source is surely your
priority. It's unlikely to be that the compiler is breaking your
otherwise correct code. Does valgrind help you at all?
> I can expect that the segfaults will be from some mishandling that is
> separate from the way the primitives work.
>
> If you are telling me that C compilers no longer trust global variables
> that they don't see getting set, then you're saying I no longer have an
> interpreter, that I have sixteen thousand lines of trash that cannot be
> fixed.
No, that would daft. But equally, just because an object is global does
not mean the compiler can't or won't deduce things from accesses to it.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-05-29 15:40 -0400 |
| Message-ID | <oght8c$jc3$1@dont-email.me> |
| In reply to | #110873 |
On 05/29/2017 09:46 AM, joel.rees@gmail.com wrote:
> On Monday, May 29, 2017 at 9:48:35 PM UTC+9, Ben Bacarisse wrote:
>> joel.rees@dokodem writes:
>> <snip>
>>> I have a lot of primitives that look like this:
>>>
>>> ----------------------------
>>> void ALLOT(void)
>>> { /* We don't have ROM in the high half of memory,
>>> // so testing the high bit (sign) of DP would be wrong.
>>> // Or would it? Trying to allocate negative, or more than 2 G?
>>> // That should be picked up in HERERR, anyway,
>>> // but does it make sense to check separately here for real nonsense?
>>> */
>>> UP.task->dictionaryAllocationPointer.bytep += ( * SP++ ).integer;
>>> HERERR;
>>> }
>>> ----------------------------
>>>
>>> I guess those global variables are not under the same requirement of
>>> test-before-access as parameters are.
...
>>> Otherwise, my entire interpreter might as well be lopped.
>>
>> I don't see the problem.
>
> The problem is communicating to the compiler the fact that these globals
> are supposed to be known good by the time these primitives are called.
>
> If the compiler doesn't trust globals used the way I'm using them, when
> they are set in startup code in some other file, then I basically have
> 16,000 lines of trash, rather than a Forth interpreter that can be maybe
> salvaged with some work.
If you've taken the effort to make sure that the relevant globals never
have any dangerous values at the time ALLOT() is called, then there's
nothing that a conforming implementation of C is allowed to do to your
code that should bother you. Please note: making sure that your startup
code sets them to valid initial values is NOT sufficient. Your code must
also ensure that they never acquire dangerous values after initialization.
...
>> If you access an
>> indeterminate pointer (or one that is "known" but invalid) the code has
>> a serious flat that needs to be fixed. I don't see the point in trying
>> to work out if you can get away with something.
>
> If you're telling me that I should get busy and find out where the
> segment errors are occurring, that would be great, because I would
> understand that the way I've structured the interpreter as a bunch of
> C function pointers is not a problem.
It's entirely possible that what he says is true, even if the structure
of your code is also a problem - and what I've seen of that structure
does seem problematic.
> I can expect that the segfaults will be from some mishandling that is
> separate from the way the primitives work.
From the small sample that I've seen, your primitives are pretty
dangerous. If you've failed to take all of the precautions needed to
make them safe, then the segfaults could very well be caused by "the way
the primitives work".
> If you are telling me that C compilers no longer trust global variables
> that they don't see getting set,
It's an issue of whether or not those variables have dangerous values,
not an issue of whether the compiler trusts that the values are valid.
The code optimization you're complaining about is actually due to the
compiler trusting that the relevant variable has been prevented by other
parts of your from have a null value, as it must, in order to prevent
the code from having undefined behavior. It's precisely because of that
trust that the compiler is removing the unnecessary test for null which
occurs after the expression that would have undefined behavior if the
pointer were null, along with all of the code controlled by that test.
> then you're saying I no longer have an
> interpreter, that I have sixteen thousand lines of trash that cannot be
> fixed.
That seems entirely possible, but not for the reasons you've been giving.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-29 17:18 -0700 |
| Message-ID | <lntw43qjs4.fsf@kst-u.example.com> |
| In reply to | #110873 |
joel.rees@gmail.com writes:
[...]
>> joel.rees@dokodem writes:
>> <snip>
>> > I have a lot of primitives that look like this:
>> >
>> > ----------------------------
>> > void ALLOT(void)
>> > { /* We don't have ROM in the high half of memory,
>> > // so testing the high bit (sign) of DP would be wrong.
>> > // Or would it? Trying to allocate negative, or more than 2 G?
>> > // That should be picked up in HERERR, anyway,
>> > // but does it make sense to check separately here for real nonsense?
>> > */
>> > UP.task->dictionaryAllocationPointer.bytep += ( * SP++ ).integer;
>> > HERERR;
>> > }
>> > ----------------------------
>> >
>> > I guess those global variables are not under the same requirement of
>> > test-before-access as parameters are.
I don't know what "global variables" you're referring to.
[...]
> If you are telling me that C compilers no longer trust global variables
> that they don't see getting set, then you're saying I no longer have an
> interpreter, that I have sixteen thousand lines of trash that cannot be
> fixed.
Strictly speaking, C doesn't have anything called "global variables".
Scope and storage duration are separate concepts. What some languages
would call a "global variable" might be an object defined at file scope.
Such an object cannot be uninitialized, because any object defined at
file scope (outside any function) or with the "static" keyword, if it's
not explicitly initialized, is implicitly initialized to zero. The
meaning of "zero" in this context is a little complicated; it means that
all integers are initialized to 0, all floating-point objects to 0.0,
all pointers to NULL, and all arrays, structures, and unions have their
elements/members recursively initialized as above.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-05-29 15:08 -0400 |
| Message-ID | <oghrcc$cqc$1@dont-email.me> |
| In reply to | #110852 |
On 05/29/2017 04:44 AM, joel.rees@gmail.com wrote:
...
> Can I ask one more question? And then I'll try to get my focus back on
> my primary projects.
>
> When I was responding to Keith's response to my going a little over the
> top about #pragma packed structs in gcc being able to incur alignment
> exceptions without a lot of care, I realized what is probably worrying
> me the most about trying to write this interpreter in C.
>
> I have a lot of primitives that look like this:
>
> ----------------------------
> void ALLOT(void)
> { /* We don't have ROM in the high half of memory,
> // so testing the high bit (sign) of DP would be wrong.
> // Or would it? Trying to allocate negative, or more than 2 G?
> // That should be picked up in HERERR, anyway,
> // but does it make sense to check separately here for real nonsense?
> */
> UP.task->dictionaryAllocationPointer.bytep += ( * SP++ ).integer;
> HERERR;
> }
> ----------------------------
>
> I guess those global variables are not under the same requirement of
> test-before-access as parameters are.
No - if any of the relevant variables could have a value that would
render the behavior of that expression undefined, then you need to test
whether they have such values, and make sure that the expression is NOT
executed unless none of the relevant variables has such a value. That's
equally true whether you use global variables or parameters.
Here's a list of the dangerous possibilities that you need to either
prevent or test for:
* If SP is null, both SP++ and *SP have undefined behavior.
* If SP points one past the end of the relevant array, then SP++ and *SP
both have undefined behavior.
* If UP.task is null, or points one past the end of an array, the
behavior of UP.task->dictionaryAllocationPointer is undefined.
* If UP.task->dictionaryAllocationPointer.bytep is null, the behavior of
the += expression is undefined.
* If( * SP++ ).integer has a value that's not positive, the names used
in this code suggest to me that something will not work as intended.
* UP.task->dictionaryAllocationPointer.bytep must point into an array.
If the number of elements in the array after the one that it points at
is smaller than ( * SP++ ).integer, then the += expression has undefined
behavior (I may have an off-by-one error in my description of the danger
condition).
Here's a list of dangerous possibilities that you cannot test for - the
only option you have to avoid undefined behavior is to make sure that
they don't come up:
* If UP.task, UP.task->dictionaryAllocationPointer.bytep, SP, or
(*SP).integer has an indeterminate value, it might have a trap
representation, in which case the behavior of your code is undefined.
Even if it doesn't have a trap representation, the object will contain
the representation of an unspecified value. It's pretty much impossible
that making use of that unspecified value is a good idea, even if it
doesn't have one of the dangerous values listed above.
Please note that every issue listed above is your responsibility to
check, not the compiler's, and is controlled entirely by the code in
your program. If your code is written properly, to either prevent those
issues from coming up, or making sure the expression is not executed if
any of those issues do come up, there there's nothing that the compiler
has a right to do with your code that should cause you any problems.
> Otherwise, my entire interpreter might as well be lopped.
I think you're misunderstanding something: the code that got lopped was
code that could only have been executed if the variable being tested had
a value that guarantees that a previous expression had undefined
behavior. It's the fact that the test was performed after executing that
line, that allowed the test and the code it controlled to be "lopped
off". What that code should have done is used the test to ensure that if
the relevant variable had a dangerous value, the dangerous expression
wasn't even get executed.
On a different branch of this discussion, I see that you claim that the
rest of the code in your program is carefully written to prevent any of
those dangerous conditions from applying at the time that ALLOT() is
called. If that is indeed the case, then if you added the following code
at the end of ALLOT():
if(SP==NULL)
{
printf("This should never happen.\n");
}
the printf() statement would be guaranteed to never be executed.
Therefore, it shouldn't matter to you whether or not that code actually
gets lopped off - which is precisely why it's permissible for a compiler
to lop it off.
> From what you know of the standard, do you think that's a safe
> assumption relative to (reasonably) standard compliant compilers?
I can only address fully-conforming implementations of C. Any
implementation that is less than fully conforming might fail to conform
in a way that is relevant to the issues discussed above.
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-29 20:40 -0700 |
| Message-ID | <e81d6408-47df-43e4-8cd0-acbbf9883dbc@googlegroups.com> |
| In reply to | #110891 |
On Tuesday, May 30, 2017 at 4:08:21 AM UTC+9, James Kuyper wrote:
> On 05/29/2017 04:44 AM, joel.rees@dokodemo wrote:
> ...
> > Can I ask one more question? And then I'll try to get my focus back on
> > my primary projects.
> >
> > When I was responding to Keith's response to my going a little over the
> > top about #pragma packed structs in gcc being able to incur alignment
> > exceptions without a lot of care, I realized what is probably worrying
> > me the most about trying to write this interpreter in C.
> >
> > I have a lot of primitives that look like this:
> >
> > ----------------------------
> > void ALLOT(void)
> > { /* We don't have ROM in the high half of memory,
> > // so testing the high bit (sign) of DP would be wrong.
> > // Or would it? Trying to allocate negative, or more than 2 G?
> > // That should be picked up in HERERR, anyway,
> > // but does it make sense to check separately here for real nonsense?
> > */
> > UP.task->dictionaryAllocationPointer.bytep += ( * SP++ ).integer;
> > HERERR;
> > }
> > ----------------------------
> >
> > I guess those global variables are not under the same requirement of
> > test-before-access as parameters are.
>
> No - if any of the relevant variables could have a value that would
> render the behavior of that expression undefined, then you need to test
> whether they have such values, and make sure that the expression is NOT
> executed unless none of the relevant variables has such a value. That's
> equally true whether you use global variables or parameters.
>
> Here's a list of the dangerous possibilities that you need to either
> prevent or test for:
>
> * If SP is null, both SP++ and *SP have undefined behavior.
Since SP is the stack pointer of the virtual Forth processor, it won't
be NULL unless some other serious problem has already occurred.
The stack check is in the high-level interpreter loop, before beginning
interpretation of each line. And in my checks, I'm making sure that
there is a buffer zone of two cells which hasn't been written two, as
well.
Whether that's enough or not is a separate question, but it's typical
of Forth interpreters, for the same reason that a C run time doesn't
check its stack between every op-code executed, unless the hardware
itself is checking.
> * If SP points one past the end of the relevant array, then SP++ and *SP
> both have undefined behavior.
The initialization routines allocate (malloc()) a large array, 64K,
by default, and point SP within that array.
Specifically, that array contains the return address stack, the parameter
stack (SP), some input buffers (around 1K, IIRC), and the symbol table heap.
Oh, and there is a short table of constants, and the task record is in
there, too, but together those are less than 100 entries, so less than 1K,
even on a 64-bit run-time.
Typical Forth programs take less than 4K of the heap, but there are
command-line parameters to increase the allocation. Stack usage typically
does not exceed ten calls deep, although I do have a recursive routine
in the startup code for balancing the symbol table tree. That is bounded
by the number of symbol table entries, or definitions, in the startup
vocabulary, which is less than 300.
Recursion is a potential problem, left up to the education of the Forth
programmer.
> * If UP.task is null, or points one past the end of an array, the
> behavior of UP.task->dictionaryAllocationPointer is undefined.
That is also part of the virtual processor, and if it is not valid,
some other serious problem has already occurred.
> * If UP.task->dictionaryAllocationPointer.bytep is null, the behavior of
> the += expression is undefined.
Testing (HERERR) after the allocation instead of before is a little
distasteful to me, but the code is following a model virtual Forth
processor that does it that way.
Either way, this is adjusting the pointer itself, and there is neither
read nor write on the pointer until after HERERR tests it, so even if
the test-after-read pruning were applied on this code, it really
shouldn't be applied here.
I'm thinking I'll see if moving the test to before the math will cause
confusion in the error recovery routines I'm using.
But if you can't do math before testing a pointer, how are you going to
test the pointer -- unless the compiler team thinks they can tell when
your math is testing the pointer and when it is doing something else?
Hmm. From https://sourceforge.net/p/bif-c/code/HEAD/tree/trunk/bif2b_a.h
-----------------------
#define HERERR /* Check allocation limits. */ \
{ if ( UP.task->dictionaryAllocationPointer.cellp + 10 >= SP ) /* Probably want to buffer this, really. */ \
ALLERR; \
}
#define ALLERR mERROR( 2 ); /* Report allocation errors. */
-----------------------
From https://sourceforge.net/p/bif-c/code/HEAD/tree/trunk/bif5b_a.h
-----------------------
#define mERROR( number ) \
{ ( * --SP ).integer = number; \
mCALLdef( hERROR ); \
sysSIG.integer = ICODE_LIST_RETURN_ERROR; /* ERROR longjmp()s out to ABORT or QUIT. */ \
return; /* If it comes here, we have problems; bail one level, anyway, in hopes it catches the NEXT loop. */ \
}
-----------------------
and from https://sourceforge.net/p/bif-c/code/HEAD/tree/trunk/bif_vm.h
-----------------------
#define mCALLdefp( headerp ) ( ( * ( W.definitionp = headerp ) ).codeLink.icode )()
#define mCALLdef( header ) mCALLdefp( &header )
-----------------------
(W is a record of the currently executing definition, but I'm not using
it consistently between i-code defined definitions and C function defined
definitions. I don't always call the C functions through these two macros,
when I know that the C code never references W. If I forgot to use one
or the other of these macros on C code that references W, that could
well cause a segfault -- which is one reason for wanting to leave the
i-code list defined stuff as i-code lists so there's less chance to
forget. One more thing to keep an eye out for.)
Here's ERROR's (hERROR's) i-code list, from
https://sourceforge.net/p/bif-c/code/HEAD/tree/trunk/bif5b_a.c
-----------------------
{ /* { (natural_t) 0 Need to check what we're gonna do here! } */
{ (natural_t) &hWORDPD }, /* last WORD */
{ (natural_t) &hCOUNT },
{ (natural_t) &hTYPE },
/* This is why I wanted to write C source to compile the strings.
{ (natural_t) &hXDOTQ },
// But in-line strings are a serious pain in C source, because they move.
{ '\x3 ? ' },
*/
{ (natural_t) &hLIT },
{ (natural_t) sERROR_TAIL },
{ (natural_t) &hCOUNT },
{ (natural_t) &hTYPE },
{ (natural_t) &hMESS }, /* Potential array index bounds vulnerability, anyone? */
{ (natural_t) &hWARN },
{ (natural_t) &hFETCH },
{ (natural_t) &hZLESS },
{ (natural_t) &hZBR },
{ 2 * sizeof (cell_u) },
{ (natural_t) &hIABORT },
{ (natural_t) &hSPSTO },
{ (natural_t) &hIN },
{ (natural_t) &hFETCH },
{ (natural_t) &hBLK },
{ (natural_t) &hFETCH },
{ (natural_t) &hQUIT },
{ (natural_t) &hSEMIS }
}
};
-----------------------
It basically prints out an error message and then attempts to restore
the virtual processor to a known, functional state. This needs some
work, but it is basically the way Forth does it, so it theoretically
should work if C isn't doing something I don't expect.
> * If( * SP++ ).integer has a value that's not positive, the names used
> in this code suggest to me that something will not work as intended.
Actually, that is a "feature" of most Forths. Use a negative allocation
count to deallocate that much of the heap. Again, it's the Forth way,
and should theoretically be okay unless C is doing something I don't
expect.
> * UP.task->dictionaryAllocationPointer.bytep must point into an array.
> If the number of elements in the array after the one that it points at
> is smaller than ( * SP++ ).integer, then the += expression has undefined
> behavior (I may have an off-by-one error in my description of the danger
> condition).
As I describe above, it's pointing into the array it shares with the
stacks, etc.
There really aren't any arrays declared in this code that could come
after the big memory space array. But even if there were, the heap will
collide with both stacks well before a one-off could write into another
array.
> Here's a list of dangerous possibilities that you cannot test for - the
> only option you have to avoid undefined behavior is to make sure that
> they don't come up:
>
> * If UP.task, UP.task->dictionaryAllocationPointer.bytep, SP, or
> (*SP).integer has an indeterminate value, it might have a trap
> representation, in which case the behavior of your code is undefined.
> Even if it doesn't have a trap representation, the object will contain
> the representation of an unspecified value. It's pretty much impossible
> that making use of that unspecified value is a good idea, even if it
> doesn't have one of the dangerous values listed above.
Explicitly initialized in the startup.
> Please note that every issue listed above is your responsibility to
> check, not the compiler's, and is controlled entirely by the code in
> your program.
I am fully aware of that. I just worry, as you will note in my thoughts
about testing the allocation after the allocation pointer is adjusted,
whether the compiler is doing something I don't expect.
> If your code is written properly, to either prevent those
> issues from coming up, or making sure the expression is not executed if
> any of those issues do come up, there there's nothing that the compiler
> has a right to do with your code that should cause you any problems.
That's comforting.
> > Otherwise, my entire interpreter might as well be lopped.
>
> I think you're misunderstanding something: the code that got lopped was
> code that could only have been executed if the variable being tested had
> a value that guarantees that a previous expression had undefined
> behavior.
See below. You brought it back up.
> It's the fact that the test was performed after executing that
> line, that allowed the test and the code it controlled to be "lopped
> off". What that code should have done is used the test to ensure that if
> the relevant variable had a dangerous value, the dangerous expression
> wasn't even get executed.
>
> On a different branch of this discussion, I see that you claim that the
> rest of the code in your program is carefully written to prevent any of
> those dangerous conditions from applying at the time that ALLOT() is
> called. If that is indeed the case, then if you added the following code
> at the end of ALLOT():
>
> if(SP==NULL)
> {
> printf("This should never happen.\n");
> }
>
> the printf() statement would be guaranteed to never be executed.
> Therefore, it shouldn't matter to you whether or not that code actually
> gets lopped off - which is precisely why it's permissible for a compiler
> to lop it off.
Oh, well, maybe I can use this to explain why, even though I have
explained several times that I would not use the problematic technique
myself, I think that lopping that code would be just plain mean,
arrogantly assuming that the optimizer knows best.
Can you stand one more try?
Say I know that my hardware is not stable. It's a new design, with a
lot of circuitry that may not be getting enough power.
But I need to exercise the hardware so that I can watch power
consumption at various probe points.
One of the observed failure states is that the area of memory in which
I've told gcc to allocate the global-scope statically allocated
variables that are the registers in my virtual CPU tends to lose its
contents and go to zero.
Do you see why I have might have such a test in there?
Of course it wouldn't be a printf(). It would be a little lower level
than that, output to an LED or something. And I'd probably brace the
allocation with the output statements.
I know. It's a bit of a contrived example.
But there's another possibility involving stable hardware.
In fishing out some obscure behavior in a primitive, in part of the
code where inserting a printf() won't work for some reason, I may
deliberately pass an allocation value to ALLOT that will set the
final value of the allocation pointer to NULL, as a flag for what
went wrong in that other place.
Do I have a memory of actually having done something like this in the
past? Indeed I do. NULL was a very convenient flag value, much more
convenient than (char *) 1 or such.
Not that there is no other way, just that there might be valid use
for such a construct, and it will be awkward to remember to avoid
NULL next time I want to use such a debugging trick.
> > From what you know of the standard, do you think that's a safe
> > assumption relative to (reasonably) standard compliant compilers?
>
> I can only address fully-conforming implementations of C. Any
> implementation that is less than fully conforming might fail to conform
> in a way that is relevant to the issues discussed above.
Anyway, thanks. I wish I could afford to offer to send you and Keith
each a pizza, for your time helping me figure out what to do with this
interpreter, and for your willingness to help me try to resuscitate my
C language skills. For now I'll just have to say thanks.
--
Joel Rees
Trying to re-invent the industry all by myself:
http://defining-computers.blogspot.jp/
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2017-05-30 00:49 -0700 |
| Message-ID | <54835eb1-5836-4869-b562-7ae7745568ec@googlegroups.com> |
| In reply to | #110920 |
On Monday, May 29, 2017 at 10:40:54 PM UTC-5, joel...@gmail.com wrote: > On Tuesday, May 30, 2017 at 4:08:21 AM UTC+9, James Kuyper wrote: > > Here's a list of the dangerous possibilities that you need to either > > prevent or test for: > > > > * If SP is null, both SP++ and *SP have undefined behavior. > > Since SP is the stack pointer of the virtual Forth processor, it won't > be NULL unless some other serious problem has already occurred. > > The stack check is in the high-level interpreter loop, before beginning > interpretation of each line. And in my checks, I'm making sure that > there is a buffer zone of two cells which hasn't been written two, as > well. > > Whether that's enough or not is a separate question, but it's typical > of Forth interpreters, for the same reason that a C run time doesn't > check its stack between every op-code executed, unless the hardware > itself is checking. > I think it's perfectly appropriate for any kind of interpreter to do a modest sanity check in the main loop. https://github.com/luser-dr00g/xpost/blob/master/src/lib/xpost_interpreter.c#L569 All the pointers that must be non-NULL can be checked at once.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-05-30 11:54 +0100 |
| Message-ID | <87fufm3996.fsf@bsb.me.uk> |
| In reply to | #110920 |
joel.rees@gmail.com writes: <snip> > [...] I just worry, as you will note in my thoughts > about testing the allocation after the allocation pointer is adjusted, > whether the compiler is doing something I don't expect. If you move a pointer that points into an array, and then test if it is still in (or just past) the array, the compiler would be permitted to remove the test. However, I don't know any that do this. For one thing there is probably not much to gain and, for another, the compiler could tell this was the case in only the very simplest of cases. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-05-30 09:48 -0400 |
| Message-ID | <ogjt0d$rk7$1@dont-email.me> |
| In reply to | #110920 |
On 05/29/2017 11:40 PM, joel.rees@gmail.com wrote:
> On Tuesday, May 30, 2017 at 4:08:21 AM UTC+9, James Kuyper wrote:
>> On 05/29/2017 04:44 AM, joel.rees@dokodemo wrote:
...
>>> I have a lot of primitives that look like this:
>>>
>>> ----------------------------
>>> void ALLOT(void)
>>> { /* We don't have ROM in the high half of memory,
>>> // so testing the high bit (sign) of DP would be wrong.
>>> // Or would it? Trying to allocate negative, or more than 2 G?
>>> // That should be picked up in HERERR, anyway,
>>> // but does it make sense to check separately here for real nonsense?
>>> */
>>> UP.task->dictionaryAllocationPointer.bytep += ( * SP++ ).integer;
>>> HERERR;
>>> }
>>> ----------------------------
>>>
>>> I guess those global variables are not under the same requirement of
>>> test-before-access as parameters are.
>>
>> No - if any of the relevant variables could have a value that would
>> render the behavior of that expression undefined, then you need to test
>> whether they have such values, and make sure that the expression is NOT
>> executed unless none of the relevant variables has such a value. That's
>> equally true whether you use global variables or parameters.
>>
>> Here's a list of the dangerous possibilities that you need to either
>> prevent or test for:
I want to emphasize that I was simply providing a comprehensive list; I
would normally expect that most of these issue are avoided by correct
design of the rest of the program. There's only one test that I'd expect
to be carried out within this routine, and that's testing whether the +=
might push bytep more than one position past the end of the relevant array.
...
>> * If UP.task->dictionaryAllocationPointer.bytep is null, the behavior of
>> the += expression is undefined.
>
> Testing (HERERR) after the allocation instead of before is a little
> distasteful to me, but the code is following a model virtual Forth
> processor that does it that way.
>
> Either way, this is adjusting the pointer itself, and there is neither
> read nor write on the pointer until after HERERR tests it, so even if
> the test-after-read pruning were applied on this code, it really
> shouldn't be applied here.
There are real machines that will cause your program to fail if an
attempt is made to load an invalid pointer value into a pointer
register, and the result after that addition could very well be an
invalid pointer. That's the reason why the C standard specifies that the
behavior of such an addition is undefined. Because the behavior is
undefined, even compilers targeting machines that don't have such a
feature are entitled to peform such optimizations.
Therefore, if you test whether the addition would have undefined
behavior, you should perform that test prior to the addition, and should
use the results of that test to prevent the addition from being
performed if it is in fact dangerous.
> I'm thinking I'll see if moving the test to before the math will cause
> confusion in the error recovery routines I'm using.
>
> But if you can't do math before testing a pointer, how are you going to
> test the pointer -- unless the compiler team thinks they can tell when
> your math is testing the pointer and when it is doing something else?
Set alloc_end to point one past the end of the array that bytep points
into. To save myself some typing, I'll simplify the context:
if(alloc_end - bytep < integer)
{
// error handling
} else {
bytep += integer;
}
> Hmm. From https://sourceforge.net/p/bif-c/code/HEAD/tree/trunk/bif2b_a.h
>
> -----------------------
> #define HERERR /* Check allocation limits. */ \
> { if ( UP.task->dictionaryAllocationPointer.cellp + 10 >= SP ) /* Probably want to buffer this, really. */ \
You've mentioned elsewhere that your emulated stack and heap share the
same block of memory. Assuming that cellp points at the top of the heap,
and SP points at the bottom of the stack, this is the correct
alternative - but only if you're certain that no allocation would be
bigger than 10
...
...
> I am fully aware of that. I just worry, as you will note in my thoughts
> about testing the allocation after the allocation pointer is adjusted,
> whether the compiler is doing something I don't expect.
If you have any expectations whatsoever about the behavior of code that
the C standard says has undefined behavior, those expectations had
better come from some other authoritative source that defines the
behavior that C itself does not define. Since you sound uncertain about
these issues, I suspect that you have no such alternative source.
...
>> On a different branch of this discussion, I see that you claim that the
>> rest of the code in your program is carefully written to prevent any of
>> those dangerous conditions from applying at the time that ALLOT() is
>> called. If that is indeed the case, then if you added the following code
>> at the end of ALLOT():
>>
>> if(SP==NULL)
>> {
>> printf("This should never happen.\n");
>> }
That was a badly chosen example, because the relevant line of code
changes the value of SP. A more appropriate example would have used
UP.task instead of SP.
>> the printf() statement would be guaranteed to never be executed.
>> Therefore, it shouldn't matter to you whether or not that code actually
>> gets lopped off - which is precisely why it's permissible for a compiler
>> to lop it off.
>
> Oh, well, maybe I can use this to explain why, even though I have
> explained several times that I would not use the problematic technique
> myself, I think that lopping that code would be just plain mean,
> arrogantly assuming that the optimizer knows best.
>
> Can you stand one more try?
>
> Say I know that my hardware is not stable. It's a new design, with a
> lot of circuitry that may not be getting enough power.
>
> But I need to exercise the hardware so that I can watch power
> consumption at various probe points.
>
> One of the observed failure states is that the area of memory in which
> I've told gcc to allocate the global-scope statically allocated
> variables that are the registers in my virtual CPU tends to lose its
> contents and go to zero.
>
> Do you see why I have might have such a test in there?
No, I most emphatically do NOT see how that situation justifies
unconditionally executing the statement that might have undefined
behavior before testing whether the behavior would have been undefined.
I think it's unlikely that the Forth interpreter you've been talking
about elsewhere would be used in this kind of context. However, the code
for that interpreter is already part of this discussion, so I'll use it
to make my point. If UP.task were one of those pointers that's in danger
of getting spontaneously nulled, then the right way to test it is:
if(UP.task == NULL)
{
// error handling
} else {
UP.task->dictionaryAllocationPointer.bytep +=
( * SP++ ).integer;
}
Testing whether it's null after the undefined behavior may have already
caused your program to abort is pointless - which is why a conforming
implementation of C is allowed to remove that test along with the code
that is controlled by it.
...
> past? Indeed I do. NULL was a very convenient flag value, much more
> convenient than (char *) 1 or such.
Particularly since the (char*) 1 is not guaranteed to have a non-trap value.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-30 07:49 -0700 |
| Message-ID | <2f1c8306-e5bc-4f50-899b-3e4e7366e2d8@googlegroups.com> |
| In reply to | #110941 |
On Tuesday, May 30, 2017 at 8:48:23 AM UTC-5, James Kuyper wrote: > There are real machines that will cause your program to fail if an > attempt is made to load an invalid pointer value into a pointer > register, and the result after that addition could very well be an > invalid pointer. That's the reason why the C standard specifies that the > behavior of such an addition is undefined. Because the behavior is > undefined, even compilers targeting machines that don't have such a > feature are entitled to peform such optimizations. The fact that the authors of the Standard don't prohibit implementations from behaving in a particular fashion does not imply any judgment that such behavior would not render a compiler unsuitable for some purposes it might otherwise have been able to fulfill. The Standard makes no effort to distinguish behaviors which 99% of implementations should process in the same predictable and useful fashion, but which some implementations might possibly have reason to process differently, from those which few if any implementations could be expected to process in predictable fashion. No useful purpose is served by having compiler writers pretend that it does so.
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-30 10:20 -0700 |
| Message-ID | <c41151cd-d30e-4c87-8111-39864e5964f2@googlegroups.com> |
| In reply to | #110941 |
Let's see if I can string together an explanation of what I just found.
On Tuesday, May 30, 2017 at 10:48:23 PM UTC+9, James Kuyper wrote:
> On 05/29/2017 11:40 PM, joel.rees@mu wrote:
> > On Tuesday, May 30, 2017 at 4:08:21 AM UTC+9, James Kuyper wrote:
> >> On 05/29/2017 04:44 AM, joel.rees@dokodemo wrote:
> ...
> >>> I have a lot of primitives that look like this:
> >>>
> >>> ----------------------------
> >>> void ALLOT(void)
> >>> { /* We don't have ROM in the high half of memory,
> >>> // so testing the high bit (sign) of DP would be wrong.
> >>> // Or would it? Trying to allocate negative, or more than 2 G?
> >>> // That should be picked up in HERERR, anyway,
> >>> // but does it make sense to check separately here for real nonsense?
> >>> */
> >>> UP.task->dictionaryAllocationPointer.bytep += ( * SP++ ).integer;
> >>> HERERR;
> >>> }
> >>> ----------------------------
> >>>
> >>> I guess those global variables are not under the same requirement of
> >>> test-before-access as parameters are.
> >>
> >> No - if any of the relevant variables could have a value that would
> >> render the behavior of that expression undefined, then you need to test
> >> whether they have such values, and make sure that the expression is NOT
> >> executed unless none of the relevant variables has such a value. That's
> >> equally true whether you use global variables or parameters.
> >>
> >> Here's a list of the dangerous possibilities that you need to either
> >> prevent or test for:
>
> I want to emphasize that I was simply providing a comprehensive list; I
> would normally expect that most of these issue are avoided by correct
> design of the rest of the program. There's only one test that I'd expect
> to be carried out within this routine, and that's testing whether the +=
> might push bytep more than one position past the end of the relevant array.
And that is actually something Forths written this way never do.
The effective end of the heap is the current parameter stack pointer.
It hasn't been so long since your typical C run-time did the same thing,
by the way. ;|
Fortunately, Forth code typically does not allocate large objects on the
parameter stack, and large objects are typically allocated on the heap in
small increments.
> ...
> >> * If UP.task->dictionaryAllocationPointer.bytep is null, the behavior of
> >> the += expression is undefined.
> >
> > Testing (HERERR) after the allocation instead of before is a little
> > distasteful to me, but the code is following a model virtual Forth
> > processor that does it that way.
> >
> > Either way, this is adjusting the pointer itself, and there is neither
> > read nor write on the pointer until after HERERR tests it, so even if
> > the test-after-read pruning were applied on this code, it really
> > shouldn't be applied here.
>
> There are real machines that will cause your program to fail if an
> attempt is made to load an invalid pointer value into a pointer
> register, and the result after that addition could very well be an
> invalid pointer.
Thinking about this makes me wonder whether the compiler can track
which array any of the pointers in the virtual machine are pointing
into, with them all being kept in objects of cell_u union type,
particularly pointers that have spent any time on the parameter stack.
On an architecture whose pointers can trap if not known to be valid,
it might simply not be possible to compile this interpreter in any way
that would not trap as soon as the interpreter proper is entered, and
maybe even during the initializations.
> That's the reason why the C standard specifies that the
> behavior of such an addition is undefined. Because the behavior is
> undefined, even compilers targeting machines that don't have such a
> feature are entitled to peform such optimizations.
Let's keep that in mind.
> Therefore, if you test whether the addition would have undefined
> behavior, you should perform that test prior to the addition, and should
> use the results of that test to prevent the addition from being
> performed if it is in fact dangerous.
Well, the actual test being performed here is not against the end of
the physical array, but against the current stack pointer.
In the eval loop, I essentially check the following set of conditions:
bottom_of_heap <= allocation_pointer
allocation_pointer < parameter_stack_pointer - 10
parameter_stack_pointer <= bottom_of_parameter_stack
(where the parameter stack is inverted).
Now there are other things, as I mentioned, both above the parameter
stack and below the heap. (And there is, in fact, in many Forth
interpreters, a moving terminal input buffer at the top of the heap,
which I won't explain here.)
And, in this interpreter, I'm leaving small buffer zones at the actual
bottom and top of that array. (It occurs to me that calling them bumper
zones would probably be easier to understand.)
> > I'm thinking I'll see if moving the test to before the math will cause
> > confusion in the error recovery routines I'm using.
> >
> > But if you can't do math before testing a pointer, how are you going to
> > test the pointer -- unless the compiler team thinks they can tell when
> > your math is testing the pointer and when it is doing something else?
>
> Set alloc_end to point one past the end of the array that bytep points
> into. To save myself some typing, I'll simplify the context:
>
> if(alloc_end - bytep < integer)
> {
> // error handling
> } else {
> bytep += integer;
> }
That would actually be moving the macro HERERR before the allocation,
HERERR;
UP.task->dictionaryAllocationPointer.bytep += ( * SP++ ).integer;
and redefining HERERR from
if ( UP.task->dictionaryAllocationPointer.cellp + 10 >= SP )
ALLERR;
to
if ( SP - UP.task->dictionaryAllocationPointer.bytep
< ( * SP ).integer + 10 )
ALLERR;
after I make sure ALLERR can handle reporting allocation errors before
they happen.
Except that the allocation is not guaranteed to be on the top of the
stack in every use of HERERR. Maybe I can pass the allocation count
to HERERR as a macro parameter. In many cases, it will just be 0, but
I'll need to check all the uses, maybe define another macro to cover
some cases that won't fit.
> > Hmm. From https://sourceforge.net/p/bif-c/code/HEAD/tree/trunk/bif2b_a.h
> >
> > -----------------------
> > #define HERERR /* Check allocation limits. */ \
> > { if ( UP.task->dictionaryAllocationPointer.cellp + 10 >= SP ) /* Probably want to buffer this, really. */ \
>
> You've mentioned elsewhere that your emulated stack and heap share the
> same block of memory. Assuming that cellp points at the top of the heap,
> and SP points at the bottom of the stack, this is the correct
> alternative - but only if you're certain that no allocation would be
> bigger than 10
Maybe I should make that 5 * sizeof (cell_u), but it won't really be a
guarantee, just the knowledge that Forth code usually doesn't push
things larger than a double integer on the stack, and heap allocation
usually occurs in small increments, too.
> ...
> ...
> > I am fully aware of that. I just worry, as you will note in my thoughts
> > about testing the allocation after the allocation pointer is adjusted,
> > whether the compiler is doing something I don't expect.
>
> If you have any expectations whatsoever about the behavior of code that
> the C standard says has undefined behavior, those expectations had
> better come from some other authoritative source that defines the
> behavior that C itself does not define. Since you sound uncertain about
> these issues, I suspect that you have no such alternative source.
I hate to admit it, but my health is such that I can no longer read the
standard without falling asleep.
(And, yeah, I have to take a few extra precautions against falling
asleep with my hands on the keyboard, too. I'm only in my fifties, but
I have a few extra health issues.)
And then there's this problem that I keep expecting to be able to
interpret the standard according to what I consider good engineering
common sense.
> ...
> >> On a different branch of this discussion, I see that you claim that the
> >> rest of the code in your program is carefully written to prevent any of
> >> those dangerous conditions from applying at the time that ALLOT() is
> >> called. If that is indeed the case, then if you added the following code
> >> at the end of ALLOT():
> >>
> >> if(SP==NULL)
> >> {
> >> printf("This should never happen.\n");
> >> }
>
> That was a badly chosen example, because the relevant line of code
> changes the value of SP. A more appropriate example would have used
> UP.task instead of SP.
That wouldn't really be appropriate either, because UP.task never
changes within the context of the interpreter proper.
Testing the task record base is a bit beyond checking for NULLs and
boundaries.
> >> the printf() statement would be guaranteed to never be executed.
> >> Therefore, it shouldn't matter to you whether or not that code actually
> >> gets lopped off - which is precisely why it's permissible for a compiler
> >> to lop it off.
> >
> > Oh, well, maybe I can use this to explain why, even though I have
> > explained several times that I would not use the problematic technique
> > myself, I think that lopping that code would be just plain mean,
> > arrogantly assuming that the optimizer knows best.
> >
> > Can you stand one more try?
> >
> > Say I know that my hardware is not stable. It's a new design, with a
> > lot of circuitry that may not be getting enough power.
> >
> > But I need to exercise the hardware so that I can watch power
> > consumption at various probe points.
> >
> > One of the observed failure states is that the area of memory in which
> > I've told gcc to allocate the global-scope statically allocated
> > variables that are the registers in my virtual CPU tends to lose its
> > contents and go to zero.
> >
> > Do you see why I have might have such a test in there?
>
> No, I most emphatically do NOT see how that situation justifies
> unconditionally executing the statement that might have undefined
> behavior before testing whether the behavior would have been undefined.
And so you would condemn me to having to use assembly language code to
exercise said hardware while I characterize the power usage. Or at least
a C compiler running under a switch or pragma to suppress such
optimizations.
> I think it's unlikely that the Forth interpreter you've been talking
> about elsewhere would be used in this kind of context.
Quite on the contrary. That is, in fact, one of the primary targets for
this interpreter, if I can get it debugged and raise my confidence level
about how compilers will interpret the source.
Forth interpreters are quite often used as debug/monitors in new hardware.
> However, the code
> for that interpreter is already part of this discussion, so I'll use it
> to make my point. If UP.task were one of those pointers that's in danger
> of getting spontaneously nulled, then the right way to test it is:
>
> if(UP.task == NULL)
But UP.task will never be NULL after the startup code is done.
> {
> // error handling
> } else {
> UP.task->dictionaryAllocationPointer.bytep +=
> ( * SP++ ).integer;
> }
And if a compiler could track that fact out in its analysis of the code,
it would be free, I think, to lop the error handling branch off of that
bit of code you went to the trouble of writing.
Of course, now that you understand that UP.task will never be NULL, I
assume you won't complain about that.
> Testing whether it's null after the undefined behavior may have already
> caused your program to abort is pointless - which is why a conforming
> implementation of C is allowed to remove that test along with the code
> that is controlled by it.
>
> ...
> > past? Indeed I do. NULL was a very convenient flag value, much more
> > convenient than (char *) 1 or such.
>
> Particularly since the (char*) 1 is not guaranteed to have a non-trap value.
Good point. Although the use I was explaining kind of implies that it
was not on such hardware.
(I don't think I would ever build such hardware, but I do remember
daydreaming about ways to make such hardware usable, when I was about
twenty years younger than I am now.)
--
Joel Rees
Trying to re-invent the industry all by myself:
http://defining-computers.blogspot.jp/
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-05-30 14:50 -0400 |
| Message-ID | <137c6aa5-9633-c6eb-5857-966f2cf4630a@verizon.net> |
| In reply to | #110957 |
On 05/30/2017 01:20 PM, joel.rees@gmail.com wrote:
> Let's see if I can string together an explanation of what I just found.
>
> On Tuesday, May 30, 2017 at 10:48:23 PM UTC+9, James Kuyper wrote:
>> On 05/29/2017 11:40 PM, joel.rees@mu wrote:
>>> On Tuesday, May 30, 2017 at 4:08:21 AM UTC+9, James Kuyper wrote:
>>>> On 05/29/2017 04:44 AM, joel.rees@dokodemo wrote:
>> ...
>>>>> I have a lot of primitives that look like this:
>>>>>
>>>>> ----------------------------
>>>>> void ALLOT(void)
>>>>> { /* We don't have ROM in the high half of memory,
>>>>> // so testing the high bit (sign) of DP would be wrong.
>>>>> // Or would it? Trying to allocate negative, or more than 2 G?
>>>>> // That should be picked up in HERERR, anyway,
>>>>> // but does it make sense to check separately here for real nonsense?
>>>>> */
>>>>> UP.task->dictionaryAllocationPointer.bytep += ( * SP++ ).integer;
>>>>> HERERR;
>>>>> }
>>>>> ----------------------------
>>>>>
>>>>> I guess those global variables are not under the same requirement of
>>>>> test-before-access as parameters are.
>>>>
>>>> No - if any of the relevant variables could have a value that would
>>>> render the behavior of that expression undefined, then you need to test
>>>> whether they have such values, and make sure that the expression is NOT
>>>> executed unless none of the relevant variables has such a value. That's
>>>> equally true whether you use global variables or parameters.
>>>>
>>>> Here's a list of the dangerous possibilities that you need to either
>>>> prevent or test for:
>>
>> I want to emphasize that I was simply providing a comprehensive list; I
>> would normally expect that most of these issue are avoided by correct
...
>> design of the rest of the program. There's only one test that I'd expect
>> to be carried out within this routine, and that's testing whether the +=
>> might push bytep more than one position past the end of the relevant array.
>
> And that is actually something Forths written this way never do.
>
> The effective end of the heap is the current parameter stack pointer.
>
> It hasn't been so long since your typical C run-time did the same thing,
> by the way. ;|
I know - and I've always hated that fact. It's been decades since I had
any need to know such details (my code is explicitly prohibited from
depending upon the details of how any particular compiler works), so
I've no idea whether or not that approach is still commonplace.
However, when I was well aware of the fact that the compilers I used
worked that way, I welcomed the opportunity (which some compilers
provided) of turning on an option to check for possible collisions
between the heap and the stack before each attempt to push things onto
the stack. I don't remember what the impact of that option was on the
performance of the resulting code, but I don't remember it as being
prohibitively slow. I also don't remember the collision checks ever
being triggered.
...
>> There are real machines that will cause your program to fail if an
>> attempt is made to load an invalid pointer value into a pointer
>> register, and the result after that addition could very well be an
>> invalid pointer.
>
> Thinking about this makes me wonder whether the compiler can track
> which array any of the pointers in the virtual machine are pointing
> into,
I've no idea whether any compiler actually does that, but it certainly
would be permitted. What I do know is that many systems give each
process a certain block of memory for it's own use, and that on at least
some of those systems, any attempt to create a pointer to memory outside
that block will cause the process to be terminated, and that there's a
finite chance that any particular array might be sufficiently near the
boundary that creating a pointer that points more than one position past
the end of the array might trigger that result.
> with them all being kept in objects of cell_u union type,
> particularly pointers that have spent any time on the parameter stack.
>
> On an architecture whose pointers can trap if not known to be valid,
You've got it backward. A conforming implementation of C would not be
possible on such a system. The kinds of system I'm talking about traps
only if the pointer is known to not be valid.
...
> I hate to admit it, but my health is such that I can no longer read the
> standard without falling asleep.
>
> (And, yeah, I have to take a few extra precautions against falling
> asleep with my hands on the keyboard, too. I'm only in my fifties, but
> I have a few extra health issues.)
I'm around the same age, without any special health problems that are
relevant, but I've occasionally run into the same problem (except that I
actually can read the standard without falling asleep). Having twin
2-year olds to take care of hasn't exactly helped.
> And then there's this problem that I keep expecting to be able to
> interpret the standard according to what I consider good engineering
> common sense.
The "common" part of "common sense" refers to the implicit assumption
that everyone thinks in roughly the same way, and that anyone who
doesn't is mentally defective in some fashion. I recommend dropping that
assumption. The committee has a definite concept of what "good
engineering" means for language design, and their concept is
significantly different from yours. Whether or not they're right about
that, the fact is that they are the relevant authority, so if you intend
to use the language whose design they're responsible for, don't be
surprised if they made some decisions differently than you would.
>>>> On a different branch of this discussion, I see that you claim that the
>>>> rest of the code in your program is carefully written to prevent any of
>>>> those dangerous conditions from applying at the time that ALLOT() is
>>>> called. If that is indeed the case, then if you added the following code
>>>> at the end of ALLOT():
>>>>
>>>> if(SP==NULL)
>>>> {
>>>> printf("This should never happen.\n");
>>>> }
>>
>> That was a badly chosen example, because the relevant line of code
>> changes the value of SP. A more appropriate example would have used
>> UP.task instead of SP.
>
> That wouldn't really be appropriate either, because UP.task never
> changes within the context of the interpreter proper.
Which is a prime example of why the compiler is entitled to drop both
the test and the code controlled by it. You've taken adequate measures
to assure that the code will never have undefined behavior for that
reason, so the test is guaranteed to fail. Since the alternative would
be undefined behavior, the implementation is permitted to trust that
you've taken such measures, and it therefore permitted to remove both
the test and the code it controls.
The compiler is entitled to assume that you've taken similarly strong
efforts to assume than none of the other conditions I listed is
violated, which means tests of those conditions that don't prevent the
expression from being executed can also be dropped, the same way that
the test on UP.task could be dropped, and for precisely the same reason.
...
>>> Say I know that my hardware is not stable. It's a new design, with a
>>> lot of circuitry that may not be getting enough power.
>>>
>>> But I need to exercise the hardware so that I can watch power
>>> consumption at various probe points.
>>>
>>> One of the observed failure states is that the area of memory in which
>>> I've told gcc to allocate the global-scope statically allocated
>>> variables that are the registers in my virtual CPU tends to lose its
>>> contents and go to zero.
>>>
>>> Do you see why I have might have such a test in there?
>>
>> No, I most emphatically do NOT see how that situation justifies
>> unconditionally executing the statement that might have undefined
>> behavior before testing whether the behavior would have been undefined.
>
> And so you would condemn me to having to use assembly language code to
> exercise said hardware while I characterize the power usage. Or at least
> a C compiler running under a switch or pragma to suppress such
> optimizations.
No, I would condemn you to testing the condition before executing the
expression, and to avoid executing the expression if the test reveals
that the controlled expression would have undefined behavior. Why do you
find that alternative so distasteful?
>> However, the code
>> for that interpreter is already part of this discussion, so I'll use it
>> to make my point. If UP.task were one of those pointers that's in danger
>> of getting spontaneously nulled, then the right way to test it is:
>>
>> if(UP.task == NULL)
>
> But UP.task will never be NULL after the startup code is done.
If it were stored in the memory that can be spontaneously be zeroed out,
it could end up being nulled, at least if a zeroed out pointer is a null
pointer (which is not necessarily the case).
Note: if a zeroed-out pointer is a valid non-null pointer on such a
system, you should compare pointers that are at risk of getting zeroed
out with a zeroed-out pointer safely stored in some other piece of
memory, rather than with NULL.
If UP.task is not one of the pointers that's at risk of being
spontaneously zeroed-out, replace it with any other pointer that is at
risk, and replace the += expression below with any other expression that
would have undefined behavior if that pointer did get zeroed-out.
>> {
>> // error handling
>> } else {
>> UP.task->dictionaryAllocationPointer.bytep +=
>> ( * SP++ ).integer;
>> }
>
> And if a compiler could track that fact out in its analysis of the code,
> it would be free, I think, to lop the error handling branch off of that
> bit of code you went to the trouble of writing.
You're right - assuming that UP.task is immune to the spontaneous
zeroing that you were talking about above, that test is in fact
pointless, because it can never be triggered, and you therefore have no
legitimate reason to object to the test and error handling code being
removed. If you treat the executable as a black box, you would have no
way to prove that it's been removed, since no test could be performed
that would trigger the error handling code.
If a black-box test of the executable could be performed that would
prove that the error handling code had been removed, then a conforming
implementation of C would not be entitled to remove it.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-05-30 19:16 +0000 |
| Message-ID | <kyjXA.4$J83.2@fx39.iad> |
| In reply to | #110958 |
"James R. Kuyper" <jameskuyper@verizon.net> writes: >On 05/30/2017 01:20 PM, joel.rees@gmail.com wrote: >> It hasn't been so long since your typical C run-time did the same thing, >> by the way. ;| > >I know - and I've always hated that fact. It's been decades since I had >any need to know such details (my code is explicitly prohibited from >depending upon the details of how any particular compiler works), so >I've no idea whether or not that approach is still commonplace. Not on 64-bit architectures: $ cat /proc/25788/maps 00400000-00550000 r-xp 00000000 08:02 1184980 /usr/bin/xpdf 0074f000-00750000 r--p 0014f000 08:02 1184980 /usr/bin/xpdf 00750000-00784000 rw-p 00150000 08:02 1184980 /usr/bin/xpdf 00983000-009af000 rw-p 00183000 08:02 1184980 /usr/bin/xpdf 022af000-042ae000 rw-p 00000000 00:00 0 [heap] ... 7f1787f74000-7f1787f80000 r--p 00000000 00:23 7195080 /tmp/jUqEqE (deleted) 7f1787f80000-7f1787f83000 rw-p 00000000 00:00 0 7ffefc942000-7ffefc963000 rw-p 00000000 00:00 0 [stack] 7ffefc9e0000-7ffefc9e2000 r--p 00000000 00:00 0 [vvar] 7ffefc9e2000-7ffefc9e4000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-30 12:07 -0700 |
| Message-ID | <6d4cc640-1d12-4281-b519-4288e19cf241@googlegroups.com> |
| In reply to | #110957 |
On Tuesday, May 30, 2017 at 12:20:24 PM UTC-5, joel...@gmail.com wrote: > And if a compiler could track that fact out in its analysis of the code, > it would be free, I think, to lop the error handling branch off of that > bit of code you went to the trouble of writing. Seemingly-redundant checks are often a form of layered security. If executable code from a compiler will be used exclusively to process data which is known *not* to contain maliciously-crafted content, such behavior may be reasonable. On the other hand, consider three programs: 1. A picture viewer which outputs a useful message when given an invalid file. 2. A picture viewer which is 20% faster than #1 when given a good file, and is guaranteed not to do anything other than one of the following when given an invalid file: a. Show a useful message b. Show an arbitrary bunch of pixels. c. Abnormally terminate (perhaps with core dump) d. Hang, consuming all CPU time allocated to it. 3. A picture viewer which is 50% faster than #2, but which, when given a maliciously-crafted "picture" file, will execute whatever code the creator of that file saw fit to include. In the absence of aggressive optimizations, many programs could uphold the requirements for #2 above with relatively little error checking. If a user's needs would be met by #2 but not #3, an aggressive optimizer would increase the amount of error checking required to avoid behavior #3, thus making it necessary to use code that runs more slowly than would be necessary with a less aggressive optimizer.
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-30 20:15 -0700 |
| Message-ID | <ed99a017-8f0b-48fb-a3c8-e7656840327e@googlegroups.com> |
| In reply to | #110957 |
For what it's worth, I moved the tests around so that all allocations are preceded by math which compares the allocation size with the available calculated by the difference between the current and the limit. In the process, I noted that I had left notes to myself about the implicit race condition of checking after allocating, which I think is the more general problem. Also, I decided to remove some fancy code for optimized double integer handling while I was at it. Bwtween fixing the two bugs, the Forth interpreter has become much more stable. It has at least partially returned to its former, less buggy state. Thank you again, Keith and James and others who have commented. I'll try to follow up on any important threads in the conversation I've left dangling once I get my calendar for a fictional world to print. -- Joel Rees Delusions of being a novelist: http://joel-rees-economics.blogspot.jp/2017/01/soc500-00-00-toc.html
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-06-03 11:01 +0000 |
| Message-ID | <59329647.2517984@news.xs4all.nl> |
| In reply to | #110852 |
joel.rees@gmail.com wrote:
> void ALLOT(void)
> { /* We don't have ROM in the high half of memory,
> // so testing the high bit (sign) of DP would be wrong.
> // Or would it? Trying to allocate negative, or more than 2 G?
> // That should be picked up in HERERR, anyway,
> // but does it make sense to check separately here for real nonsense?
> */
> UP.task->dictionaryAllocationPointer.bytep += ( * SP++ ).integer;
> HERERR;
> }
> ----------------------------
>
> I guess those global variables are not under the same requirement of
> test-before-access as parameters are.
You guess wrong.
> Otherwise, my entire interpreter might as well be lopped.
You guess wrong again.
Code can only be lopped if it can be _proven_ that it either has UB or
is not executed. If it can only be proven that it _might_ have UB if
called wrong, but could have real, defined behaviour if called
correctly, then it cannot be removed.
Since you haven't provided any context, we can't tell whether the above
code could be used correctly, or is always superfluous. But it will only
be cut if it definitively is superfluous (non-executing or UB), not if
it could be under some circumstances but not under others.
Richard
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-29 11:25 +0200 |
| Message-ID | <20170529112538.5f0b3e70b6bbe526441c3045@gmail.com> |
| In reply to | #110850 |
On Mon, 29 May 2017 03:58:44 -0400 James Kuyper <jameskuyper@verizon.net> wrote: > No. But it's a relatively small amount of money for anyone sufficiently > competent to contribute, while being large enough to discourage many > people who aren't. Those fees aren't being collected for the purpose of > providing such filtering, that's just a side-effect. They're being > collected because this activity is so poorly funded that part of the > funding needed to cover the costs of the process has to come from the > volunteers. The power of the wallet => the power of the brain. How many decades have you spared your money to convince yourself you're a smart guy? You're pathetic! Money won't follow you in hell...
[toc] | [prev] | [next] | [standalone]
Page 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web