Path: csiph.com!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Jolly Roger Newsgroups: comp.sys.mac.system Subject: Re: Latest IOS/OS X SSL security flaw Date: 23 Feb 2014 16:47:27 GMT Organization: People for the Ethical Treatment of Pirates Lines: 92 Message-ID: References: <220220141415089899%nospam@nospam.invalid> <2NWdnQXy6oxRY5XOnZ2dnUVZ_qSdnZ2d@giganews.com> X-Trace: individual.net /H776ysmdKFv6nBERk1zAgPvQtmI2/H6xMlWeMro6W+IWO4SFJ Cancel-Lock: sha1:GBdCMzIQK3HbgObulL4fyAck3uI= X-Face: _.g>n!a$f3/H3jA]>9pN55*5<`}Tud57>1Y%b|b-Y~()~\t,LZ3e up1/bO{=-) User-Agent: slrn/1.0.1 (Darwin) Xref: csiph.com comp.sys.mac.system:56901 On 2014-02-23, Don Bruder wrote: > In article , > Jolly Roger wrote: > >> On 2014-02-23, Alan Browne wrote: >> > On 2014.02.22, 16:30 , Jolly Roger wrote: >> >> On 2014-02-22, Alan Browne wrote: >> >>> On 2014.02.22, 14:15 , nospam wrote: >> >>>> In article , Ted Lee >> >>>> 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. >> >>>> >> >>>> >> >>> >> >>> 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 > } > specifically to negate even the possibility of getting bit by that > type of bug. Vertical space is cheap insurance :) Indeed! Like minds, there! (Only difference I tend not to indent th braces themselves.) Not everyone has the discipline or interest to do this. I am often praised for my code cleanliness and readability by others. So there are obviously other benefits to adhering to strict best practices like this. >> > 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? >> >> Right there with you. : ) I can appreciate shortened forms; but not >> so much when they increase the likelihood of mistakes like this. >> Pascal had BEGIN/END too. > > What? Never heard of > #define BEGIN { > #define END } > ? > :) > > Years ago, those, and other similar "translation" macros, were exactly > how I transitioned from Pascal to C. Then one day I noticed that the C > must have "kicked in" - I'd been using "naked" C and forgetting to > bother setting up or #include-ing the #defines for a while without > even realizing it. Haha! I did similar things during my transition! : D I'm glad I cut my teeth on Pascal before moving to C/C++. I think it gave me an appreciation for structure that I otherwise might not have attained. -- 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