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 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2014-02-25 20:05 +0000 |
| Message-ID | <slrnlgptrr.1rur.g.kreme@oswin.local> |
| In reply to | #57071 |
In message <bn40grF96u7U3@mid.individual.net>
Jolly Roger <jollyroger@pobox.com> 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:
Well, I only use that compact if (foo) { stuff; } construction when it
really is a very simple single statement.
> if (foo)
> {
> // blah blah blah
> bar(foo);
> b = a * c;
>}
> a = a + 1;
The only difference I would make is
if (foo) {
// stuff
// goes
// here
}
--
"Give a man a fire and he's warm for a day, but set fire to him an he's
warm for the rest of his life."
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-02-25 21:31 +0000 |
| Message-ID | <bn4gcrFcrkaU5@mid.individual.net> |
| In reply to | #57076 |
On 2014-02-25, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
> In message <bn40grF96u7U3@mid.individual.net>
> Jolly Roger <jollyroger@pobox.com> 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:
>
> Well, I only use that compact if (foo) { stuff; } construction when it
> really is a very simple single statement.
>
>> if (foo)
>> {
>> // blah blah blah
>> bar(foo);
>> b = a * c;
>>}
>> a = a + 1;
>
> The only difference I would make is
>
> if (foo) {
> // stuff
> // goes
> // here
> }
Yeah, that's really popular; but for my own code, I prefer the initial
bracket to be on its own line, for symmetry. It's not a big deal - 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 | Don Bruder <dakidd@sonic.net> |
|---|---|
| Date | 2014-02-25 19:13 -0800 |
| Message-ID | <lejm4d$9gu$1@dont-email.me> |
| In reply to | #57084 |
In article <bn4gcrFcrkaU5@mid.individual.net>,
Jolly Roger <jollyroger@pobox.com> wrote:
> On 2014-02-25, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
> > In message <bn40grF96u7U3@mid.individual.net>
> > Jolly Roger <jollyroger@pobox.com> 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:
> >
> > Well, I only use that compact if (foo) { stuff; } construction when it
> > really is a very simple single statement.
> >
> >> if (foo)
> >> {
> >> // blah blah blah
> >> bar(foo);
> >> b = a * c;
> >>}
> >> a = a + 1;
> >
> > The only difference I would make is
> >
> > if (foo) {
> > // stuff
> > // goes
> > // here
> > }
>
> Yeah, that's really popular; but for my own code, I prefer the initial
> bracket to be on its own line, for symmetry.
Agreed - I've never much cared for egyptian braces. Another "evil" to me
is this sort of if/else construct, a riff on egyptian bracing:
if (foo) {
bar(foo);
} else {
baz(foo);
}
That "} else {" hanging there makes my brain itch!
If I had to pick between that and a single-line
"if (foo) {bar(foo);} else {baz(foo);}" version, I think I'd have to sit
down and ponder a while about which would result in the least
brain-pain.
(Just as an observation, I note that in the quoting, my original code
has been mangled just slightly - my braces should be aligned, but it
looks like somehow an extra space snuck in on the opening ones)
Remind me again - How many of us here have OCD? :)
--
Security provided by Mssrs Smith and/or Wesson. Brought to you by the letter Q
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-02-26 04:35 +0000 |
| Message-ID | <bn598kFhkarU3@mid.individual.net> |
| In reply to | #57115 |
On 2014-02-26, Don Bruder <dakidd@sonic.net> wrote:
> In article <bn4gcrFcrkaU5@mid.individual.net>,
> Jolly Roger <jollyroger@pobox.com> wrote:
>
>> On 2014-02-25, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
>>>
>>> The only difference I would make is
>>>
>>> if (foo) {
>>> // stuff
>>> // goes
>>> // here
>>> }
>>
>> Yeah, that's really popular; but for my own code, I prefer the initial
>> bracket to be on its own line, for symmetry.
>
> Agreed - I've never much cared for egyptian braces. Another "evil" to me
> is this sort of if/else construct, a riff on egyptian bracing:
>
> if (foo) {
> bar(foo);
> } else {
> baz(foo);
> }
>
> That "} else {" hanging there makes my brain itch!
Same here. My eyes are able to more easily and fluidly scan this:
if (foo)
{
bar(foo);
}
else
{
baz(foo);
}
In my current position, I am often scanning lots of code in a very short
time span as I'm debugging, reviewing, or just reading code to gain an
understanding of it. The faster and easier it is for me to scan, the
better. Symmetry and spacing make a big difference in how fast you can
scan code. It's really that simple for me. The small amount of extra key
strokes needed is worth the gain in efficiency to me.
> If I had to pick between that and a single-line
> "if (foo) {bar(foo);} else {baz(foo);}" version, I think I'd have to sit
> down and ponder a while about which would result in the least
> brain-pain.
As others have said, if the code really is that simple, a single line
might be okay - for the moment. The concern that usually prevents me
from writing such is that someone may need to add code within the
if/else blocks later on. Having everything bunched up on a single line
means that to add something to it and keep it easily legible, someone
has to reformat it, which could introduce errors if a typo is made. I
prefer to err on the side of caution and avoid cramming things together
to begin with. I guess I'm a bit of a purist in that respect. I'm not
worried about it though, because I feel I have sound reasons for why I
do things the way I do, and I do get complimented by my peers on my
coding style.
> (Just as an observation, I note that in the quoting, my original code
> has been mangled just slightly - my braces should be aligned, but it
> looks like somehow an extra space snuck in on the opening ones)
>
> Remind me again - How many of us here have OCD? :)
I noticed that too. You're not alone. : D
--
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 | billy@MIX.COM |
|---|---|
| Date | 2014-02-26 06:42 +0000 |
| Message-ID | <lek2di$3dc$1@reader2.panix.com> |
| In reply to | #57120 |
Jolly Roger <jollyroger@pobox.com> writes:
> In my current position, I am often scanning lots of code in a very short
> time span as I'm debugging, reviewing, or just reading code to gain an
> understanding of it. The faster and easier it is for me to scan, the
> better. Symmetry and spacing make a big difference in how fast you can
> scan code. It's really that simple for me. The small amount of extra key
> strokes needed is worth the gain in efficiency to me.
Oddly enough, the same can be said regarding the masssive amounts of
unnecessarily included text in some articles in this very thread.
Billy Y..
--
sub #'9+1 ,r0 ; convert ascii byte
add #9.+1 ,r0 ; to an integer
bcc 20$ ; not a number
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-03-01 21:57 +0000 |
| Message-ID | <bnf3e9Fl9faU3@mid.individual.net> |
| In reply to | #57313 |
On 2014-02-26, billy@MIX.COM <billy@MIX.COM> wrote: > Jolly Roger <jollyroger@pobox.com> writes: > >> In my current position, I am often scanning lots of code in a very short >> time span as I'm debugging, reviewing, or just reading code to gain an >> understanding of it. The faster and easier it is for me to scan, the >> better. Symmetry and spacing make a big difference in how fast you can >> scan code. It's really that simple for me. The small amount of extra key >> strokes needed is worth the gain in efficiency to me. > > Oddly enough, the same can be said regarding the masssive amounts of > unnecessarily included text in some articles in this very thread. : D -- 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 | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2014-02-26 23:29 +0000 |
| Message-ID | <slrnlgsu6j.16s.g.kreme@oswin.local> |
| In reply to | #57115 |
In message <lejm4d$9gu$1@dont-email.me>
Don Bruder <dakidd@sonic.net> wrote:
> In article <bn4gcrFcrkaU5@mid.individual.net>,
> Jolly Roger <jollyroger@pobox.com> wrote:
>> On 2014-02-25, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
>> > In message <bn40grF96u7U3@mid.individual.net>
>> > Jolly Roger <jollyroger@pobox.com> 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:
>> >
>> > Well, I only use that compact if (foo) { stuff; } construction when it
>> > really is a very simple single statement.
>> >
>> >> if (foo)
>> >> {
>> >> // blah blah blah
>> >> bar(foo);
>> >> b = a * c;
>> >>}
>> >> a = a + 1;
>> >
>> > The only difference I would make is
>> >
>> > if (foo) {
>> > // stuff
>> > // goes
>> > // here
>> > }
>>
>> Yeah, that's really popular; but for my own code, I prefer the initial
>> bracket to be on its own line, for symmetry.
> Agreed - I've never much cared for egyptian braces. Another "evil" to me
> is this sort of if/else construct, a riff on egyptian bracing:
> if (foo) {
> bar(foo);
> } else {
> baz(foo);
> }
> That "} else {" hanging there makes my brain itch!
Well, I like the } else {, but I can live without it. However your
spacing is messed up, the brackets have to align with the if. That's
non-negotiable.
if (foo) {
bar(foo);
}
else {
baz(foo);
}
Is perfectly acceptable.
> Remind me again - How many of us here have OCD? :)
It's not OCD, I just like things to be RIGHT!.
--
I take my advice from the advertising world, "Treat me nice," says the
party girl. Coke adds life where there isn't any
[toc] | [prev] | [next] | [standalone]
| From | Walter Bushell <proto@panix.com> |
|---|---|
| Date | 2014-04-13 15:06 -0400 |
| Message-ID | <proto-D537D2.15061213042014@news.panix.com> |
| In reply to | #57152 |
In article <slrnlgsu6j.16s.g.kreme@oswin.local>, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote: > > > Remind me again - How many of us here have OCD? :) > > It's not OCD, I just like things to be RIGHT!. And it properly called CDO. -- Never attribute to stupidity that which can be explained by greed. Me.
[toc] | [prev] | [next] | [standalone]
| From | Tom Stiller <clusterfux.upmon@gmail.com> |
|---|---|
| Date | 2014-04-13 21:11 +0000 |
| Message-ID | <br0crcFp0ctU1@mid.individual.net> |
| In reply to | #58526 |
On 2014-04-13, Walter Bushell <proto@panix.com> wrote: > In article <slrnlgsu6j.16s.g.kreme@oswin.local>, > Lewis <g.kreme@gmail.com.dontsendmecopies> wrote: > >> >> > Remind me again - How many of us here have OCD? :) >> >> It's not OCD, I just like things to be RIGHT!. > > And it properly called CDO. > Hmmmm; I would have thought COD.
[toc] | [prev] | [next] | [standalone]
| From | Walter Bushell <proto@panix.com> |
|---|---|
| Date | 2014-04-15 17:03 -0400 |
| Message-ID | <proto-882CD8.17034515042014@news.panix.com> |
| In reply to | #58537 |
In article <br0crcFp0ctU1@mid.individual.net>, Tom Stiller <clusterfux.upmon@gmail.com> wrote: > On 2014-04-13, Walter Bushell <proto@panix.com> wrote: > > In article <slrnlgsu6j.16s.g.kreme@oswin.local>, > > Lewis <g.kreme@gmail.com.dontsendmecopies> wrote: > > > >> > >> > Remind me again - How many of us here have OCD? :) > >> > >> It's not OCD, I just like things to be RIGHT!. > > > > And it properly called CDO. > > > Hmmmm; I would have thought COD. No CDO is in proper alphabetical order as it should be. -- Never attribute to stupidity that which can be explained by greed. Me.
[toc] | [prev] | [next] | [standalone]
| From | Your Name <YourName@YourISP.com> |
|---|---|
| Date | 2014-04-16 09:29 +1200 |
| Message-ID | <160420140929175077%YourName@YourISP.com> |
| In reply to | #58526 |
In article <proto-D537D2.15061213042014@news.panix.com>, Walter Bushell <proto@panix.com> wrote: > In article <slrnlgsu6j.16s.g.kreme@oswin.local>, > Lewis <g.kreme@gmail.com.dontsendmecopies> wrote: > > > > > > Remind me again - How many of us here have OCD? :) > > > > It's not OCD, I just like things to be RIGHT!. > > And it properly called CDO. It's properly called "not being a lazy-ass unlike most people these days". ;-)
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-25 19:29 -0500 |
| Message-ID | <g46dnUyv66zKqJDOnZ2dnUVZ_vidnZ2d@giganews.com> |
| In reply to | #57071 |
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;
--
... 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 | Bill Findlay <yaldnif.w@blueyonder.co.uk> |
|---|---|
| Date | 2014-02-26 00:49 +0000 |
| Message-ID | <CF32EA7D.43021%yaldnif.w@blueyonder.co.uk> |
| In reply to | #57096 |
On 26/02/2014 00:29, 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;
Or in Ada:
while cond1 loop
if cond436 then
...
else
...
end if;
end loop;
More concise, and virtually blunder-proof, unlike Pascal with its
unforgivable dangling else problem.
--
Bill Findlay
with blueyonder.co.uk;
use surname & forename;
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-25 19:59 -0500 |
| Message-ID | <V9CdndNLbp0SoZDOnZ2dnUVZ_rqdnZ2d@giganews.com> |
| In reply to | #57100 |
On 2014.02.25, 19:49 , Bill Findlay wrote:
> On 26/02/2014 00:29, 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
end // sorry 'bout that.
>> else
> begin // and that!
>>
>> end
>> Else
>>
>> End;
>> END;
>
> Or in Ada:
>
> while cond1 loop
> if cond436 then
> ...
> else
> ...
> end if;
> end loop;
>
> More concise, and virtually blunder-proof, unlike Pascal with its
> unforgivable dangling else problem.
Not really after the else you can have a single statement or a begin end
block; yes there is the dangler - but when faced with it, begin end
makes it all nice and dandy.
Is there repeat in Ada?
Repeat
stuff (something);
more (other);
Until something or other;
To me repeat/until is one of the nicest contructs in any language.
Beats the crap out of "while x do ..."
--
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-26 02:03 +0000 |
| Message-ID | <CF32FBF0.43035%yaldnif.w@blueyonder.co.uk> |
| In reply to | #57102 |
On 26/02/2014 00:59, in article V9CdndNLbp0SoZDOnZ2dnUVZ_rqdnZ2d@giganews.com, "Alan Browne" <alan.browne@FreelunchVideotron.ca> wrote: > On 2014.02.25, 19:49 , Bill Findlay wrote: >> On 26/02/2014 00:29, 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 > > > end // sorry 'bout that. > >>> else >> begin // and that! >>> >>> end >>> Else >>> >>> End; >>> END; >> >> Or in Ada: >> >> while cond1 loop >> if cond436 then >> ... >> else >> ... >> end if; >> end loop; >> >> More concise, and virtually blunder-proof, unlike Pascal with its >> unforgivable dangling else problem. > > Not really after the else you can have a single statement or a begin end > block; yes there is the dangler - but when faced with it, begin end > makes it all nice and dandy. If you remember. > Is there repeat in Ada? > > Repeat > stuff (something); > more (other); > Until something or other; More general: loop ... exit when ...; ... end loop; Actually, you can have as many exits as you want, but it is very rare to need more than one. And you can put exits into while and for loop bodies, which is often the clearest way of dealing with multiple termination conditions. Special case: loop ... exit when ...; end loop; Gives repeat ... until functionality. > To me repeat/until is one of the nicest contructs in any language. > Beats the crap out of "while x do ..." I can't agree with that. while ... is usually the appropriate form (forgetting for ... for the moment), but repeat ... is the right thing to use when it's the right thing to use, and you should not have to force while ... to do your bidding. Horses for courses. -- Bill Findlay with blueyonder.co.uk; use surname & forename;
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-25 22:13 -0500 |
| Message-ID | <yredndhWSc1WxpDOnZ2dnUVZ_v-dnZ2d@giganews.com> |
| In reply to | #57105 |
On 2014.02.25, 21:03 , Bill Findlay wrote:
> On 26/02/2014 00:59, in article
> V9CdndNLbp0SoZDOnZ2dnUVZ_rqdnZ2d@giganews.com, "Alan Browne"
>>> More concise, and virtually blunder-proof, unlike Pascal with its
>>> unforgivable dangling else problem.
>>
>> Not really after the else you can have a single statement or a begin end
>> block; yes there is the dangler - but when faced with it, begin end
>> makes it all nice and dandy.
>
> If you remember.
You're reminded on that famous condition: debugging
>> Is there repeat in Ada?
>>
>> Repeat
>> stuff (something);
>> more (other);
>> Until something or other;
>
> More general:
>
> loop
> ...
> exit when ...;
> ...
> end loop;
Ouch. That is ugly
>
> Actually, you can have as many exits as you want, but it is very rare to
That could be useful - I do some GPS decoding where there a lot of
conditions (error) that result in an exit from the procedure in mid
course - that precludes action before the procedure/function returns.
eg: set the fail state then do the processing, if successful, then the
fail state is cleared, if exited, the fail state is already set.
> need more than one. And you can put exits into while and for loop bodies,
> which is often the clearest way of dealing with multiple termination
> conditions.
>
> Special case:
>
> loop
> ...
> exit when ...;
> end loop;
>
> Gives repeat ... until functionality.
Good 'nuff. I'll try to get gnat up this weekend.
>> To me repeat/until is one of the nicest contructs in any language.
>> Beats the crap out of "while x do ..."
>
> I can't agree with that.
> while ... is usually the appropriate form (forgetting for ... for the
> moment), but repeat ... is the right thing to use when it's the right
> thing to use, and you should not have to force while ... to do your bidding.
I think "do while" came about mainly for file operations to avoid having
having to handle an empty file before something like a repeat loop - as
well as perhaps "priming" the read state before starting the loop.
Since I assume an existing GPS recording has at least some data in it,
repeat until works fine.
--
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 | Bill Findlay <yaldnif.w@blueyonder.co.uk> |
|---|---|
| Date | 2014-02-26 14:03 +0000 |
| Message-ID | <CF33A49A.43098%yaldnif.w@blueyonder.co.uk> |
| In reply to | #57114 |
On 26/02/2014 03:13, in article yredndhWSc1WxpDOnZ2dnUVZ_v-dnZ2d@giganews.com, "Alan Browne" <alan.browne@FreelunchVideotron.ca> wrote: > On 2014.02.25, 21:03 , Bill Findlay wrote: >> On 26/02/2014 00:59, in article >> V9CdndNLbp0SoZDOnZ2dnUVZ_rqdnZ2d@giganews.com, "Alan Browne" > >>>> More concise, and virtually blunder-proof, unlike Pascal with its >>>> unforgivable dangling else problem. >>> >>> Not really after the else you can have a single statement or a begin end >>> block; yes there is the dangler - but when faced with it, begin end >>> makes it all nice and dandy. >> >> If you remember. > > You're reminded on that famous condition: debugging Too late. I want to write my s/w so I don't have to debug it. Not 100% achievable, of course, but the closer you can get to that condition at compile-time, the better. >> loop >> ... >> exit when ...; >> ... >> end loop; > > Ouch. That is ugly The eye of the beholder. I think it is very neat. >>> To me repeat/until is one of the nicest contructs in any language. >>> Beats the crap out of "while x do ..." >> >> I can't agree with that. >> while ... is usually the appropriate form (forgetting for ... for the >> moment), but repeat ... is the right thing to use when it's the right >> thing to use, and you should not have to force while ... to do your bidding. > > I think "do while" came about mainly for file operations to avoid having > having to handle an empty file before something like a repeat loop - as > well as perhaps "priming" the read state before starting the loop. Also scanning any container data structure that could be empty, a very common usage indeed. > Since I assume an existing GPS recording has at least some data in it, > repeat until works fine. "It can't happen, because ..." That is the attitude that leads to many, many s/w security breaches. -- Bill Findlay with blueyonder.co.uk; use surname & forename;
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2014-02-26 23:42 +0000 |
| Message-ID | <slrnlgsuu8.16s.g.kreme@oswin.local> |
| In reply to | #57114 |
In message <yredndhWSc1WxpDOnZ2dnUVZ_v-dnZ2d@giganews.com> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: > On 2014.02.25, 21:03 , Bill Findlay wrote: >> On 26/02/2014 00:59, in article >> V9CdndNLbp0SoZDOnZ2dnUVZ_rqdnZ2d@giganews.com, "Alan Browne" >>>> More concise, and virtually blunder-proof, unlike Pascal with its >>>> unforgivable dangling else problem. >>> >>> Not really after the else you can have a single statement or a begin end >>> block; yes there is the dangler - but when faced with it, begin end >>> makes it all nice and dandy. >> >> If you remember. > You're reminded on that famous condition: debugging "I pressed debug. Program still has bugs, WTF?!" -R*ch -- NOTHING IS FINAL. NOTHING IS ABSOLUTE. EXCEPT ME, OF COURSE. SUCH TINKERING WITH DESTINY COULD MEAN THE DOWNFALL OF THE WORLD. THERE MUST BE A CHANCE, HOWEVER SMALL. THE LAWYERS OF FATE DEMAND A LOOPHOLE IN EVERY PROPHECY. --Sourcery
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-27 17:03 -0500 |
| Message-ID | <t6mdnQUS_oKvK5LOnZ2dnUVZ_gidnZ2d@giganews.com> |
| In reply to | #57155 |
On 2014.02.26, 18:42 , Lewis wrote:
> In message <yredndhWSc1WxpDOnZ2dnUVZ_v-dnZ2d@giganews.com>
> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> On 2014.02.25, 21:03 , Bill Findlay wrote:
>>> On 26/02/2014 00:59, in article
>>> V9CdndNLbp0SoZDOnZ2dnUVZ_rqdnZ2d@giganews.com, "Alan Browne"
>
>>>>> More concise, and virtually blunder-proof, unlike Pascal with its
>>>>> unforgivable dangling else problem.
>>>>
>>>> Not really after the else you can have a single statement or a begin end
>>>> block; yes there is the dangler - but when faced with it, begin end
>>>> makes it all nice and dandy.
>>>
>>> If you remember.
>
>> You're reminded on that famous condition: debugging
>
> "I pressed debug. Program still has bugs, WTF?!" -R*ch
LOL.
--
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 | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-02-26 02:47 +0000 |
| Message-ID | <bn52u8Fgm4aU3@mid.individual.net> |
| In reply to | #57102 |
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;
>
> To me repeat/until is one of the nicest contructs in any language.
> Beats the crap out of "while x do ..."
Perl has a nice construct for this:
until ($a == 0)
{
// something
}
In others (C, PHP, and so on), you'd have to write something like:
do
{
// something
}
while ($a != 0);
And in AppleScript, you can do:
repeat until a equals 0
-- something
end repeat
--
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]
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | comp.sys.mac.system
csiph-web