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 8 of 13 — ← Prev page 1 … 6 7 [8] 9 10 … 13 Next page →
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-28 05:24 -0700 |
| Message-ID | <17e06319-4121-4c1c-8ec5-21652c2e8395@googlegroups.com> |
| In reply to | #110796 |
On Sunday, May 28, 2017 at 3:39:17 AM UTC+9, Keith Thompson wrote:
> joel.rees@outerlimbo writes:
> > [...]
> [...]
>
> > For example, many embedded compilers have a switch, pragma, or qualifier
> > that allows the programmer to tell the compiler that structs should be
> > compiled as literal maps instead of as suggestions. That is not currently
> > addressed by the Standard, is it?
>
> I don't know what you mean by "literal maps".
>
> [...]
I don't have the manual handy but I've seen this kind of pragma, allowing
this kind of struct:
#pragma PACKED
#pragma MSB1ST
typedef struct arbf_s {
unsigned sign: 1;
unsigned length: 7;
unsigned exponent: 8;
unsigned firstword: 16;
unsigned int16 extension[];
} arbitrary_fraction;
And I forget how the pragma is reverted.
Without such switches, you would end up with something like these:
typedef char arbitrary_fraction[];
#define ARBF_SIGN( p ) ( (p)[ 0 ] & 0x80 )
#define ARBF_LENGTH( p ) ( (p)[ 0 ] & 0x7f )
#define ARBF_EXPONENT( p ) ( (p)[ 1 ] )
#define ARBF_MAGNITUDE_PTR( p ) ( (p) + 2 )
#define ARBF_MAGNITUDE_CELL( p ) ( (p)[ 0 ] * 0x100 + (p)[ 1 ] )
#define ARBF_MAGNITUDE_NEXT( p ) ( (p) + 2 )
except, of course, that that is a little too simplistic, and I,
personally, would probably not try to use macros to access the value
of the magnitude field.
--
Joel Rees
Random ranting:
http://reiisi.blogspot.com
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-28 13:51 -0700 |
| Message-ID | <lnlgpgso0j.fsf@kst-u.example.com> |
| In reply to | #110818 |
joel.rees@gmail.com writes:
> On Sunday, May 28, 2017 at 3:39:17 AM UTC+9, Keith Thompson wrote:
>> joel.rees@outerlimbo writes:
>> > [...]
>> [...]
>>
>> > For example, many embedded compilers have a switch, pragma, or qualifier
>> > that allows the programmer to tell the compiler that structs should be
>> > compiled as literal maps instead of as suggestions. That is not currently
>> > addressed by the Standard, is it?
>>
>> I don't know what you mean by "literal maps".
>>
>> [...]
>
> I don't have the manual handy but I've seen this kind of pragma, allowing
> this kind of struct:
>
> #pragma PACKED
> #pragma MSB1ST
> typedef struct arbf_s {
> unsigned sign: 1;
> unsigned length: 7;
[snip]
> } arbitrary_fraction;
Ah, so you were talking about a mechanism to specify the layout of a
struct in more detail than C supports.
Many compilers do support something like `#pragma pack` -- but note that
it can be unsafe if you're not careful. If it causes a member to be
misaligned, then the compiler can generate whatever code is necessary to
access the member if you refer to it by name, but if you refer to it via
a pointer it can blow up in your face.
https://stackoverflow.com/q/8568432/827263
https://stackoverflow.com/a/8568441/827263
(I'll note that Ada permits much more detailed specification of
layouts, though I don't think it lets you specify endianness.)
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-28 15:12 -0700 |
| Message-ID | <457f0056-87a6-42fd-b3d8-c205a4f2534d@googlegroups.com> |
| In reply to | #110830 |
On Sunday, May 28, 2017 at 3:52:04 PM UTC-5, Keith Thompson wrote:
> Many compilers do support something like `#pragma pack` -- but note that
> it can be unsafe if you're not careful. If it causes a member to be
> misaligned, then the compiler can generate whatever code is necessary to
> access the member if you refer to it by name, but if you refer to it via
> a pointer it can blow up in your face.
The Keil-ARM compiler allows its "__packed" attribute to be applied to
pointers' target types. Given:
struct __packed {
uint8_t x;
uint32_t y;
} foo;
uint32_t __packed *p = &foo.y;
the pointer "p" may be used to access foo.y without problem even on
machines that only support aligned accesses, since the compiler will
process all accesses to "p" using multiple smaller loads or stores
when required. I find it weird that gcc doesn't seem to support such
a concept, since it would seem like it should be obviously useful and
not particularly difficult.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-28 15:43 -0700 |
| Message-ID | <lnh904siuw.fsf@kst-u.example.com> |
| In reply to | #110835 |
supercat@casperkitty.com writes:
> On Sunday, May 28, 2017 at 3:52:04 PM UTC-5, Keith Thompson wrote:
>> Many compilers do support something like `#pragma pack` -- but note that
>> it can be unsafe if you're not careful. If it causes a member to be
>> misaligned, then the compiler can generate whatever code is necessary to
>> access the member if you refer to it by name, but if you refer to it via
>> a pointer it can blow up in your face.
>
> The Keil-ARM compiler allows its "__packed" attribute to be applied to
> pointers' target types. Given:
>
> struct __packed {
> uint8_t x;
> uint32_t y;
> } foo;
> uint32_t __packed *p = &foo.y;
>
> the pointer "p" may be used to access foo.y without problem even on
> machines that only support aligned accesses, since the compiler will
> process all accesses to "p" using multiple smaller loads or stores
> when required. I find it weird that gcc doesn't seem to support such
> a concept, since it would seem like it should be obviously useful and
> not particularly difficult.
Does Keil-ARM permit the address of a misaligned member to be stored in
a non-__packed pointer?
For example, given the above:
uint32_t *p = &foo.y;
*p = 42;
would result in a misaligned access. Does Keil-ARM permit the
assignment?
A note to anyone who wants to try this on their own system: x86 and
x86_64 handle misaligned accesses in hardware (or microcode, or
whatever).
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-29 15:52 -0700 |
| Message-ID | <1646f5b3-b1bc-488d-a368-2d5e3ecdb5d6@googlegroups.com> |
| In reply to | #110837 |
On Sunday, May 28, 2017 at 5:43:26 PM UTC-5, Keith Thompson wrote:
> supercat writes:
> > The Keil-ARM compiler allows its "__packed" attribute to be applied to
> > pointers' target types. Given:
> >
> > struct __packed {
> > uint8_t x;
> > uint32_t y;
> > } foo;
> > uint32_t __packed *p = &foo.y;
> >
> > the pointer "p" may be used to access foo.y without problem even on
> > machines that only support aligned accesses, since the compiler will
> > process all accesses to "p" using multiple smaller loads or stores
> > when required. I find it weird that gcc doesn't seem to support such
> > a concept, since it would seem like it should be obviously useful and
> > not particularly difficult.
>
> Does Keil-ARM permit the address of a misaligned member to be stored in
> a non-__packed pointer?
I don't have it handy at the moment, but my recollection is that __packed
is treated as a qualifier somewhat like "const", so applying the address-of
operator to a __packed member yields a __packed pointer, and assignment of
a __packed-qualified pointer to a non-__packed-qualified pointer yields a
non-fatal diagnostic.
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-28 17:51 -0700 |
| Message-ID | <ce109875-ab88-491b-9a68-1535d0459483@googlegroups.com> |
| In reply to | #110830 |
On Monday, May 29, 2017 at 5:52:04 AM UTC+9, Keith Thompson wrote:
> joel.rees@outerlimbo writes:
> > On Sunday, May 28, 2017 at 3:39:17 AM UTC+9, Keith Thompson wrote:
> >> joel.rees@outerlimbo writes:
> >> > [...]
> >> [...]
> >>
> >> > For example, many embedded compilers have a switch, pragma, or qualifier
> >> > that allows the programmer to tell the compiler that structs should be
> >> > compiled as literal maps instead of as suggestions. That is not currently
> >> > addressed by the Standard, is it?
> >>
> >> I don't know what you mean by "literal maps".
> >>
> >> [...]
> >
> > I don't have the manual handy but I've seen this kind of pragma, allowing
> > this kind of struct:
> >
> > #pragma PACKED
> > #pragma MSB1ST
> > typedef struct arbf_s {
> > unsigned sign: 1;
> > unsigned length: 7;
> [snip]
> > } arbitrary_fraction;
>
> Ah, so you were talking about a mechanism to specify the layout of a
> struct in more detail than C supports.
>
> Many compilers do support something like `#pragma pack` -- but note that
> it can be unsafe if you're not careful. If it causes a member to be
> misaligned, then the compiler can generate whatever code is necessary to
> access the member if you refer to it by name, but if you refer to it via
> a pointer it can blow up in your face.
>
> https://stackoverflow.com/q/8568432/827263
> https://stackoverflow.com/a/8568441/827263
>
> (I'll note that Ada permits much more detailed specification of
> layouts, though I don't think it lets you specify endianness.)
Wow.
That kind of thing brings out my Tourette's.
Apologies for having extreme reactions to this, but I do.
I'd had the idea that I'd seen a pragma for this in the gcc docs, but
when I'm reading them at two in the morning, I sometimes can't tell if
I dreamed something or actually saw it.
But I had probably missed the fine print where it said that gcc reserved
the right to refrain from generating the appropriate code to safely load
the misaligned members. Or maybe I just assumed I was having a nightmare.
That is a specification bug, and just plain bad engineering. Optimization
for speed or size cannot take precedence over a safe access when the safe
access is known, even if static allocation would allow fudging the
thing to allow the optimization.
And, for the sake of whatever angels or deities or physical principles
you invoke, if you can fudge the entire struct on static allocation,
why can't you also shoe-horn enough code in to access it safely on
non-static?
And why isn't a programmer who can't figure out how to do that today
allowed to revisit the code next week with a slightly different
perspective, before shipping the code?
Who are they competing with? Who is cracking the whip here that pushes
them to do this kind of thing?
Voluntarism is not an excuse here. People who voluntarily make unsafe
bicycles for the poor should be avoided, or at least be discouraged
from doing so.
--
Joel Rees
Trying to re-invent the industry all by myself:
http://defining-computers.blogspot.jp/
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-28 20:45 -0700 |
| Message-ID | <lna85ws4ui.fsf@kst-u.example.com> |
| In reply to | #110842 |
joel.rees@gmail.com writes:
> On Monday, May 29, 2017 at 5:52:04 AM UTC+9, Keith Thompson wrote:
[...]
>> Many compilers do support something like `#pragma pack` -- but note that
>> it can be unsafe if you're not careful. If it causes a member to be
>> misaligned, then the compiler can generate whatever code is necessary to
>> access the member if you refer to it by name, but if you refer to it via
>> a pointer it can blow up in your face.
>>
>> https://stackoverflow.com/q/8568432/827263
>> https://stackoverflow.com/a/8568441/827263
>>
>> (I'll note that Ada permits much more detailed specification of
>> layouts, though I don't think it lets you specify endianness.)
>
> Wow.
>
> That kind of thing brings out my Tourette's.
>
> Apologies for having extreme reactions to this, but I do.
[...]
> And, for the sake of whatever angels or deities or physical principles
> you invoke, if you can fudge the entire struct on static allocation,
> why can't you also shoe-horn enough code in to access it safely on
> non-static?
It has nothing to do with static vs. non-static allocation.
#pragma pack makes it possible for a struct member to violate its normal
alignment requirements. If you take that member's address and store it
in a pointer object, that information is lost. A fix would require
forbidding, or at least restricting, the ability to take the address of
an unaligned member.
> And why isn't a programmer who can't figure out how to do that today
> allowed to revisit the code next week with a slightly different
> perspective, before shipping the code?
>
> Who are they competing with? Who is cracking the whip here that pushes
> them to do this kind of thing?
>
> Voluntarism is not an excuse here. People who voluntarily make unsafe
> bicycles for the poor should be avoided, or at least be discouraged
> from doing so.
You are vastly overreacting. It's a bug, which I've reported:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
If you're going to have the same reaction to each of the 51627
bugs reported before that, or however many were reported after,
you're going to have a very difficult time.
--
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 | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-29 01:11 -0700 |
| Message-ID | <37d7b2d8-e689-4dc2-aacf-701cc6608e5d@googlegroups.com> |
| In reply to | #110844 |
On Monday, May 29, 2017 at 12:46:05 PM UTC+9, Keith Thompson wrote:
> joel.rees@someplace writes:
> > On Monday, May 29, 2017 at 5:52:04 AM UTC+9, Keith Thompson wrote:
> [...]
> >> Many compilers do support something like `#pragma pack` -- but note that
> >> it can be unsafe if you're not careful. If it causes a member to be
> >> misaligned, then the compiler can generate whatever code is necessary to
> >> access the member if you refer to it by name, but if you refer to it via
> >> a pointer it can blow up in your face.
> >>
> >> https://stackoverflow.com/q/8568432/827263
> >> https://stackoverflow.com/a/8568441/827263
> >>
> >> (I'll note that Ada permits much more detailed specification of
> >> layouts, though I don't think it lets you specify endianness.)
> >
> > Wow.
> >
> > That kind of thing brings out my Tourette's.
> >
> > Apologies for having extreme reactions to this, but I do.
> [...]
> > And, for the sake of whatever angels or deities or physical principles
> > you invoke, if you can fudge the entire struct on static allocation,
> > why can't you also shoe-horn enough code in to access it safely on
> > non-static?
>
> It has nothing to do with static vs. non-static allocation.
Didn't you say
A program that uses a single struct rather than array doesn't
reliably exhibit the problem, since the compiler can allocate
the struct on an odd address so the x member is properly aligned.
Aren't you talking about static allocation?
> #pragma pack makes it possible for a struct member to violate its normal
> alignment requirements.
Where are those "normal" requirements given? And why are you calling them
"normal"?
Now, I know that it is a common optimization in many processors to
require data of a specific size to be aligned on an address such that it
matches the expected physical width of RAM in storage, thus avoid the
need for the bus controller to catch the access in mid swing, and grab
part of the data from one "row" of bits, so to speak (although "row"
can have other meanings when talking about RAM, so I'd rather use
another term if I could pierce the Japanese overlaying so much of my
vocabulary), and grab part from the next "row".
And I know that, traditionally, the C compilers have insisted on taking
the liberty of seeing that elements of structs are sufficiently padded
that such misaligned accesses don't occur within the struct.
But when you say "packed data", what else could you mean but to tell
the compiler to break that alignment however it has to, to get data
safely in and out of memory?
> If you take that member's address and store it
> in a pointer object, that information is lost.
What information is lost? Does the run time not know what type of data
a pointer points to? If the run time knows the difference between a
char * and a packed struct thing *, surely it should be able to know
that packed struct thing has bit fields and elements and where those
are?
> A fix would require
> forbidding, or at least restricting, the ability to take the address of
> an unaligned member.
Sure. And that reasoning for adding padding to non-packed structs does
have foundation. But that is for non-packed structs.
But if you are going to provide a pragma that allows packing the data,
you have to make sure the compiler can safely get that data in and out
of memory. Otherwise, you should not provide the pragma.
Or maybe you should call it, the "packed_unsafe" pragma or something,
so that it's clear that it can't be depended on to get the data in
and out safely unless the programmer makes sure that he or she never
takes the pointer of a misaligned struct member.
And, if I were writing the compiler, I'd want to potentially generate
a warning if the address of such a misaligned member were taken.
What I think I'd prefer to do is make special misaligned types. That
way the pointer can remember that it can't be accessed like a pointer
to a regular object of that width. Compilers tend to have lots of
their own private types anyway, why not a misaligned int64, etc?
> > And why isn't a programmer who can't figure out how to do that today
> > allowed to revisit the code next week with a slightly different
> > perspective, before shipping the code?
> >
> > Who are they competing with? Who is cracking the whip here that pushes
> > them to do this kind of thing?
> >
> > Voluntarism is not an excuse here. People who voluntarily make unsafe
> > bicycles for the poor should be avoided, or at least be discouraged
> > from doing so.
>
> You are vastly overreacting. It's a bug, which I've reported:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
Yeah, I read that far in the stack exchange post. I didn't check the
bug report itself to see what happened to it. I suppose I should.
Okay, now I have. I see that there was some of what I was thinking
about discussed. But they insist that packed ints should be ints
a packing (mode?) on a linear scale. I don't think that's the solution
I'd want to try to use.
I'd be thinking more in terms of
typedef struct off1_int32_s {
unsigned byte0: 8;
unsigned mid: 16;
signed byte3: 8;
} off1_int32_st;
with a rule for converting to int32 by extracting each field, etc.
I know that some people will claim I'm trying to turn C into C++
or something, but these conversions don't have to be made into
fully generalized object or class, and the don't have to be made
visible at the source level.
> If you're going to have the same reaction to each of the 51627
> bugs reported before that, or however many were reported after,
> you're going to have a very difficult time.
LOL. Laughed because if I didn't laugh I'd be crying.
Yes. I am having a very difficult time, and I'll show you why. Maybe
you'll laugh, too:
----------------------------
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;
}
----------------------------
My interpreter is full of this kind of stuff.
If I apply the same requirements of test-before-access to the variable
UP.task, and to the variable SP, that are applied to parameters, there
isn't a primitive in the interpreter that the optimizer couldn't lop.
And I'm getting somewhat random segfaults that I wasn't getting three
years ago, so I'm wondering which of these is getting lopped.
And the terrible thing is, I had once been considering trying to pass
some of these pointers around between the inner interpreter and the
primitives as C parameters. I gave that up in the hopes that some
compilers would refrain from generating a stack frame for functions
with neither parameters nor variables. If I had used C parameters,
this interpreter would be dead in the waters these last how many
years?
Somehow, if the compiler is going to be lopping stuff it thinks might
have issues, we have to be able to tell the compiler which variable it
can trust. Or just take pointers out of C altogether.
--
Joel Rees
Trying to re-invent the industry all by myself:
http://defining-computers.blogspot.jp/
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-05-29 05:24 -0400 |
| Message-ID | <oggp5s$j0k$1@dont-email.me> |
| In reply to | #110851 |
On 05/29/2017 04:11 AM, joel.rees@gmail.com wrote: > On Monday, May 29, 2017 at 12:46:05 PM UTC+9, Keith Thompson wrote: >> joel.rees@someplace writes: >>> On Monday, May 29, 2017 at 5:52:04 AM UTC+9, Keith Thompson wrote: ... >> It has nothing to do with static vs. non-static allocation. > > Didn't you say > > A program that uses a single struct rather than array doesn't > reliably exhibit the problem, since the compiler can allocate > the struct on an odd address so the x member is properly aligned. > > Aren't you talking about static allocation? No. What made you think that he was? His comment applies equally well to objects with thread or automatic storage duration. >> #pragma pack makes it possible for a struct member to violate its normal >> alignment requirements. > > Where are those "normal" requirements given? The implemenation's documentation. You can determine them at runtime in C2011 using _Alignof(). > ... And why are you calling them > "normal"? To distinguish them from the more relaxed alignment requirement that must be used to allow the fields to be packed into a struct without padding. > Now, I know that it is a common optimization in many processors to > require data of a specific size to be aligned on an address such that it It's usually the type of the data, rather than the size. And while there exist platforms in which this is merely an optimization, there are platforms where it's a hard requirement: data that's not correctly aligned must be copied into a location where it has correct alignment before it can be loaded into a register of an appropriate type. > And I know that, traditionally, the C compilers have insisted on taking > the liberty of seeing that elements of structs are sufficiently padded > that such misaligned accesses don't occur within the struct. > > But when you say "packed data", what else could you mean but to tell > the compiler to break that alignment however it has to, to get data > safely in and out of memory? On systems with hard alignment requirements, it's commonplace that packed data can only be read and written directly to the struct using the actual member names, it cannot be done using a pointer to the appropriate member, because the code that gets generated when using a pointer knowns nothing about the fact that the pointer points to a member of a packed struct. >> If you take that member's address and store it >> in a pointer object, that information is lost. > > What information is lost? The fact that it refers to a misaligned object. On systems with hard alignment requirements, it's not possible to create a usable pointer to misaligned data. > Does the run time not know what type of data > a pointer points to? Yes. > If the run time knows the difference between a > char * and a packed struct thing *, It doesn't. It can't. The relevant pointer objects are incapable of storing that information. > ... surely it should be able to know > that packed struct thing has bit fields and elements and where those > are? The pointer object contains none of that information. It only knows that it points at a correctly aligned object of the appropriate type, and therefore causes problems when the object is, in fact, misaligned. ... > But if you are going to provide a pragma that allows packing the data, > you have to make sure the compiler can safely get that data in and out > of memory. It can - but the methods that can be used for that purpose are more restricted than they are for structures that contain only aligned data. > Or maybe you should call it, the "packed_unsafe" pragma or something, That would only be reasonable to do on platforms where "packed_safe" is implementable. You probably aren't familiar with any platforms where that would be difficult to do - but the C committee is. Personally, I know nothing about any such platforms - my code is explicitly prohibited from making use of compiler-specific features, so I've never used "packed". In appropriate contexts, I use mask and shift operations on arrays of unsigned char, rather than defining packed structs with bit fields.
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-29 06:02 -0700 |
| Message-ID | <a029db89-6c84-4e16-9116-8864cc6bf339@googlegroups.com> |
| In reply to | #110853 |
On Monday, May 29, 2017 at 6:24:38 PM UTC+9, James Kuyper wrote: > On 05/29/2017 04:11 AM, joel.rees@somewhere wrote: > > On Monday, May 29, 2017 at 12:46:05 PM UTC+9, Keith Thompson wrote: > >> joel.rees@someplace writes: > >>> On Monday, May 29, 2017 at 5:52:04 AM UTC+9, Keith Thompson wrote: > ... > >> It has nothing to do with static vs. non-static allocation. > > > > Didn't you say > > > > A program that uses a single struct rather than array doesn't > > reliably exhibit the problem, since the compiler can allocate > > the struct on an odd address so the x member is properly aligned. > > > > Aren't you talking about static allocation? > > No. What made you think that he was? His comment applies equally well to > objects with thread or automatic storage duration. Well, okay, then how about malloc()? Except that is the programmer's responsibility, of course, and the oddity of the offset struct to align the dangerous member is not the only problem, as you point out. > >> #pragma pack makes it possible for a struct member to violate its normal > >> alignment requirements. > > > > Where are those "normal" requirements given? > > The implemenation's documentation. You can determine them at runtime in > C2011 using _Alignof(). > > > ... And why are you calling them > > "normal"? > > To distinguish them from the more relaxed alignment requirement that > must be used to allow the fields to be packed into a struct without padding. Which are determined by the CPU and maybe RAM controller. > > Now, I know that it is a common optimization in many processors to > > require data of a specific size to be aligned on an address such that it > > It's usually the type of the data, rather than the size. Type and size, depending on the CPU. The 68000 had word alignment restrictions relative to the address registers and byte alignment for data registers, IIRC -- word meaning sixteen bit. > And while there > exist platforms in which this is merely an optimization, there are > platforms where it's a hard requirement: data that's not correctly > aligned must be copied into a location where it has correct alignment > before it can be loaded into a register of an appropriate type. In the case of the 68000, you would generally assembler the byte aligned pointer into a free data register and move it to the appropriate address register. You could also assemble it to the stack or some other handy place in memory if no data registers were free, because the 68000 supported memory-to-memory moves. I don't remember whether the 68020 relaxed the restriction, but I'm pretty sure it didn't widen it. IIRC, the 88000 had alignment restrictions for all registers, depending on the size of data being loaded. SH-3 has restrictions on all registers based on size of data. I recall that some processors simply load and store data of the width of the register. If you need a byte located somewhere in the field being loaded, you have to load the whole field aligned to the register size and then shift and mask to get the byte. Etc. > > And I know that, traditionally, the C compilers have insisted on taking > > the liberty of seeing that elements of structs are sufficiently padded > > that such misaligned accesses don't occur within the struct. > > > > But when you say "packed data", what else could you mean but to tell > > the compiler to break that alignment however it has to, to get data > > safely in and out of memory? > > On systems with hard alignment requirements, it's commonplace that > packed data can only be read and written directly to the struct using > the actual member names, it cannot be done using a pointer to the > appropriate member, because the code that gets generated when using a > pointer knowns nothing about the fact that the pointer points to a > member of a packed struct. Which seems bizarre to me. If the compiler can generate the code to load a char, it can generate the code to load a wider word, misaligned. It's just a matter of taking the extra instructions, and maybe/probably register to do it. > >> If you take that member's address and store it > >> in a pointer object, that information is lost. > > > > What information is lost? > > The fact that it refers to a misaligned object. On systems with hard > alignment requirements, it's not possible to create a usable pointer to > misaligned data. On a system that addresses 36 bit bytes, yeah, it's hard enough to track the location of a byte that you generally don't. But in that case, char is probably going to be 36 bits, the same size as short and int. Maybe such a system has alignment requirements for 72 bit words, but it returns to the problem of, if the address is odd, generating the appropriate instructions to get it into the 72-bit register. If the compiler can generate those instructions for a struct on the stack, on the thread heap, or on the program heap, it can generate those instructions relative to the struct wherever the struct is. Even in a case where the struct itself is offset to align the field with the alignment requirements, the compiler has to be able to generate instructions to access the other fields. I noted that the discussion of the bug indicated that there was, indeed, some alignment requirement property associated with the pointer, by a kind of augmented type record for the pointer. If they can do that much, it's not far-fetched to think they can augment the type with the specifics of the misalignment. Hiding that from the application programmer may be difficult, but it should be possible. > > Does the run time not know what type of data > > a pointer points to? > > Yes. > > > If the run time knows the difference between a > > char * and a packed struct thing *, > > It doesn't. It can't. The relevant pointer objects are incapable of > storing that information. Back up and read that again, please? char vs. member of packed struct? char vs. int, of course. I'm suggesting that int can be given possibly hidden additional properties that indicate it is misaligned. > > ... surely it should be able to know > > that packed struct thing has bit fields and elements and where those > > are? > > The pointer object contains none of that information. It only knows that > it points at a correctly aligned object of the appropriate type, If it can know whether the pointer is correctly aligned, we should be able to make it know it may not be correctly aligned. If it's a pointer to a signed character at some arbitrary location in memory, the compiler should be able to generate the necessary instructions, which, for some hardware, may not be a simple single load. If it's a pointer to an unsigned short int at some arbitrary location in memory, the compiler should be able to generate the necessary instructions, which, for some hardware, may not be a simple single load. If, as an assembly language programmer, I'm going to load 32 bits of aligned data, I write a certain instruction (or two). If, as an assembly language programmer, I'm going to load 32 bits of known misaligned data, I write a certain sequence of instructions, according to what I know about the misalignment. If, as an assembly language programmer, I'm going to load 32 bits of data from an arbitrary location and I don't know whether the pointer will be aligned or not, I generate a call to a subroutine or maybe a macro. Maybe the subroutine/macro looks at the bottom bit or two or three and figures out an appropriate sequence of loads. Maybe it just assembles a sequence of four bytes from memory in one register and moves it to the target register. A compiler can do the same thing, if we make sure it knows that a particular pointer might be misaligned. > and > therefore causes problems when the object is, in fact, misaligned. only if the compiler writers refuse to let the compiler remember, along with the type of data the pointer references, whether the pointer is known to be aligned or not known. > ... > > But if you are going to provide a pragma that allows packing the data, > > you have to make sure the compiler can safely get that data in and out > > of memory. > > It can - but the methods that can be used for that purpose are more > restricted than they are for structures that contain only aligned data. Sure. As I described above. It would be nice if the standard could address that, but I would be, that is, that is, I am definitely disappointed to find out gcc has the pragma but insists that the programmer still refrain from expecting it to be more useful than replacing the series of shifts and masks that the programmer would otherwise have to write. > > Or maybe you should call it, the "packed_unsafe" pragma or something, > > That would only be reasonable to do on platforms where "packed_safe" is > implementable. You probably aren't familiar with any platforms where > that would be difficult to do - but the C committee is. Well, C committee aside, the conversation on that bug you linked to shows that gcc has attributes in the compiler's record of the pointer, but there seems to be something preventing them using it. And it has been that way for a "long time". Or are we talking about something more difficult than the 68000 or the SH-3? > Personally, I > know nothing about any such platforms - my code is explicitly prohibited > from making use of compiler-specific features, so I've never used > "packed". In appropriate contexts, I use mask and shift operations on > arrays of unsigned char, rather than defining packed structs with bit > fields. As do I when I write portable code, although I probably don't write as much as you do. I've played with using the structs, and, what with the byte ordering and the padding, and the non-standard packing, it just doesn't seem worthwhile to push the standard syntax of the struct. And I said I was going to get back to work. -- Joel Rees Randomly ranting: http://reiisi.blogspot.com
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-29 17:13 -0700 |
| Message-ID | <lny3tfqk05.fsf@kst-u.example.com> |
| In reply to | #110870 |
joel.rees@gmail.com writes:
> On Monday, May 29, 2017 at 6:24:38 PM UTC+9, James Kuyper wrote:
>> On 05/29/2017 04:11 AM, joel.rees@somewhere wrote:
>> > On Monday, May 29, 2017 at 12:46:05 PM UTC+9, Keith Thompson wrote:
>> >> joel.rees@someplace writes:
>> >>> On Monday, May 29, 2017 at 5:52:04 AM UTC+9, Keith Thompson wrote:
>> ...
>> >> It has nothing to do with static vs. non-static allocation.
>> >
>> > Didn't you say
>> >
>> > A program that uses a single struct rather than array doesn't
>> > reliably exhibit the problem, since the compiler can allocate
>> > the struct on an odd address so the x member is properly aligned.
>> >
>> > Aren't you talking about static allocation?
>>
>> No. What made you think that he was? His comment applies equally well to
>> objects with thread or automatic storage duration.
>
> Well, okay, then how about malloc()? Except that is the programmer's
> responsibility, of course, and the oddity of the offset struct to
> align the dangerous member is not the only problem, as you point out.
As I said in another response, the way the struct is allocated is
irrelevant to the point I was making.
[...]
> Which seems bizarre to me. If the compiler can generate the code to
> load a char, it can generate the code to load a wider word, misaligned.
> It's just a matter of taking the extra instructions, and maybe/probably
> register to do it.
The problem is that the compiler doesn't know when it needs to generate
those extra instructions.
[...]
> On a system that addresses 36 bit bytes, yeah, it's hard enough to track
> the location of a byte that you generally don't.
I have no idea why you've brought 36 bit bytes into this.
Here's an annotated example of the problem. I *think* you understand
this, but some of what you've written seems to imply that you don't.
#include <stdio.h>
void show(int *p0, int *p1) {
/*
* This function doesn't now about the packed struct. It knows
* only that it's been given pointers to ints, and it assumes
* that they're's properly aligned. Handling misaligned int
* objects would require generating slower code for *all*
* accesses via int* pointers.
*/
printf("show: *p0 = %d, *p1 = %d\n", *p0, *p1);
}
struct __attribute__ ((__packed__)) packed_struct {
int n0;
char c;
int n1;
};
int main(void) {
struct packed_struct ps = { 100, 'x', 200 };
/*
* No problem, compiler generates code to access the misaligned
* member.
*/
printf("main: ps.n0 = %d, ps.n1 = %d\n", ps.n0, ps.n1);
/* Here's the problem. */
{
int *ptr0 = &ps.n0;
int *ptr1 = &ps.n1;
show(ptr0, ptr1);
}
return 0;
}
Note that the show() function could be in another translation unit, so
there's no way it could know about the possibility that its argument
might be a pointer to a misaligned int object. More precisely, there's
no way the compiler could know that when compiling the show() function.
Generating code that allows for that possibility would slow down
everything.
There could be ways to avoid that, for example by restricting attempts
to take the address of a misaligned member and/or by annotating the
pointer type used to access it. Such solutions have not been
implemented in gcc.
On an x86_64 system, the above program's output is:
main: ps.n0 = 100, ps.n1 = 200
show: *p0 = 100, *p1 = 200
because the CPU handles misaligned accesses. On a SPARC system, the
output is:
main: ps.n0 = 100, ps.n1 = 200
followed by a bus error.
--
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 | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-29 19:26 -0700 |
| Message-ID | <816686b1-04db-4580-8695-9861b1036027@googlegroups.com> |
| In reply to | #110912 |
On Tuesday, May 30, 2017 at 9:13:53 AM UTC+9, Keith Thompson wrote:
> joel.rees@dokodemo writes:
> > On Monday, May 29, 2017 at 6:24:38 PM UTC+9, James Kuyper wrote:
> >> On 05/29/2017 04:11 AM, joel.rees@somewhere wrote:
> >> > On Monday, May 29, 2017 at 12:46:05 PM UTC+9, Keith Thompson wrote:
> >> >> joel.rees@someplace writes:
> >> >>> On Monday, May 29, 2017 at 5:52:04 AM UTC+9, Keith Thompson wrote:
> >> ...
> >> >> It has nothing to do with static vs. non-static allocation.
> >> >
> >> > Didn't you say
> >> >
> >> > A program that uses a single struct rather than array doesn't
> >> > reliably exhibit the problem, since the compiler can allocate
> >> > the struct on an odd address so the x member is properly aligned.
> >> >
> >> > Aren't you talking about static allocation?
> >>
> >> No. What made you think that he was? His comment applies equally well to
> >> objects with thread or automatic storage duration.
> >
> > Well, okay, then how about malloc()? Except that is the programmer's
> > responsibility, of course, and the oddity of the offset struct to
> > align the dangerous member is not the only problem, as you point out.
>
> As I said in another response, the way the struct is allocated is
> irrelevant to the point I was making.
>
> [...]
>
> > Which seems bizarre to me. If the compiler can generate the code to
> > load a char, it can generate the code to load a wider word, misaligned.
> > It's just a matter of taking the extra instructions, and maybe/probably
> > register to do it.
>
> The problem is that the compiler doesn't know when it needs to generate
> those extra instructions.
>
> [...]
>
> > On a system that addresses 36 bit bytes, yeah, it's hard enough to track
> > the location of a byte that you generally don't.
>
> I have no idea why you've brought 36 bit bytes into this.
>
> Here's an annotated example of the problem. I *think* you understand
> this, but some of what you've written seems to imply that you don't.
>
> #include <stdio.h>
>
> void show(int *p0, int *p1) {
> /*
> * This function doesn't now about the packed struct. It knows
> * only that it's been given pointers to ints, and it assumes
> * that they're's properly aligned. Handling misaligned int
> * objects would require generating slower code for *all*
> * accesses via int* pointers.
> */
> printf("show: *p0 = %d, *p1 = %d\n", *p0, *p1);
> }
>
> struct __attribute__ ((__packed__)) packed_struct {
> int n0;
> char c;
> int n1;
> };
>
> int main(void) {
> struct packed_struct ps = { 100, 'x', 200 };
>
> /*
> * No problem, compiler generates code to access the misaligned
> * member.
> */
> printf("main: ps.n0 = %d, ps.n1 = %d\n", ps.n0, ps.n1);
>
> /* Here's the problem. */
> {
> int *ptr0 = &ps.n0;
> int *ptr1 = &ps.n1;
> show(ptr0, ptr1);
> }
> return 0;
> }
>
> Note that the show() function could be in another translation unit,
Until you remind me (again) of this with actual source code in my face,
my mind was dodging it.
And the best we can do is ask the compiler to give us a warning when
storing the pointers to the members.
> so
> there's no way it could know about the possibility that its argument
> might be a pointer to a misaligned int object. More precisely, there's
> no way the compiler could know that when compiling the show() function.
> Generating code that allows for that possibility would slow down
> everything.
>
> There could be ways to avoid that, for example by restricting attempts
> to take the address of a misaligned member and/or by annotating the
> pointer type used to access it. Such solutions have not been
> implemented in gcc.
Lacking the hardware to check it, I could only log into bugzilla and ask
if they have forgotten the bug you filed. I'll see if I can make some
time today before I forget it.
Right now, I'm digging into my Forth interpreter, looking for the clues.
> On an x86_64 system, the above program's output is:
>
> main: ps.n0 = 100, ps.n1 = 200
> show: *p0 = 100, *p1 = 200
>
> because the CPU handles misaligned accesses. On a SPARC system, the
> output is:
>
> main: ps.n0 = 100, ps.n1 = 200
>
> followed by a bus error.
>
> --
> 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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-29 14:19 -0700 |
| Message-ID | <ln37bns6na.fsf@kst-u.example.com> |
| In reply to | #110851 |
joel.rees@gmail.com writes:
> On Monday, May 29, 2017 at 12:46:05 PM UTC+9, Keith Thompson wrote:
[...]
>> It has nothing to do with static vs. non-static allocation.
>
> Didn't you say
>
> A program that uses a single struct rather than array doesn't
> reliably exhibit the problem, since the compiler can allocate
> the struct on an odd address so the x member is properly aligned.
Yes, I did.
> Aren't you talking about static allocation?
No, not at all, and I can't figure out why you think I was. Any object
has to have memory allocated for it in some way, using one of the four
language-defined storage durations (static, thread, automatic, and
allocated; "allocated" in this context refers to malloc() and equivalent
methods). What I wrote applies equally to all of them.
>> #pragma pack makes it possible for a struct member to violate its normal
>> alignment requirements.
>
> Where are those "normal" requirements given? And why are you calling them
> "normal"?
I'm referring to the implementation-defined alignment requirements that
each type has in the absence of any compiler-specific features like
"#pragma pack". You can query it using the _Alignof operator, added in
C11. Was that unclear?
[...]
> But when you say "packed data", what else could you mean but to tell
> the compiler to break that alignment however it has to, to get data
> safely in and out of memory?
Yes, that's what it means.
>> If you take that member's address and store it
>> in a pointer object, that information is lost.
>
> What information is lost?
The information that the object (a misaligned member of a packed struct)
doesn't meet its type's alignment requirement.
> Does the run time not know what type of data
> a pointer points to?
Yes, in the sense that the compiler generates code that relies on that
information.
> If the run time knows the difference between a
> char * and a packed struct thing *, surely it should be able to know
> that packed struct thing has bit fields and elements and where those
> are?
It does, but again, that information is lost when you take the address
of a misaligned member.
Given a structure with a misaligned int member, you can take the address
of that member and, for example, pass it to a function that takes an
int* argument. That function has no way of knowing that the int object
is misaligned. That's the bug.
>> A fix would require
>> forbidding, or at least restricting, the ability to take the address of
>> an unaligned member.
>
> Sure. And that reasoning for adding padding to non-packed structs does
> have foundation. But that is for non-packed structs.
>
> But if you are going to provide a pragma that allows packing the data,
> you have to make sure the compiler can safely get that data in and out
> of memory. Otherwise, you should not provide the pragma.
And that's the bug, which has already been reported to the gcc
developers.
[...]
> And, if I were writing the compiler, I'd want to potentially generate
> a warning if the address of such a misaligned member were taken.
Not a bad idea. Feel free to add a comment to the bug report suggesting
it (if it hasn't been suggested already).
[...]
--
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 | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-29 15:45 -0700 |
| Message-ID | <08b562ba-6423-43f8-bc64-81bd6de35c41@googlegroups.com> |
| In reply to | #110896 |
On Tuesday, May 30, 2017 at 6:19:35 AM UTC+9, Keith Thompson wrote: > joel.rees@dokodemo writes: > > [...] > > > > But if you are going to provide a pragma that allows packing the data, > > you have to make sure the compiler can safely get that data in and out > > of memory. Otherwise, you should not provide the pragma. > > And that's the bug, which has already been reported to the gcc > developers. That's greatly reassuring to hear. > [...] > > > And, if I were writing the compiler, I'd want to potentially generate > > a warning if the address of such a misaligned member were taken. > > Not a bad idea. Feel free to add a comment to the bug report suggesting > it (if it hasn't been suggested already). > > [...] The topic of a warning was in the discussion, but nothing seems to have been done with it since 2015, as near as I could see. I'll look again. -- Joel Rees Randomly ranting: http://reiisi.blogspot.com
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-05-30 07:01 +0100 |
| Message-ID | <87poeqkhmj.fsf@gmail.com> |
| In reply to | #110896 |
Keith Thompson <kst-u@mib.org> writes:
> joel.rees@gmail.com writes:
>> On Monday, May 29, 2017 at 12:46:05 PM UTC+9, Keith Thompson wrote:
> [...]
>>> It has nothing to do with static vs. non-static allocation.
>>
>> Didn't you say
>>
>> A program that uses a single struct rather than array doesn't
>> reliably exhibit the problem, since the compiler can allocate
>> the struct on an odd address so the x member is properly aligned.
>
> Yes, I did.
>
>> Aren't you talking about static allocation?
>
> No, not at all, and I can't figure out why you think I was.
Well, one reason why you may have been is that the compiler has a lot
more freedom in aligning static allocation.
The return value of malloc(1) has more stringent alignment requirements
than the address of a char on the stack.
Theoretically a packed
struct bad_align {
char c;
char *p
}
structure on the stack could be aligned so the pointer access was
correctly alignment.
It seems spectacularly unlikely that a compiler would do this though.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-30 09:31 -0700 |
| Message-ID | <lnk24yqpad.fsf@kst-u.example.com> |
| In reply to | #110922 |
Gareth Owen <gwowen@gmail.com> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> joel.rees@gmail.com writes:
>>> On Monday, May 29, 2017 at 12:46:05 PM UTC+9, Keith Thompson wrote:
>> [...]
>>>> It has nothing to do with static vs. non-static allocation.
>>>
>>> Didn't you say
>>>
>>> A program that uses a single struct rather than array doesn't
>>> reliably exhibit the problem, since the compiler can allocate
>>> the struct on an odd address so the x member is properly aligned.
>>
>> Yes, I did.
>>
>>> Aren't you talking about static allocation?
>>
>> No, not at all, and I can't figure out why you think I was.
>
> Well, one reason why you may have been is that the compiler has a lot
> more freedom in aligning static allocation.
>
> The return value of malloc(1) has more stringent alignment requirements
> than the address of a char on the stack.
>
> Theoretically a packed
>
> struct bad_align {
> char c;
> char *p
> }
>
> structure on the stack could be aligned so the pointer access was
> correctly alignment.
>
> It seems spectacularly unlikely that a compiler would do this though.
In fact, using gcc 4.2.1 on Solaris 9, my test program initially
defined:
struct __attribute__ ((__packed__)) packed_struct {
char c;
int n;
};
but a reference to n didn't trap as I expected. Investigation showed
that the struct object (defined locally, thus on the "stack") was
allocated at an odd address, causing n to be correctly aligned. I had
to change the declaration to:
struct __attribute__ ((__packed__)) packed_struct {
int n0;
char c;
int n1;
};
to demonstrate the problem.
But there's nothing special about static allocation. malloc() return a
maximally aligned pointer, so if I had malloced the struct object I
wouldn't have had to add the second int member to force the trap, but
either static or automatic allocation allows the compiler to allocate at
an odd address if there's an advantage in doing so.
Of course you shouldn't depend on this behavior.
--
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-27 16:22 -0400 |
| Message-ID | <ogcmvg$38u$1@dont-email.me> |
| In reply to | #110787 |
On 05/27/2017 02:46 AM, joel.rees@gmail.com wrote:
> On Friday, May 26, 2017 at 10:05:31 PM UTC+9, David Brown wrote:
>> On 26/05/17 03:44, joel.rees@donde wrote:
...
>>> The gcc compiler team, a while back, decided that code like this
>>>
>>> int * thingp = * parampp;
>>> ...
>>> if ( parampp == NULL ) {
>>> /* fix it */
>>> }
>>>
>>> since it was UB, was justifiably silently lopped -- with everything
>>> that depended on it.
...
>> 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" -
what I mean by the term would certainly not be compiler-dependent. 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. 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.
The code in question has undefined behavior, and has always had
undefined behavior. 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.
...
> When the compiler suddenly starts silently lopping code instead of
> suddenly complaining that the source contains incorrect things, it
> leaves even a good programmer with lots of hubris grasping at straws
> and making up mythologies to explain what appears to be ghosts in the
> machine.
If the standard says that the behavior of code is undefined, rather than
being a constraint violation, then there is no requirement that a
diagnostic be generated. This is inconvenient for the developer, so the
committee generally makes the behavior undefined only if it believes
that mandating a diagnostic would, in some cases, make it excessively
difficult, at least for some compilers, to conform to that requirement.
For the particular rule violated by this code, it could be arbitrarily
difficult for an implementation to determine whether or not the value
stored in a pointer object is currently valid. Cases can be constructed
where determining whether or not it's valid at compile time is
equivalent to solving the halting problem, and it's trivial to make it
impossible to determine until run time.
Good quality implementations should provide warnings in those cases
where they do detect the fact that the behavior might be undefined, but
good programmers shouldn't rely upon getting such warnings.
Keep in mind that just because an optimization appears to take advantage
of the fact that code is undefined doesn't mean that the code which
implements that optimization necessarily has determined that the
behavior is undefined. The developers might simply have noticed that the
code which implements the optimization only causes problems if the
behavior happens to be undefined, and was therefore acceptable.
...
>> They therefore introduced a warning "-Wnull-derefence"
>> to match the optimisation pass. It would have been nicer, perhaps, to
>> have this warning enabled by default whenever the optimisation
>> "-fdelete-null-pointer-checks" is enabled. But that is a lesson learned.
>
> No, it would not have been "nicer". Maybe they didn't realize how much
> the industry depends on the gnu toolchain. Or maybe they had missed
> the human factors part of their engineering training.
>
> Lopping code without warning is more than a little like suddenly
> chopping a leg off all the restaurant tables because three is all
> that is needed and more stable than four (in theory).
Lopping code without warning is what most optimizations do. Do you want
to see a twenty page listing of warnings every time your compiler is
invoked on perfectly correct code with an optimization level higher than
0? Keep in mind that the code which implements this optimization need
not have actually determined that the behavior is undefined, in which
case it would have to give a warning, whether or not the behavior is
undefined.
...
>> The compiler team was entirely correct. That does /not/ mean they were
>> as helpful and "user friendly" as they should have been.
>
> Programmers are not end-users. Helping the programmers is not an example
> of coddling.
Being "user friendly" is not the same as coddling.
..
>> 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).
...
>> 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. I'm perfectly capable of writing
defective code, but if I do, I don't blame the compiler for generating a
defective executable without warning, if the standard does not mandate
providing that warning.
>>> Maybe that's because gcc gave me more than they should have.
>>
>> What?
>
> I have a bad habit of playing devil's advocate against myself sometimes.
>
> Some people might say that gcc shouldn't have allowed my
> misinterpretation of static declaration of flexible arrays to ever
> compile.
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.
If you want to be warned about differences between GnuC and standard C,
you need to tell gcc which version of the standard you want it to
conform to, by using the -std= option. By not using that option, you're
telling it "I'm happy to have my code depend upon GnuC features that
might not be supported by any other compiler in the world". If that's
not what you meant to tell gcc, you should change the way you invoke it.
>>> Or maybe that's because the Standard is too insistent that it must be
>>> The One True Standard.
>>
>> The C standard /is/ the standard for programming in C. That is how this
>> all works.
>
> Can we call it the target standard?
No. It's an actual standard, not a target one.
>> Perhaps they should conform to the one in Supercat's imagination.
>
> If enough programmers seem to find his standard useful, why not have
> a separate standard for that?>
> If supercat or someone is willing and able to fund the committees and
> the conferences, that is.
I'd have no objection to that whatsoever, and absolutely no interest in
making use of any compiler that conforms to the resulting standard.
>> The standard forms a sort of a contract between the programmer and the
>> compiler. If the programmer is not doing his part of the deal, that is
>> /his/ problem. Blame that on the programmer's teacher, or the
>> programmer's choice of language (very often C is simply not a good
>> choice). In some cases, you could blame the standards. The compiler is
>> /not/ at fault for assuming the programmer knows what he is doing, and
>> aiming to produce the most efficient possible object code for correct
>> source code. But it might be at fault for not being as helpful and
>> informative as reasonably possible, and certainly it is always good to
>> get diagnostics when source code has undefined behaviour.
>
> I could go with that metaphor, but a contract cannot be enforced
> unilaterally.
This one isn't enforced at all.
> 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.
>> Those are
>> /all/ tangible results. They are highly motivated towards not breaking
>> existing code - but are willing to make existing /bad/ source code do
>> bad things if that sacrifice is needed to make /correct/ code faster.
>
> Which last is not a focus on safety.
Writing code with undefined behavior was never intended to be a safe
activity, because the standard only selects "undefined behavior" if, in
the committee's opinion, mandating detection of the underlying problem
would impose an excessive burden on at least some compilers in some
cases. Avoiding undefined behavior is the developer's responsibility;
warning the developer about it is not the implementation's
responsibility (though many high-quality implementations do exceed
requirements by warning about many of the more easily detected cases
that have undefined behavior).
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-27 14:41 -0700 |
| Message-ID | <ea649286-4c5a-448c-9c7b-88a4e1623da9@googlegroups.com> |
| In reply to | #110801 |
On Saturday, May 27, 2017 at 3:22:30 PM UTC-5, James Kuyper wrote: > Writing code with undefined behavior was never intended to be a safe > activity, because the standard only selects "undefined behavior" if, in > the committee's opinion, mandating detection of the underlying problem > would impose an excessive burden on at least some compilers in some > cases. It is not intended to be a safe activity on all implementations. That does not imply a judgment that implementations should not process it in a safe and useful fashion when practical. The Standard says that some implementations will process forms of Undefined Behavior in a documented (and presumably) useful fashion characteristic of the environment. Such a description would seem rather odd if there was no intention that use of such behavior would be safe on such implementations. The $50,000 question is how implementations which are intended for any particular platform and application field should decide which, if any, of the indicated ways of processing Undefined Behavior should be used in any given situation. I would suggest that if a platform would define a useful behavior for some action, a quality implementation that is suitable for low-level programming for that platform should either expose such behavioral guarantees to the programmer or document compelling reasons for its failure to do so. Implementations are used for many purposes other than low-level programming, and implementations that make no pretense of being suitable for low-level programming should not feel obligated to expose the same platform features as those that do, but should instead make clear that they will be incompatible with some kinds of low-level code.
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-28 06:53 -0700 |
| Message-ID | <80de5f11-ca3c-474d-9414-a65ef5d4b75b@googlegroups.com> |
| In reply to | #110801 |
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:
> >> On 26/05/17 03:44, joel.rees@donde wrote:
> ...
> >>> The gcc compiler team, a while back, decided that code like this
> >>>
> >>> int * thingp = * parampp;
> >>> ...
> >>> if ( parampp == NULL ) {
> >>> /* fix it */
> >>> }
> >>>
> >>> since it was UB, was justifiably silently lopped -- with everything
> >>> that depended on it.
> ...
> >> 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" -
I'm referring to the old platitude that there every program has bugs
... and hinting broadly at the concept that standards are subject to the
same limitation.
> what I mean by the term would certainly not be compiler-dependent.
Surely you do not mean to say that correct code is code that has not
been compiled?
> 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.
> 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.
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.
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.
> 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,
... 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.
> ...
> > When the compiler suddenly starts silently lopping code instead of
> > suddenly complaining that the source contains incorrect things, it
> > leaves even a good programmer with lots of hubris grasping at straws
> > and making up mythologies to explain what appears to be ghosts in the
> > machine.
>
> If the standard says that the behavior of code is undefined, rather than
> being a constraint violation, then there is no requirement that a
> diagnostic be generated. This is inconvenient for the developer, so the
> committee generally makes the behavior undefined only if it believes
> that mandating a diagnostic would, in some cases, make it excessively
> difficult, at least for some compilers, to conform to that requirement.
> For the particular rule violated by this code, it could be arbitrarily
> difficult for an implementation to determine whether or not the value
> stored in a pointer object is currently valid. Cases can be constructed
> where determining whether or not it's valid at compile time is
> equivalent to solving the halting problem, and it's trivial to make it
> impossible to determine until run time.
>
> Good quality implementations should provide warnings in those cases
> where they do detect the fact that the behavior might be undefined, but
> good programmers shouldn't rely upon getting such warnings.
>
> Keep in mind that just because an optimization appears to take advantage
> of the fact that code is undefined doesn't mean that the code which
> implements that optimization necessarily has determined that the
> behavior is undefined. The developers might simply have noticed that the
> code which implements the optimization only causes problems if the
> behavior happens to be undefined, and was therefore acceptable.
>
> ...
> >> They therefore introduced a warning "-Wnull-derefence"
> >> to match the optimisation pass. It would have been nicer, perhaps, to
> >> have this warning enabled by default whenever the optimisation
> >> "-fdelete-null-pointer-checks" is enabled. But that is a lesson learned.
> >
> > No, it would not have been "nicer". Maybe they didn't realize how much
> > the industry depends on the gnu toolchain. Or maybe they had missed
> > the human factors part of their engineering training.
> >
> > Lopping code without warning is more than a little like suddenly
> > chopping a leg off all the restaurant tables because three is all
> > that is needed and more stable than four (in theory).
>
> Lopping code without warning is what most optimizations do.
You can look at it that way if you want, and I'm going to say that is
not exactly supposed to be the case, but it really is not at issue.
> Do you want
> to see a twenty page listing of warnings every time your compiler is
> invoked on perfectly correct code with an optimization level higher than
> 0? Keep in mind that the code which implements this optimization need
> not have actually determined that the behavior is undefined, in which
> case it would have to give a warning, whether or not the behavior is
> undefined.
Each level of optimization has its own requirements.
What was compiling yesterday at level three should not suddenly be
lopped silently at level three today.
Mind you, I'm not intending to criticize the coders on the compiler teams.
The records are pretty clear that it was a management error.
> ...
> >> The compiler team was entirely correct. That does /not/ mean they were
> >> as helpful and "user friendly" as they should have been.
> >
> > Programmers are not end-users. Helping the programmers is not an example
> > of coddling.
>
> Being "user friendly" is not the same as coddling.
Being "programmer friendly" is not the same as being "user friendly".
There are guards on band saws, for example, for a reason.
> ..
> >> 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?
They need experience. How do they get experience except by writing code?
> ...
> >> 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.
You know the standard well, and that is good.
I guarantee you there are fields of application that you would be lost
in, notwithstanding that the code is standards conformant C.
I'm sure you wouldn't be lost for long, since you know C, but you would
likely see constructs and idioms that would make you wonder, and require
some discussion with co-workers.
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.
Unless you want to assert that the singularity has already occurred,
we, as an industry, and as a civilization, have hardly scratched the
surface.
> I'm perfectly capable of writing
> defective code, but if I do, I don't blame the compiler for generating a
> defective executable without warning, if the standard does not mandate
> providing that warning.
It should not be necessary for the standard to mandate a warning.
Common sense should apply.
> >>> Maybe that's because gcc gave me more than they should have.
> >>
> >> What?
> >
> > I have a bad habit of playing devil's advocate against myself sometimes.
> >
> > Some people might say that gcc shouldn't have allowed my
> > misinterpretation of static declaration of flexible arrays to ever
> > compile.
>
> 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. No, actually, I just had not had time, while working on
this project after hours, to read far enough in the manuals to discover
that the standard said it did not guarantee that flexible arrays within
structs could be initialized by the same fiat as naked unsized arrays.
You see, I am not currently a C programmer by profession. At the time
I began this could, I was working in Java, perl, php, and something
else.
I'm not saying that it was not my responsibility to understand the
language, just that the realities of life had me writing code in a
language that had evolved a bit since the last time I had written in
it, and the realities of life had me pushing beyond what I had time
and resources for.
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.
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.
> If you want to be warned about differences between GnuC and standard C,
> you need to tell gcc which version of the standard you want it to
> conform to, by using the -std= option. By not using that option, you're
> telling it "I'm happy to have my code depend upon GnuC features that
> might not be supported by any other compiler in the world". If that's
> not what you meant to tell gcc, you should change the way you invoke it.
>
> >>> Or maybe that's because the Standard is too insistent that it must be
> >>> The One True Standard.
> >>
> >> The C standard /is/ the standard for programming in C. That is how this
> >> all works.
> >
> > 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.
> >> Perhaps they should conform to the one in Supercat's imagination.
> >
> > If enough programmers seem to find his standard useful, why not have
> > a separate standard for that?>
> > If supercat or someone is willing and able to fund the committees and
> > the conferences, that is.
>
> I'd have no objection to that whatsoever, and absolutely no interest in
> making use of any compiler that conforms to the resulting standard.
>
> >> The standard forms a sort of a contract between the programmer and the
> >> compiler. If the programmer is not doing his part of the deal, that is
> >> /his/ problem. Blame that on the programmer's teacher, or the
> >> programmer's choice of language (very often C is simply not a good
> >> choice). In some cases, you could blame the standards. The compiler is
> >> /not/ at fault for assuming the programmer knows what he is doing, and
> >> aiming to produce the most efficient possible object code for correct
> >> source code. But it might be at fault for not being as helpful and
> >> informative as reasonably possible, and certainly it is always good to
> >> get diagnostics when source code has undefined behaviour.
> >
> > I could go with that metaphor, but a contract cannot be enforced
> > unilaterally.
>
> This one isn't enforced at all.
Except by the compilers.
> > 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?
Only the elite should have input?
> >> Those are
> >> /all/ tangible results. They are highly motivated towards not breaking
> >> existing code - but are willing to make existing /bad/ source code do
> >> bad things if that sacrifice is needed to make /correct/ code faster.
> >
> > Which last is not a focus on safety.
>
> Writing code with undefined behavior was never intended to be a safe
> activity, because the standard only selects "undefined behavior" if, in
> the committee's opinion, mandating detection of the underlying problem
> would impose an excessive burden on at least some compilers in some
> cases. Avoiding undefined behavior is the developer's responsibility;
> warning the developer about it is not the implementation's
> responsibility (though many high-quality implementations do exceed
> requirements by warning about many of the more easily detected cases
> that have undefined behavior).
Back to those band saw guards.
Out on the production room floor, people use band saws in ways that
vary from the manuals. If enough of them lose fingers, arms, eyes, etc.,
the factory starts looking for other suppliers whose products have
better safety features.
Anyway, I had intended to let this discussion rest. I've got something
to think about, on those i-code lists, while I'm working on what is
supposed to put food on the table for the next several months. And I
have a lot more work than I have time to be enjoying sparring with
you in abstract about the standard.
Thanks again for your help.
--
Joel Rees
Delusions of being a novelist:
http://reiisi.blogspot.com/p/novels-i-am-writing.html
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-28 09:28 -0700 |
| Message-ID | <ed7b187f-dabe-4ddf-b535-22c6561ab4eb@googlegroups.com> |
| In reply to | #110819 |
On Sunday, May 28, 2017 at 8:54:05 AM UTC-5, joel...@gmail.com wrote: > On Sunday, May 28, 2017 at 5:22:30 AM UTC+9, James Kuyper wrote: > > 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? I would suggest that the primary purpose of most C implementations is to allow a programmer who is given a set of application requirements, to end up with a machine- code program that, when executed, will satisfy those requirements. If an implementation is marketed toward a particular application field, it should try to allow programmers to meet the kinds of requirements that would be typical in that field, as efficiently as possible (measured both in terms of programmer effort and machine resources). Some application fields involve feeding programs data that comes exclusively from "trustworthy" sources. If a program is not required to prevent maliciously crafted files from doing evil things, it may be more efficient than one that it is required to ensure that no possible input will have any effect beyond yielding possibly-meaningless output and/or triggering an abnormal program termination. On the other hand, many programs need to be able to safely process data from sources that may not be trustworthy. It may be acceptable for such programs to terminate abnormally when given bogus data, but it should not be acceptable for them to allow maliciously- crafted data to trigger arbitrary side effects of its creator's choosing. Many platforms make it possible for an implementation to guarantee at almost zero cost that many actions will never do anything other than execute without side-effects (yielding a possibly meaningless value) or terminate the program. If either behavior would satisfy a program's requirements, but other forms of arbitrary behavior would not, such guarantees may make it possible to generate more efficient code than would be possible in their absence. > Back to those band saw guards. > > Out on the production room floor, people use band saws in ways that > vary from the manuals. If enough of them lose fingers, arms, eyes, etc., > the factory starts looking for other suppliers whose products have > better safety features. Problems would also arise if band saw makers included guards which made it impossible for anyone to get their hands anywhere near the blade, but made it necessary to use tools to indirectly manipulate the objects to be cut. If a band saw maker included a guard that would prevent anyone's finger from getting within 6" of the blade, but then built in a bomb that would destroy the facility if anyone's finger got within 5" of the blade, I would regard that product as being needlessly unsafe even if the only way for someone's finger to get within 5" of the blade would be to bypass the guard.
[toc] | [prev] | [next] | [standalone]
Page 8 of 13 — ← Prev page 1 … 6 7 [8] 9 10 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web