Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.mac.system > #56833 > unrolled thread
| Started by | Ted Lee <tmplee@gmail.com> |
|---|---|
| First post | 2014-02-22 12:56 -0600 |
| Last post | 2014-03-01 21:53 +0000 |
| Articles | 20 on this page of 197 — 21 participants |
Back to article view | Back to comp.sys.mac.system
Latest IOS/OS X SSL security flaw Ted Lee <tmplee@gmail.com> - 2014-02-22 12:56 -0600
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-22 14:15 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 14:47 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-22 21:30 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 19:04 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 00:36 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 09:48 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 16:41 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 12:05 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 17:22 +0000
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-24 02:15 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 03:57 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 18:25 -0500
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-25 08:16 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 19:50 -0500
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-23 07:51 -0800
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 11:23 -0500
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-23 15:05 -0800
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 20:01 -0500
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 04:21 +0000
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-24 04:35 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 06:00 +0000
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-24 16:52 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-24 21:54 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:44 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-25 00:19 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 19:26 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-25 00:40 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 19:46 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-25 00:57 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:43 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-25 00:19 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 19:29 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-25 00:40 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 19:45 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-25 00:57 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 05:04 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 06:00 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 16:10 +0000
Re: Latest IOS/OS X SSL security flaw Kurt Ullman <kurtullman@yahoo.com> - 2014-02-24 12:15 -0500
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 22:33 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:47 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-25 13:41 +0000
Re: Latest IOS/OS X SSL security flaw Kurt Ullman <kurtullman@yahoo.com> - 2014-02-25 09:06 -0500
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-25 17:34 +0000
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-25 19:14 +0000
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-25 20:42 +0100
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-25 21:32 +0000
Re: Latest IOS/OS X SSL security flaw Ted Lee <tmplee@gmail.com> - 2014-02-25 17:12 -0600
Re: Latest IOS/OS X SSL security flaw Ted Lee <tmplee@gmail.com> - 2014-02-25 17:24 -0600
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-26 02:38 +0000
Re: Latest IOS/OS X SSL security flaw Ted Lee <tmplee@gmail.com> - 2014-02-25 21:03 -0600
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-26 04:19 +0000
Re: Latest IOS/OS X SSL security flaw "M. John Matlaw" <nouser@invalid.com> - 2014-02-28 11:29 -0500
Re: Latest IOS/OS X SSL security flaw Ted Lee <tmplee@gmail.com> - 2014-02-28 12:48 -0600
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-26 01:44 +0000
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-25 21:59 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 22:33 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 23:13 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:45 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 23:17 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 18:28 -0500
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-24 23:16 -0500
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-24 21:17 -0800
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-25 21:03 +0100
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-25 21:00 +0100
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-25 22:02 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-25 08:11 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-25 16:47 +0000
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-25 17:03 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 19:45 -0500
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-26 00:05 -0500
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-25 20:57 +0100
Re: Latest IOS/OS X SSL security flaw "M. John Matlaw" <nouser@invalid.com> - 2014-02-26 09:52 -0500
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-04-06 02:36 +0200
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-24 21:24 +0100
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 20:43 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:40 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 16:47 +0000
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-23 15:37 -0800
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 20:08 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 01:15 +0000
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-23 18:45 -0800
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 02:52 +0000
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-23 19:01 -0800
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 04:23 +0000
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-24 22:10 +0100
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 22:21 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:27 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:27 -0500
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-24 21:05 -0800
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 19:34 -0500
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-24 21:58 +0100
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 18:04 -0500
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-25 02:44 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 01:14 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 04:11 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 18:36 -0500
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-25 08:20 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-25 17:00 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-25 20:05 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-25 21:31 +0000
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-25 19:13 -0800
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-26 04:35 +0000
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-26 06:42 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-03-01 21:57 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-26 23:29 +0000
Re: Latest IOS/OS X SSL security flaw Walter Bushell <proto@panix.com> - 2014-04-13 15:06 -0400
Re: Latest IOS/OS X SSL security flaw Tom Stiller <clusterfux.upmon@gmail.com> - 2014-04-13 21:11 +0000
Re: Latest IOS/OS X SSL security flaw Walter Bushell <proto@panix.com> - 2014-04-15 17:03 -0400
Re: Latest IOS/OS X SSL security flaw Your Name <YourName@YourISP.com> - 2014-04-16 09:29 +1200
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 19:29 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-26 00:49 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 19:59 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-26 02:03 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 22:13 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-26 14:03 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-26 23:42 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-27 17:03 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-26 02:47 +0000
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-26 00:10 -0500
Re: Latest IOS/OS X SSL security flaw Walter Bushell <proto@panix.com> - 2014-04-13 15:11 -0400
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-13 15:43 -0400
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-26 02:42 +0000
Re: Latest IOS/OS X SSL security flaw Walter Bushell <proto@panix.com> - 2014-04-13 15:08 -0400
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-13 15:41 -0400
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 19:18 -0500
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-26 23:39 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-27 17:09 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 13:03 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-23 01:32 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 10:07 -0500
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-04-06 02:44 +0200
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-22 17:49 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 19:07 -0500
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-22 22:23 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 03:49 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 10:12 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 16:42 +0000
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-23 14:38 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 10:11 -0500
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-23 14:38 -0500
Re: Latest IOS/OS X SSL security flaw Jim Gibson <jimsgibson@gmail.com> - 2014-02-24 10:42 -0800
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-24 17:07 -0500
Re: Latest IOS/OS X SSL security flaw Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2014-02-22 23:01 -0800
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-23 14:38 -0500
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-24 01:46 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-03-01 21:52 +0000
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-03-02 00:05 -0500
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-24 22:24 +0100
Re: Latest IOS/OS X SSL security flaw mcarels@xs4all.nl (Maarten Carels) - 2014-02-24 10:43 +0100
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 18:39 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 19:16 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 14:18 -0500
Re: Latest IOS/OS X SSL security flaw Tim McNamara <timmcn@bitstream.net> - 2014-02-22 13:43 -0600
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 14:52 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-22 20:05 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 15:16 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-22 21:10 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 16:25 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-22 22:13 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-22 22:19 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 18:55 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-23 09:38 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 10:17 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-23 15:42 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 10:45 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-23 17:09 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 13:51 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-23 20:07 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 15:14 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 15:20 -0500
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-24 02:18 +0000
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-22 17:51 -0500
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-22 17:55 -0500
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-22 21:50 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 19:09 -0500
Re: Latest IOS/OS X SSL security flaw Alan Baker <alangbaker@telus.net> - 2014-02-22 12:35 -0800
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-22 16:59 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-22 22:14 +0000
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-22 17:53 -0500
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-22 18:01 -0500
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-22 18:22 -0500
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-22 18:29 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-22 23:33 +0000
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-23 18:23 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 01:08 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-22 21:49 +0000
Re: Latest IOS/OS X SSL security flaw Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2014-02-22 22:57 -0800
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 16:36 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 11:58 -0500
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-23 14:35 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 21:03 +0000
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-23 18:23 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 01:07 +0000
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-24 01:53 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-03-01 21:53 +0000
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2014-02-26 00:10 -0500 |
| Message-ID | <530d772b$0$59826$c3e8da3$e074e489@news.astraweb.com> |
| In reply to | #57108 |
> On 2014-02-26, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: >> >> Is there repeat in Ada? >> >> Repeat >> stuff (something); >> more (other); >> Until something or other; >> In cobol: PERFORM AROUSAL THROUGH ORGASM UNTIL EXHAUSTED. this is a valid statement. basically it loops the list of paragraphs between Arousal and Orgasm (inclusive) checking the value of the variable EXHAUSTED after each iteration. When set to "true", the the loop ends.
[toc] | [prev] | [next] | [standalone]
| From | Walter Bushell <proto@panix.com> |
|---|---|
| Date | 2014-04-13 15:11 -0400 |
| Message-ID | <proto-8C5705.15110913042014@news.panix.com> |
| In reply to | #57125 |
In article <530d772b$0$59826$c3e8da3$e074e489@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > > On 2014-02-26, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: > >> > >> Is there repeat in Ada? > >> > >> Repeat > >> stuff (something); > >> more (other); > >> Until something or other; > >> > > In cobol: > > PERFORM AROUSAL THROUGH ORGASM UNTIL EXHAUSTED. > > this is a valid statement. basically it loops the list of paragraphs > between Arousal and Orgasm (inclusive) checking the value of the > variable EXHAUSTED after each iteration. When set to "true", the the > loop ends. Better PERFORM AROUSAL THROUGH ORGASM UNTIL EXHAUSTED ON SIZE ERROR GO TO HASTY_EXIT. -- Never attribute to stupidity that which can be explained by greed. Me.
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-04-13 15:43 -0400 |
| Message-ID | <sp6dnQ6qv5lPddfOnZ2dnUVZ_gydnZ2d@giganews.com> |
| In reply to | #58528 |
On 2014.04.13, 15:11 , Walter Bushell wrote:
> In article <530d772b$0$59826$c3e8da3$e074e489@news.astraweb.com>,
> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>
>>> On 2014-02-26, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>>>
>>>> Is there repeat in Ada?
>>>>
>>>> Repeat
>>>> stuff (something);
>>>> more (other);
>>>> Until something or other;
>>>>
>>
>> In cobol:
>>
>> PERFORM AROUSAL THROUGH ORGASM UNTIL EXHAUSTED.
>>
>> this is a valid statement. basically it loops the list of paragraphs
>> between Arousal and Orgasm (inclusive) checking the value of the
>> variable EXHAUSTED after each iteration. When set to "true", the the
>> loop ends.
>
> Better
>
>
> PERFORM AROUSAL THROUGH ORGASM UNTIL EXHAUSTED ON SIZE ERROR GO TO
> HASTY_EXIT.
What if there are two exit cases, ?
"SIZE ERROR"
"EJACULATION TIME < SATISFYING"
--
"Big data can reduce anything to a single number,
but you shouldn’t be fooled by the appearance of exactitude."
-Gary Marcus and Ernest Davis, NYT, 2014.04.07
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-02-26 02:42 +0000 |
| Message-ID | <bn52jrFgm4aU2@mid.individual.net> |
| In reply to | #57096 |
On 2014-02-26, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> On 2014.02.25, 12:00 , Jolly Roger wrote:
>> On 2014-02-25, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
>>> In message <dMudndUn8-IKSpbOnZ2dnUVZ_rWdnZ2d@giganews.com>
>>> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>>> On 2014.02.23, 23:11 , Lewis wrote:
>>>>> In message <led5e1$4q9$1@dont-email.me>
>>>>> Don Bruder <dakidd@sonic.net> wrote:
>>>>>> I tend toward "overkill unto the verge of paranoia" when bracing
>>>>>> conditionals, for exactly that reason. Even though I'm quite aware that
>>>>>> "if (foo) bar(foo);" is perfectly valid code that'll compile without so
>>>>>> much as a hiccup, if I'm coding something that needs that sort of
>>>>>> construct, I'm most likely going to write it as
>>>>>> if (foo)
>>>>>> {
>>>>>> bar(foo);
>>>>>> }
>>>>>> else
>>>>>> {
>>>>>> // It's a bad idea to bar() a nil foo
>>>>>> }
>>>>>
>>>>> I like more compact code:
>>>>>
>>>>> if (foo) { bar(foo); }
>>>
>>>> Pascal:
>>>
>>>> if foo then bar(foo);
>>>
>>>> Much more readable.
>>>
>>> Not really.
>>>
>>>
>>> if (foo) { bar(foo); }
>>> a = a + 1;
>>>
>>> if foo then bar(foo);
>>> a = a + 1;
>>>
>>> The first (C) example is much clearer to me that the assignment line is
>>> *not* part of the if block.
>>
>> Agreed.
>>
>> That said, I dislike your approach of placing as much as possible on a
>> single line. It's not as easy to scan through many lines of such code as
>> it would be if things weren't stacked up like that, and it doesn't make
>> things easy for the developer later on when you need to add additional
>> comments and statements inside of the if clause. So I tend to adhere to
>> this expanded format instead, so that modification down the line is as
>> easy as possible:
>>
>> if (foo)
>> {
>> // blah blah blah
>> bar(foo);
>> b = a * c;
>> }
>> a = a + 1;
>
> That looks silly to me - the braces all the way to the left ... well
> it's the braces that are the issue...
I see no need to indent just the braces on their own, since they
function as a container for everything inside of the if block. I see
that as a waste of horizontal space for little benefit. I realize others
don't agree, and that's fine. It's good that we have the freedom to
choose.
>> To each, their own, of course; but I'm always doing my best to think
>> ahead and consider that the code I write will probably need to be
>> modified by someone else at some point in the future. One of my goals
>> is to make that job as easy as I can for them.
>
> Me too. We just don't agree on how that looks. To be sure Pascal, with
> the begin / end statement leaves a very clear beginning and end to
> blocks of code. Further, if so inclined, you can change case to help
> the reader:
>
> BEGIN
>
> while cond1 do
> Begin
> if cond436 then
> begin
>
> else
>
> end;
> Else
>
> End;
> END;
Yeah, to me indenting begin/end is unnecessary. But to each, their own!
: )
--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.
JR
[toc] | [prev] | [next] | [standalone]
| From | Walter Bushell <proto@panix.com> |
|---|---|
| Date | 2014-04-13 15:08 -0400 |
| Message-ID | <proto-DBB75C.15081013042014@news.panix.com> |
| In reply to | #57096 |
In article <g46dnUyv66zKqJDOnZ2dnUVZ_vidnZ2d@giganews.com>,
Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> On 2014.02.25, 12:00 , Jolly Roger wrote:
> > On 2014-02-25, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
> >> In message <dMudndUn8-IKSpbOnZ2dnUVZ_rWdnZ2d@giganews.com>
> >> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> >>> On 2014.02.23, 23:11 , Lewis wrote:
> >>>> In message <led5e1$4q9$1@dont-email.me>
> >>>> Don Bruder <dakidd@sonic.net> wrote:
> >>>>> I tend toward "overkill unto the verge of paranoia" when bracing
> >>>>> conditionals, for exactly that reason. Even though I'm quite aware that
> >>>>> "if (foo) bar(foo);" is perfectly valid code that'll compile without so
> >>>>> much as a hiccup, if I'm coding something that needs that sort of
> >>>>> construct, I'm most likely going to write it as
> >>>>> if (foo)
> >>>>> {
> >>>>> bar(foo);
> >>>>> }
> >>>>> else
> >>>>> {
> >>>>> // It's a bad idea to bar() a nil foo
> >>>>> }
> >>>>
> >>>> I like more compact code:
> >>>>
> >>>> if (foo) { bar(foo); }
> >>
> >>> Pascal:
> >>
> >>> if foo then bar(foo);
> >>
> >>> Much more readable.
> >>
> >> Not really.
> >>
> >>
> >> if (foo) { bar(foo); }
> >> a = a + 1;
> >>
> >> if foo then bar(foo);
> >> a = a + 1;
> >>
> >> The first (C) example is much clearer to me that the assignment line is
> >> *not* part of the if block.
> >
> > Agreed.
> >
> > That said, I dislike your approach of placing as much as possible on a
> > single line. It's not as easy to scan through many lines of such code as
> > it would be if things weren't stacked up like that, and it doesn't make
> > things easy for the developer later on when you need to add additional
> > comments and statements inside of the if clause. So I tend to adhere to
> > this expanded format instead, so that modification down the line is as
> > easy as possible:
> >
> > if (foo)
> > {
> > // blah blah blah
> > bar(foo);
> > b = a * c;
> > }
> > a = a + 1;
>
> That looks silly to me - the braces all the way to the left ... well
> it's the braces that are the issue...
>
> > To each, their own, of course; but I'm always doing my best to think
> > ahead and consider that the code I write will probably need to be
> > modified by someone else at some point in the future. One of my goals
> > is to make that job as easy as I can for them.
>
> Me too. We just don't agree on how that looks. To be sure Pascal, with
> the begin / end statement leaves a very clear beginning and end to
> blocks of code. Further, if so inclined, you can change case to help
> the reader:
>
> BEGIN
>
> while cond1 do
> Begin
> if cond436 then
> begin
>
> else
>
> end;
> Else
>
> End;
> END;
I really would like numbers or Names on the "Begin"s and "End"s so
that the logic is totally clear.
--
Never attribute to stupidity that which can be explained by greed. Me.
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-04-13 15:41 -0400 |
| Message-ID | <sp6dnQ-qv5nxddfOnZ2dnUVZ_gydnZ2d@giganews.com> |
| In reply to | #58527 |
On 2014.04.13, 15:08 , Walter Bushell wrote:
> In article <g46dnUyv66zKqJDOnZ2dnUVZ_vidnZ2d@giganews.com>,
> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> Me too. We just don't agree on how that looks. To be sure Pascal, with
>> the begin / end statement leaves a very clear beginning and end to
>> blocks of code. Further, if so inclined, you can change case to help
>> the reader:
>>
>> BEGIN
>>
>> while cond1 do
>> Begin
>> if cond436 then
>> begin
>>
>> else
>>
>> end;
>> Else
>>
>> End;
>> END;
>
> I really would like numbers or Names on the "Begin"s and "End"s so
> that the logic is totally clear.
It's clear enough to me. Languages like Ada are more demanding in terms
of "closures".
In practice in "serious" programs I end procedures:
END; {arm_nuclear_weapons}
(* ********************************************************* *)
--
"Big data can reduce anything to a single number,
but you shouldn’t be fooled by the appearance of exactitude."
-Gary Marcus and Ernest Davis, NYT, 2014.04.07
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-25 19:18 -0500 |
| Message-ID | <tvedndNxpIBSr5DOnZ2dnUVZ_vWdnZ2d@giganews.com> |
| In reply to | #57058 |
On 2014.02.25, 03:20 , Lewis wrote:
> In message <dMudndUn8-IKSpbOnZ2dnUVZ_rWdnZ2d@giganews.com>
> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> On 2014.02.23, 23:11 , Lewis wrote:
>>> In message <led5e1$4q9$1@dont-email.me>
>>> Don Bruder <dakidd@sonic.net> wrote:
>>>> In article <bmsu50Fnr6sU2@mid.individual.net>,
>>>> Jolly Roger <jollyroger@pobox.com> wrote:
>>>
>>>>> On 2014-02-23, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>>>>> On 2014.02.22, 16:30 , Jolly Roger wrote:
>>>>>>> On 2014-02-22, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>>>>>>> On 2014.02.22, 14:15 , nospam wrote:
>>>>>>>>> In article <lears8$l8d$1@dont-email.me>, Ted Lee <tmplee@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> The press and gossip rag reports say the recently discovered security
>>>>>>>>>> flaw with SSL is present in both IOS and OS X. The patch for IOS showed
>>>>>>>>>> up last night. The reports say the OS X one will be out soon. Has
>>>>>>>>>> anyone run across a technically competent (as opposed to sensationalized
>>>>>>>>>> fear-mongering amateur drivel) discussion of the flaw *and* a conclusive
>>>>>>>>>> statement that it is indeed present in OS X?
>>>>>>>>>
>>>>>>>>> it is in os x, and it's nothing more than an extra goto.
>>>>>>>>>
>>>>>>>>> <https://www.imperialviolet.org/2014/02/22/applebug.html>
>>>>>>>>
>>>>>>>> ROFL.
>>>>>>>>
>>>>>>>> goto has always been a source of low software quality - and it rears its
>>>>>>>> head again here - although it looks more like sloppy editing than
>>>>>>>> anything else - like another line of condition code had been deleted or
>>>>>>>> moved.
>>>>>>>
>>>>>>> Indeed. And as John Gruber (Daring Fireball) asserted, the practice of
>>>>>>> using curly braces for if blocks would have made the slip-up much more
>>>>>>> obvious. I tend to prefer using braces in if blocks myself.
>>>
>>>> I tend toward "overkill unto the verge of paranoia" when bracing
>>>> conditionals, for exactly that reason. Even though I'm quite aware that
>>>> "if (foo) bar(foo);" is perfectly valid code that'll compile without so
>>>> much as a hiccup, if I'm coding something that needs that sort of
>>>> construct, I'm most likely going to write it as
>>>> if (foo)
>>>> {
>>>> bar(foo);
>>>> }
>>>> else
>>>> {
>>>> // It's a bad idea to bar() a nil foo
>>>> }
>>>
>>> I like more compact code:
>>>
>>> if (foo) { bar(foo); }
>
>> Pascal:
>
>> if foo then bar(foo);
>
>> Much more readable.
>
> Not really.
Really. It's almost plain English.
> if (foo) { bar(foo); }
> a = a + 1;
>
> if foo then bar(foo);
> a = a + 1;
>
> The first (C) example is much clearer to me that the assignment line is
> *not* part of the if block.
Bad coding style in either language, so it doesn't prove anything. The
indent is misleading. It would properly be written
if foo then bar(foo);
a := a + 1;
Or add a line of blank space between them
Or if you insist, then you can add, without generating any extra code:
if foo then
begin
bar(foo)
end;
a := a + 1;
--
... it may be that "in the cloud" really isn't the best term
for the services these companies offer. What they really
want is to have us "on the leash."
-David Pogue, Scientific American, 2014.02
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2014-02-26 23:39 +0000 |
| Message-ID | <slrnlgsuq9.16s.g.kreme@oswin.local> |
| In reply to | #57095 |
In message <tvedndNxpIBSr5DOnZ2dnUVZ_vWdnZ2d@giganews.com>
Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> On 2014.02.25, 03:20 , Lewis wrote:
>> In message <dMudndUn8-IKSpbOnZ2dnUVZ_rWdnZ2d@giganews.com>
>> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>> On 2014.02.23, 23:11 , Lewis wrote:
>>>> In message <led5e1$4q9$1@dont-email.me>
>>>> Don Bruder <dakidd@sonic.net> wrote:
>>>>> In article <bmsu50Fnr6sU2@mid.individual.net>,
>>>>> Jolly Roger <jollyroger@pobox.com> wrote:
>>>>
>>>>>> On 2014-02-23, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>>>>>> On 2014.02.22, 16:30 , Jolly Roger wrote:
>>>>>>>> On 2014-02-22, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>>>>>>>> On 2014.02.22, 14:15 , nospam wrote:
>>>>>>>>>> In article <lears8$l8d$1@dont-email.me>, Ted Lee <tmplee@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> The press and gossip rag reports say the recently discovered security
>>>>>>>>>>> flaw with SSL is present in both IOS and OS X. The patch for IOS showed
>>>>>>>>>>> up last night. The reports say the OS X one will be out soon. Has
>>>>>>>>>>> anyone run across a technically competent (as opposed to sensationalized
>>>>>>>>>>> fear-mongering amateur drivel) discussion of the flaw *and* a conclusive
>>>>>>>>>>> statement that it is indeed present in OS X?
>>>>>>>>>>
>>>>>>>>>> it is in os x, and it's nothing more than an extra goto.
>>>>>>>>>>
>>>>>>>>>> <https://www.imperialviolet.org/2014/02/22/applebug.html>
>>>>>>>>>
>>>>>>>>> ROFL.
>>>>>>>>>
>>>>>>>>> goto has always been a source of low software quality - and it rears its
>>>>>>>>> head again here - although it looks more like sloppy editing than
>>>>>>>>> anything else - like another line of condition code had been deleted or
>>>>>>>>> moved.
>>>>>>>>
>>>>>>>> Indeed. And as John Gruber (Daring Fireball) asserted, the practice of
>>>>>>>> using curly braces for if blocks would have made the slip-up much more
>>>>>>>> obvious. I tend to prefer using braces in if blocks myself.
>>>>
>>>>> I tend toward "overkill unto the verge of paranoia" when bracing
>>>>> conditionals, for exactly that reason. Even though I'm quite aware that
>>>>> "if (foo) bar(foo);" is perfectly valid code that'll compile without so
>>>>> much as a hiccup, if I'm coding something that needs that sort of
>>>>> construct, I'm most likely going to write it as
>>>>> if (foo)
>>>>> {
>>>>> bar(foo);
>>>>> }
>>>>> else
>>>>> {
>>>>> // It's a bad idea to bar() a nil foo
>>>>> }
>>>>
>>>> I like more compact code:
>>>>
>>>> if (foo) { bar(foo); }
>>
>>> Pascal:
>>
>>> if foo then bar(foo);
>>
>>> Much more readable.
>>
>> Not really.
> Really. It's almost plain English.
>> if (foo) { bar(foo); }
>> a = a + 1;
>>
>> if foo then bar(foo);
>> a = a + 1;
>>
>> The first (C) example is much clearer to me that the assignment line is
>> *not* part of the if block.
> Bad coding style in either language, so it doesn't prove anything. The
> indent is misleading. It would properly be written
Right, and that *never* happens. The point is, the one with the brackets
is obvious, and the other is not obvious. At all.
--
"Patience has its limits. Take it too far, and it's cowardice." - George
Jackson
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-27 17:09 -0500 |
| Message-ID | <_9WdnU4tKK87KpLOnZ2dnUVZ_ggAAAAA@giganews.com> |
| In reply to | #57154 |
On 2014.02.26, 18:39 , Lewis wrote:
> In message <tvedndNxpIBSr5DOnZ2dnUVZ_vWdnZ2d@giganews.com>
> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> On 2014.02.25, 03:20 , Lewis wrote:
>>> In message <dMudndUn8-IKSpbOnZ2dnUVZ_rWdnZ2d@giganews.com>
>>> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>>> Pascal:
>>>
>>>> if foo then bar(foo);
>>>
>>>> Much more readable.
>>>
>>> Not really.
>
>> Really. It's almost plain English.
>
>>> if (foo) { bar(foo); }
>>> a = a + 1;
>>>
>>> if foo then bar(foo);
>>> a = a + 1;
>>>
>>> The first (C) example is much clearer to me that the assignment line is
>>> *not* part of the if block.
>
>> Bad coding style in either language, so it doesn't prove anything. The
>> indent is misleading. It would properly be written
if foo then bar(foo);
a := a + 1;
> Right, and that *never* happens. The point is, the one with the brackets
> is obvious, and the other is not obvious. At all.
It is to me. Your artificial indent screamed at me to look closer only
to find the code was correct but badly edited.
But that's because I program in Pascal almost exclusively, so I see it
for what it was: messily formatted code - and that makes me fix it even
if it's just format.
--
Those who have reduced our privacy, whether they are state
or commercial actors, prefer that we do not reduce theirs.
- Jaron Lanier, Scientific American, 2013.11.
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-23 13:03 -0500 |
| Message-ID | <O7ydnfnJYtiWpZfOnZ2dnUVZ_h-dnZ2d@giganews.com> |
| In reply to | #56874 |
On 2014.02.22, 19:36 , Jolly Roger wrote:
> On 2014-02-23, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> Note: if the disk is encrypted I hit about 110 MB/s; non-encrypted 165
>> MB/s. I didn't think there would be that much of a hit on encrypted drives.
And by the time the disk is about 90% fill, the 165 MB/s drops to about
82 MB/s. Gets worse and worse to the end. Head has to move further on
directory/write updates I guess...
--
Those who have reduced our privacy, whether they are state
or commercial actors, prefer that we do not reduce theirs.
- Jaron Lanier, Scientific American, 2013.11.
[toc] | [prev] | [next] | [standalone]
| From | Bill Findlay <yaldnif.w@blueyonder.co.uk> |
|---|---|
| Date | 2014-02-23 01:32 +0000 |
| Message-ID | <CF2F0027.42C81%yaldnif.w@blueyonder.co.uk> |
| In reply to | #56870 |
On 23/02/2014 00:04, in article
L-SdnavB-Z27ppTOnZ2dnUVZ_uKdnZ2d@giganews.com, "Alan Browne"
<alan.browne@FreelunchVideotron.ca> wrote:
> On 2014.02.22, 16:30 , Jolly Roger wrote:
>> On 2014-02-22, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>> On 2014.02.22, 14:15 , nospam wrote:
>>>> In article <lears8$l8d$1@dont-email.me>, Ted Lee <tmplee@gmail.com>
>>>> wrote:
>>>>
>>>>> The press and gossip rag reports say the recently discovered security
>>>>> flaw with SSL is present in both IOS and OS X. The patch for IOS showed
>>>>> up last night. The reports say the OS X one will be out soon. Has
>>>>> anyone run across a technically competent (as opposed to sensationalized
>>>>> fear-mongering amateur drivel) discussion of the flaw *and* a conclusive
>>>>> statement that it is indeed present in OS X?
>>>>
>>>> it is in os x, and it's nothing more than an extra goto.
>>>>
>>>> <https://www.imperialviolet.org/2014/02/22/applebug.html>
>>>
>>> ROFL.
>>>
>>> goto has always been a source of low software quality - and it rears its
>>> head again here - although it looks more like sloppy editing than
>>> anything else - like another line of condition code had been deleted or
>>> moved.
>>
>> Indeed. And as John Gruber (Daring Fireball) asserted, the practice of
>> using curly braces for if blocks would have made the slip-up much more
>> obvious. I tend to prefer using braces in if blocks myself.
>
> I tend to think curly braces suck as code block begin/ends. ;-)
>
> {This was esp. so with dot matrix printers. We didn't have no fancy
> colour editors either}
>
> What the hell is the matter with nice fat, 0 code producing BEGIN END
> statements, anyway?
>
> Ada. Ah, Ada, why have you forsaken us and let C rule?
She hasn't.
I use Ada 2012 as the only serious programming language on my MacBook Pro.
The compiler would certainly have issued a warning for that extra goto.
I expect the Apple C compiler did too, but was ignored.
--
Bill Findlay
with blueyonder.co.uk;
use surname & forename;
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-23 10:07 -0500 |
| Message-ID | <vqednbcprPUtk5fOnZ2dnUVZ_uadnZ2d@giganews.com> |
| In reply to | #56875 |
On 2014.02.22, 20:32 , Bill Findlay wrote:
> On 23/02/2014 00:04, in article
> L-SdnavB-Z27ppTOnZ2dnUVZ_uKdnZ2d@giganews.com, "Alan Browne"
> <alan.browne@FreelunchVideotron.ca> wrote:
>
>> On 2014.02.22, 16:30 , Jolly Roger wrote:
>>> On 2014-02-22, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>>> On 2014.02.22, 14:15 , nospam wrote:
>>>>> In article <lears8$l8d$1@dont-email.me>, Ted Lee <tmplee@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> The press and gossip rag reports say the recently discovered security
>>>>>> flaw with SSL is present in both IOS and OS X. The patch for IOS showed
>>>>>> up last night. The reports say the OS X one will be out soon. Has
>>>>>> anyone run across a technically competent (as opposed to sensationalized
>>>>>> fear-mongering amateur drivel) discussion of the flaw *and* a conclusive
>>>>>> statement that it is indeed present in OS X?
>>>>>
>>>>> it is in os x, and it's nothing more than an extra goto.
>>>>>
>>>>> <https://www.imperialviolet.org/2014/02/22/applebug.html>
>>>>
>>>> ROFL.
>>>>
>>>> goto has always been a source of low software quality - and it rears its
>>>> head again here - although it looks more like sloppy editing than
>>>> anything else - like another line of condition code had been deleted or
>>>> moved.
>>>
>>> Indeed. And as John Gruber (Daring Fireball) asserted, the practice of
>>> using curly braces for if blocks would have made the slip-up much more
>>> obvious. I tend to prefer using braces in if blocks myself.
>>
>> I tend to think curly braces suck as code block begin/ends. ;-)
>>
>> {This was esp. so with dot matrix printers. We didn't have no fancy
>> colour editors either}
>>
>> What the hell is the matter with nice fat, 0 code producing BEGIN END
>> statements, anyway?
>>
>> Ada. Ah, Ada, why have you forsaken us and let C rule?
>
> She hasn't.
Linux, OS X, Windows and most major apps are coded in C. Ada did not
start aggressively enough - and early compilers were shit. On the
course I took they wheeled in an hp-ux system and the compiler was okay,
but it took hours to compile "Hello World" on a VAX x-compiler for x86.
Our radar system (about 15K lines of Ada for x86) took 24 hours to
x-compile and link on a VAX 785.
I wrote the monitor/flight data recorder (PC) for that in about 5000
lines and it compiled and linked in 1 minute on a 368 (16 MHz).
> I use Ada 2012 as the only serious programming language on my MacBook Pro.
> The compiler would certainly have issued a warning for that extra goto.
> I expect the Apple C compiler did too, but was ignored.
Cripes! I didn't think Ada allowed goto. I took a course at work in
about 1990 but never developed code - I did write a module in assembler
that was linked into the Ada based radar above.
On an other project (that I wasn't involved with at the start), our
contract (air transport GPS receiver) forbid:
recursion
rendezvous
pre-emption
... and other things I don't recall.
The program had to be 100% deterministic in realtime.
Our SQA absolutely forbid goto in any HOL deliverable.
--
Privacy has become an essential personal chore that most
people are not trained to perform.
- Jaron Lanier, Scientific American, 2013.11.
[toc] | [prev] | [next] | [standalone]
| From | Paul Sture <nospam@sture.ch> |
|---|---|
| Date | 2014-04-06 02:44 +0200 |
| Message-ID | <vjk61b-agd.ln1@news.chingola.ch> |
| In reply to | #56875 |
On 2014-02-23, Bill Findlay <yaldnif.w@blueyonder.co.uk> wrote: > I use Ada 2012 as the only serious programming language on my MacBook Pro. > The compiler would certainly have issued a warning for that extra goto. > I expect the Apple C compiler did too, but was ignored. In gcc: gcc -Wunreachable-code -Werr DEC/Compaq/HP COBOL would have caught this by default (yes, even 30 years ago!) and set a warning status flag in the object file which would produce a warning at link time as well. -- Paul Sture "In that case," said Napoleon, "let us wait twenty minutes; when the enemy is making a false movement we must take good care not to interrupt him."
[toc] | [prev] | [next] | [standalone]
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2014-02-22 17:49 -0500 |
| Message-ID | <53092980$0$9676$c3e8da3$aae71a0a@news.astraweb.com> |
| In reply to | #56837 |
On 14-02-22 14:47, Alan Browne wrote: > goto has always been a source of low software quality - and it rears its > head again here - although it looks more like sloppy editing than > anything else - like another line of condition code had been deleted or > moved. Don't forget compiler optimisation which may have replaced all that code with a "goto fail" since in every situation, the only action taken is to goto fail.
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-22 19:07 -0500 |
| Message-ID | <L-SdnarB-Z1fppTOnZ2dnUVZ_uIAAAAA@giganews.com> |
| In reply to | #56861 |
On 2014.02.22, 17:49 , JF Mezei wrote:
> On 14-02-22 14:47, Alan Browne wrote:
>
>> goto has always been a source of low software quality - and it rears its
>> head again here - although it looks more like sloppy editing than
>> anything else - like another line of condition code had been deleted or
>> moved.
>
>
> Don't forget compiler optimisation which may have replaced all that code
> with a "goto fail" since in every situation, the only action taken is to
> goto fail.
Compiler optimization doesn't replace source code.
A more 'rigorous' style (which amongst other things, avoids goto) would
have either avoided that bug or resulted in a failed compilation.
--
Those who have reduced our privacy, whether they are state
or commercial actors, prefer that we do not reduce theirs.
- Jaron Lanier, Scientific American, 2013.11.
[toc] | [prev] | [next] | [standalone]
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2014-02-22 22:23 -0500 |
| Message-ID | <5309699e$0$34974$c3e8da3$460562f1@news.astraweb.com> |
| In reply to | #56871 |
On 14-02-22 19:07, Alan Browne wrote: > Compiler optimization doesn't replace source code. Modern commercial optimizing compilers most certaintly do. They also re-arrange order for some target platforms. A whole block of IFs whose sole outcome is to branch to the same place would be detected by a good compiler and optimized away. On VMS for instance, when you want to debug code, you must compile with optimizations off so your source code can be matched with operations and variables. (variables are often optimized away). > A more 'rigorous' style (which amongst other things, avoids goto) would > have either avoided that bug or resulted in a failed compilation. There is nothing wrong with the code. Consider a situation where you have that double goto as a temporary situtaion to avoid the other checks to help debugging it, or because the code for those other checks isn't written yet. I agree that the use of braces does make things more obvious for those cases where only one statement is accepted following a conditional one (such as if, while and a few others)
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-02-23 03:49 +0000 |
| Message-ID | <bmt9dsFqnikU1@mid.individual.net> |
| In reply to | #56878 |
On 2014-02-23, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > On 14-02-22 19:07, Alan Browne wrote: > >> Compiler optimization doesn't replace source code. > > Modern commercial optimizing compilers most certaintly do. They also > re-arrange order for some target platforms. > > A whole block of IFs whose sole outcome is to branch to the same place > would be detected by a good compiler and optimized away. Yep, although one could argue that's not the source code being modified, but the generated object code. > On VMS for instance, when you want to debug code, you must compile with > optimizations off so your source code can be matched with operations and > variables. (variables are often optimized away). Yep, that applies to many compilers. >> A more 'rigorous' style (which amongst other things, avoids goto) would >> have either avoided that bug or resulted in a failed compilation. > > There is nothing wrong with the code. Consider a situation where you > have that double goto as a temporary situtaion to avoid the other checks > to help debugging it, or because the code for those other checks isn't > written yet. > > I agree that the use of braces does make things more obvious for those > cases where only one statement is accepted following a conditional one > (such as if, while and a few others) Clean, well-written, readable code is good code. -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-23 10:12 -0500 |
| Message-ID | <3tmdnWL8_v1qkpfOnZ2dnUVZ_rGdnZ2d@giganews.com> |
| In reply to | #56879 |
On 2014.02.22, 22:49 , Jolly Roger wrote:
> Clean, well-written, readable code is good code.
So C cannot be used to write good code. Knew it. Always knew it! ;-)
--
... it may be that "in the cloud" really isn't the best term
for the services these companies offer. What they really
want is to have us "on the leash."
-David Pogue, Scientific American, 2014.02
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-02-23 16:42 +0000 |
| Message-ID | <bmumncF59p1U3@mid.individual.net> |
| In reply to | #56891 |
On 2014-02-23, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: > On 2014.02.22, 22:49 , Jolly Roger wrote: > >> Clean, well-written, readable code is good code. > > So C cannot be used to write good code. Knew it. Always knew it! ;-) Heh... : ) -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2014-02-23 14:38 -0500 |
| Message-ID | <230220141438519230%nospam@nospam.invalid> |
| In reply to | #56891 |
In article <3tmdnWL8_v1qkpfOnZ2dnUVZ_rGdnZ2d@giganews.com>, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: > > Clean, well-written, readable code is good code. > > So C cannot be used to write good code. Knew it. Always knew it! ;-) that's more true than you might realize. c is not particularly strict.
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.sys.mac.system
csiph-web