Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #26180 > unrolled thread
| Started by | Tim Wescott <seemywebsite@myfooter.really> |
|---|---|
| First post | 2017-03-23 18:17 -0500 |
| Last post | 2017-03-26 14:43 +0200 |
| Articles | 20 on this page of 64 — 13 participants |
Back to article view | Back to comp.arch.embedded
Dimension of a matrix Tim Wescott <seemywebsite@myfooter.really> - 2017-03-23 18:17 -0500
Re: Dimension of a matrix Paul Rubin <no.email@nospam.invalid> - 2017-03-23 23:21 -0700
Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-24 09:18 +0100
Type-safety and C++, was: Re: Dimension of a matrix Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-24 18:24 +0000
Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-24 19:32 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix Stefan Reuther <stefan.news@arcor.de> - 2017-03-25 09:59 +0100
Re: Type-safety and C++, was: Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-25 13:08 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-25 01:57 +0100
Re: Type-safety and C++, was: Re: Dimension of a matrix Clifford Heath <no.spam@please.net> - 2017-03-25 18:34 +1100
Re: Type-safety and C++, was: Re: Dimension of a matrix Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-26 23:53 +0000
Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-27 09:51 +0200
Re: Type-safety and C++, was: Re: Dimension of a matrix Clifford Heath <no.spam@please.net> - 2017-03-27 20:19 +1100
Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-27 12:17 +0200
Re: Type-safety and C++, was: Re: Dimension of a matrix Paul Rubin <no.email@nospam.invalid> - 2017-03-25 09:20 -0700
Re: Type-safety and C++, was: Re: Dimension of a matrix George Neuner <gneuner2@comcast.net> - 2017-03-24 23:14 -0400
Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-25 11:07 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix George Neuner <gneuner2@comcast.net> - 2017-03-26 05:45 -0400
Re: Type-safety and C++, was: Re: Dimension of a matrix Wouter van Ooijen <wouter@voti.nl> - 2017-03-26 13:14 +0200
Re: Type-safety and C++, was: Re: Dimension of a matrix Paul Rubin <no.email@nospam.invalid> - 2017-03-26 11:08 -0700
Re: Type-safety and C++, was: Re: Dimension of a matrix Wouter van Ooijen <wouter@voti.nl> - 2017-03-26 20:24 +0200
Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-26 15:16 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-27 00:09 +0000
Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <seemywebsite@myfooter.really> - 2017-03-26 19:43 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-27 16:57 +0100
Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-27 11:53 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-27 22:04 +0200
Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <seemywebsite@myfooter.really> - 2017-03-27 18:32 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix Clifford Heath <no.spam@please.net> - 2017-03-28 11:03 +1100
Re: Type-safety and C++, was: Re: Dimension of a matrix Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-27 22:07 +0100
Re: Type-safety and C++, was: Re: Dimension of a matrix Paul Rubin <no.email@nospam.invalid> - 2017-03-27 23:42 -0700
Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-28 09:22 +0200
Re: Type-safety and C++, was: Re: Dimension of a matrix Paul Rubin <no.email@nospam.invalid> - 2017-03-28 00:42 -0700
Re: Type-safety and C++, was: Re: Dimension of a matrix Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-28 09:07 +0100
Re: Type-safety and C++, was: Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-28 19:34 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-29 11:39 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-28 19:29 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-29 10:31 +0200
Re: Type-safety and C++, was: Re: Dimension of a matrix Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-30 00:23 +0000
Re: Type-safety and C++, was: Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-29 19:31 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix Phil Martel <pomartel@comcast.net> - 2017-03-30 11:51 -0400
Re: Type-safety and C++, was: Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-30 19:16 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-31 09:21 +0200
Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <seemywebsite@myfooter.really> - 2017-03-28 14:19 -0500
Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-24 11:05 -0500
Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-24 17:33 +0100
Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-24 12:09 -0500
Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-25 13:09 -0500
Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-25 13:05 -0500
Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-24 09:20 +0100
Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-25 13:12 -0500
Re: Dimension of a matrix Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-03-25 20:08 +0100
Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-25 15:17 -0500
Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-26 17:32 +0200
Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-26 11:55 -0500
Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-26 21:23 +0200
Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-29 19:36 -0500
Re: Dimension of a matrix Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-30 00:36 +0000
Re: Dimension of a matrix Paul Rubin <no.email@nospam.invalid> - 2017-03-29 19:55 -0700
Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-30 09:49 +0200
Re: Dimension of a matrix Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-30 18:07 +0000
Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-30 09:47 +0200
Re: Dimension of a matrix Wouter van Ooijen <wouter@voti.nl> - 2017-03-25 19:08 +0100
Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-25 15:21 -0500
Re: Dimension of a matrix Wouter van Ooijen <wouter@voti.nl> - 2017-03-26 14:43 +0200
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2017-03-26 15:16 -0500 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <R6adneq4lKodvEXFnZ2dnUU7-TOdnZ2d@giganews.com> |
| In reply to | #26276 |
On Sun, 26 Mar 2017 05:45:54 -0400, George Neuner wrote: > On Sat, 25 Mar 2017 11:07:30 -0500, Tim Wescott <tim@seemywebsite.com> > wrote: > >>On Fri, 24 Mar 2017 23:14:36 -0400, George Neuner wrote: >> >>> On Fri, 24 Mar 2017 18:24:44 -0000 (UTC), Simon Clubley >>> <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote: >>> >>>>In the C++ library, it would be nice if the indexing operator most >>>>people would use by default, "[]", was the bounds checked one and the >>>>alternative indexing operator, "at()", was the non-bounds checked one. >>>>That way, you would have to do something unusual in your code to turn >>>>_off_ bounds checking instead of having to do something unusual in >>>>your code to turn _on_ bounds checking... >>> >>> Agreed. However, that would violate the C/C++ mantra that those who >>> do not want a feature should not have to pay for it. >>> >>> Strict bounds checking - particularly checks per dimension as opposed >>> to a single check that the overall target lies within the array - >>> would break some existing code. >>> [For the same reasons that pointers may be one-of before or after the >>> array, and iterators may be considered to point "between" elements.] >> >>We're talking about the C++ STL "array" class, which is defined as >>having a certain size, with no guarantees about what lies outside the >>range of the actual data. > > Yes. But not every array in C++ uses the STL class, and I was reacting > to Simon's comment about the '[]' index operator. > > It would be hopelessly confusing if the index operator of the array > class was checked, but the general (C compatible) index operator was > not. If the general operator were checked, undoubtedly some code would > break, and even though STL arrays are heap allocated with some overrun > slop, I suspect that checking the operator there also would break some > existing code. > [Not that breaking crappy code is a bad thing ... 8-) ] Changing the behavior of the '[]' operator in native C++ code is a completely different class of change than changing the behavior of the '[]' operator in a library. The first requires a change to the underlying language definition, while the second is only a change to the library code. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> |
|---|---|
| Date | 2017-03-27 00:09 +0000 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <ob9l8b$h4j$2@dont-email.me> |
| In reply to | #26290 |
On 2017-03-26, Tim Wescott <tim@seemywebsite.com> wrote: > > Changing the behavior of the '[]' operator in native C++ code is a > completely different class of change than changing the behavior of the > '[]' operator in a library. The first requires a change to the > underlying language definition, while the second is only a change to the > library code. > In an ideal world, I wouldn't mind seeing the first one become reality either. Yes, it would break some bad code, but that existing code could easily be a CVE just waiting to happen. Simon. PS: And yes, I know about the C++ speed over safety design goals... :-) -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <seemywebsite@myfooter.really> |
|---|---|
| Date | 2017-03-26 19:43 -0500 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <d9GdnTa0nuCg_UXFnZ2dnUU7-K2dnZ2d@giganews.com> |
| In reply to | #26295 |
On Mon, 27 Mar 2017 00:09:48 +0000, Simon Clubley wrote: > On 2017-03-26, Tim Wescott <tim@seemywebsite.com> wrote: >> >> Changing the behavior of the '[]' operator in native C++ code is a >> completely different class of change than changing the behavior of the >> '[]' operator in a library. The first requires a change to the >> underlying language definition, while the second is only a change to >> the library code. >> >> > In an ideal world, I wouldn't mind seeing the first one become reality > either. Yes, it would break some bad code, but that existing code could > easily be a CVE just waiting to happen. I think that would have so many ugly tentacles extending into all parts of how C natively handles arrays that it would be a nightmare all around. Much better to just have people remember that '[]' is inherently unsafe, and Pay Attention, imho. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-27 16:57 +0100 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <jDaCA.285646$FF4.12474@fx27.am4> |
| In reply to | #26297 |
On 27/03/17 01:43, Tim Wescott wrote: > On Mon, 27 Mar 2017 00:09:48 +0000, Simon Clubley wrote: > >> On 2017-03-26, Tim Wescott <tim@seemywebsite.com> wrote: >>> >>> Changing the behavior of the '[]' operator in native C++ code is a >>> completely different class of change than changing the behavior of the >>> '[]' operator in a library. The first requires a change to the >>> underlying language definition, while the second is only a change to >>> the library code. >>> >>> >> In an ideal world, I wouldn't mind seeing the first one become reality >> either. Yes, it would break some bad code, but that existing code could >> easily be a CVE just waiting to happen. > > I think that would have so many ugly tentacles extending into all parts > of how C natively handles arrays that it would be a nightmare all around. > > Much better to just have people remember that '[]' is inherently unsafe, > and Pay Attention, imho. And my, that theory has worked out well in practice, hasn't it. :(
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2017-03-27 11:53 -0500 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <q7ydnQkIucY73kTFnZ2dnUU7-fWdnZ2d@giganews.com> |
| In reply to | #26310 |
On Mon, 27 Mar 2017 16:57:02 +0100, Tom Gardner wrote: > On 27/03/17 01:43, Tim Wescott wrote: >> On Mon, 27 Mar 2017 00:09:48 +0000, Simon Clubley wrote: >> >>> On 2017-03-26, Tim Wescott <tim@seemywebsite.com> wrote: >>>> >>>> Changing the behavior of the '[]' operator in native C++ code is a >>>> completely different class of change than changing the behavior of >>>> the '[]' operator in a library. The first requires a change to the >>>> underlying language definition, while the second is only a change to >>>> the library code. >>>> >>>> >>> In an ideal world, I wouldn't mind seeing the first one become reality >>> either. Yes, it would break some bad code, but that existing code >>> could easily be a CVE just waiting to happen. >> >> I think that would have so many ugly tentacles extending into all parts >> of how C natively handles arrays that it would be a nightmare all >> around. >> >> Much better to just have people remember that '[]' is inherently >> unsafe, and Pay Attention, imho. > > And my, that theory has worked out well in practice, hasn't it. :( I don't write many bugs that have to do with overrunning array boundaries, particularly because I both inspect and test for it. I certainly do plenty of other dumbass things, because I'm not human. There's always Ada if that sort of thing is a concern -- and you don't have to completely change the semantics of arrays to make it work, because Ada arrays have that set of semantics built in. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-27 22:04 +0200 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <obbr2i$79k$1@dont-email.me> |
| In reply to | #26314 |
On 27/03/17 18:53, Tim Wescott wrote: > I don't write many bugs that have to do with overrunning array > boundaries, particularly because I both inspect and test for it. I > certainly do plenty of other dumbass things, because I'm not human. Ah ha! I always had my suspicions about you. Those videos you published are just a con to make us /think/ you are human!
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <seemywebsite@myfooter.really> |
|---|---|
| Date | 2017-03-27 18:32 -0500 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <IpednV4h-oG1PETFnZ2dnUU7-amdnZ2d@giganews.com> |
| In reply to | #26317 |
On Mon, 27 Mar 2017 22:04:16 +0200, David Brown wrote: > On 27/03/17 18:53, Tim Wescott wrote: >> I don't write many bugs that have to do with overrunning array >> boundaries, particularly because I both inspect and test for it. I >> certainly do plenty of other dumbass things, because I'm not human. > > Ah ha! I always had my suspicions about you. Those videos you > published are just a con to make us /think/ you are human! Fucking LISP. I think my programmer -- er, DAD put an extra pair of parentheses in there someplace. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2017-03-28 11:03 +1100 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <58d9a83b$0$22690$c3e8da3$33881b6a@news.astraweb.com> |
| In reply to | #26320 |
On 28/03/17 10:32, Tim Wescott wrote: > On Mon, 27 Mar 2017 22:04:16 +0200, David Brown wrote: > >> On 27/03/17 18:53, Tim Wescott wrote: >>> I don't write many bugs that have to do with overrunning array >>> boundaries, particularly because I both inspect and test for it. I >>> certainly do plenty of other dumbass things, because I'm not human. >> >> Ah ha! I always had my suspicions about you. Those videos you >> published are just a con to make us /think/ you are human! > > Fucking LISP. I think my programmer -- er, DAD put an extra pair of > parentheses in there someplace. Giving you bow-legs? As the Bard was reported to have said of a bow-legged man: Forsooth what manner of man is this, that carries his balls in parentheses?
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-27 22:07 +0100 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <7afCA.164813$ez1.63979@fx32.am4> |
| In reply to | #26314 |
On 27/03/17 17:53, Tim Wescott wrote: > On Mon, 27 Mar 2017 16:57:02 +0100, Tom Gardner wrote: > >> On 27/03/17 01:43, Tim Wescott wrote: >>> On Mon, 27 Mar 2017 00:09:48 +0000, Simon Clubley wrote: >>> >>>> On 2017-03-26, Tim Wescott <tim@seemywebsite.com> wrote: >>>>> >>>>> Changing the behavior of the '[]' operator in native C++ code is a >>>>> completely different class of change than changing the behavior of >>>>> the '[]' operator in a library. The first requires a change to the >>>>> underlying language definition, while the second is only a change to >>>>> the library code. >>>>> >>>>> >>>> In an ideal world, I wouldn't mind seeing the first one become reality >>>> either. Yes, it would break some bad code, but that existing code >>>> could easily be a CVE just waiting to happen. >>> >>> I think that would have so many ugly tentacles extending into all parts >>> of how C natively handles arrays that it would be a nightmare all >>> around. >>> >>> Much better to just have people remember that '[]' is inherently >>> unsafe, and Pay Attention, imho. >> >> And my, that theory has worked out well in practice, hasn't it. :( > > I don't write many bugs that have to do with overrunning array > boundaries, particularly because I both inspect and test for it. I > certainly do plenty of other dumbass things, because I'm not human. Excellent. How do you suggest we clone your special powers a few million times? :) > There's always Ada if that sort of thing is a concern -- and you don't > have to completely change the semantics of arrays to make it work, > because Ada arrays have that set of semantics built in. Who was it who said something to the effect that if the answer doesn't have to give correct results, then the program can be made arbitrarily fast and arbitrarily small and written arbitrarily soon? ISTR Wirth or Dijkstra.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-27 23:42 -0700 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <87shlxuclb.fsf@nightsong.com> |
| In reply to | #26314 |
Tim Wescott <tim@seemywebsite.com> writes: > I don't write many bugs that have to do with overrunning array > boundaries, particularly because I both inspect and test for it. It helps if you're writing embedded code, which tends to not deal with too much variable sized data or have complicated control flow. Otherwise how can you really tell? Inspection stops helping much once the program is large enough. Do you do any fuzz testing etc.?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-28 09:22 +0200 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <obd2p6$c2r$1@dont-email.me> |
| In reply to | #26322 |
On 28/03/17 08:42, Paul Rubin wrote: > Tim Wescott <tim@seemywebsite.com> writes: >> I don't write many bugs that have to do with overrunning array >> boundaries, particularly because I both inspect and test for it. > > It helps if you're writing embedded code, which tends to not deal with > too much variable sized data or have complicated control flow. > Otherwise how can you really tell? Inspection stops helping much once > the program is large enough. Do you do any fuzz testing etc.? > I think the key point is program design, rather than testing. Testing can help show that you /have/ bugs, it doesn't show that you /don't/ have bugs. I don't have many bugs involving overrunning arrays either (despite being a mere human). I just make sure I know the size of my arrays when I use them.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-28 00:42 -0700 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <87lgrpu9td.fsf@nightsong.com> |
| In reply to | #26323 |
David Brown <david.brown@hesbynett.no> writes: > I don't have many bugs involving overrunning arrays either (despite > being a mere human). I just make sure I know the size of my arrays when > I use them. That's what everyone says, yet those bugs keep turning up ;-).
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-28 09:07 +0100 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <KQoCA.339496$4n3.143385@fx14.am4> |
| In reply to | #26323 |
On 28/03/17 08:22, David Brown wrote: > On 28/03/17 08:42, Paul Rubin wrote: >> Tim Wescott <tim@seemywebsite.com> writes: >>> I don't write many bugs that have to do with overrunning array >>> boundaries, particularly because I both inspect and test for it. >> >> It helps if you're writing embedded code, which tends to not deal with >> too much variable sized data or have complicated control flow. >> Otherwise how can you really tell? Inspection stops helping much once >> the program is large enough. Do you do any fuzz testing etc.? >> > > I think the key point is program design, rather than testing. Testing > can help show that you /have/ bugs, it doesn't show that you /don't/ > have bugs. Try telling that to the XP/TDD brigade who have been taught by external consultants - "but there's a green light after testing" :( Mentioning the old aphorism that "you can't test quality into a product" usually meets blank incomprehension, and only rarely a glimmer of enlightenment.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-03-28 19:34 -0500 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <obev1v$lcb$1@dont-email.me> |
| In reply to | #26325 |
Tom Gardner wrote: > On 28/03/17 08:22, David Brown wrote: >> On 28/03/17 08:42, Paul Rubin wrote: >>> Tim Wescott <tim@seemywebsite.com> writes: >>>> I don't write many bugs that have to do with overrunning array >>>> boundaries, particularly because I both inspect and test for it. >>> >>> It helps if you're writing embedded code, which tends to not deal with >>> too much variable sized data or have complicated control flow. >>> Otherwise how can you really tell? Inspection stops helping much once >>> the program is large enough. Do you do any fuzz testing etc.? >>> >> >> I think the key point is program design, rather than testing. Testing >> can help show that you /have/ bugs, it doesn't show that you /don't/ >> have bugs. > > Try telling that to the XP/TDD brigade who have > been taught by external consultants - "but there's > a green light after testing" :( > > Mentioning the old aphorism that "you can't > test quality into a product" usually meets blank > incomprehension, and only rarely a glimmer of > enlightenment. > That's not how this works. Tests that catch bugs early save money. The other problem is that people take as a corollary "so don't bother testing." Zero defects is unattainable. 10^-x defects isn't. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2017-03-29 11:39 -0500 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <iY2dnYkkLPTNfkbFnZ2dnUU7-cednZ2d@giganews.com> |
| In reply to | #26325 |
On Tue, 28 Mar 2017 09:07:06 +0100, Tom Gardner wrote: > On 28/03/17 08:22, David Brown wrote: >> On 28/03/17 08:42, Paul Rubin wrote: >>> Tim Wescott <tim@seemywebsite.com> writes: >>>> I don't write many bugs that have to do with overrunning array >>>> boundaries, particularly because I both inspect and test for it. >>> >>> It helps if you're writing embedded code, which tends to not deal with >>> too much variable sized data or have complicated control flow. >>> Otherwise how can you really tell? Inspection stops helping much once >>> the program is large enough. Do you do any fuzz testing etc.? >>> >>> >> I think the key point is program design, rather than testing. Testing >> can help show that you /have/ bugs, it doesn't show that you /don't/ >> have bugs. > > Try telling that to the XP/TDD brigade who have been taught by external > consultants - "but there's a green light after testing" :( The one guy I know in the "TDD brigade" (James Grenning) would tell you that if someone came away with that conclusion then either they weren't listening or the consultant wasn't teaching the whole TDD mantra. > Mentioning the old aphorism that "you can't test quality into a product" > usually meets blank incomprehension, and only rarely a glimmer of > enlightenment. You can't test quality into a product overall, because the number of tests you need to run becomes functionally infinite. But if your individual functional units are simple enough, you can cover all the bases in your unit testing. It's still a matter of external analysis to make sure that (a) the specifications for the units guarantee that the whole will work when they're roped together, and (b) the unit tests are sufficient. I do know this about TDD: on those parts of the code where I can and do implement it, I get things running sooner and with less fuss than on those parts where I start by saying "oh, I don't need to do this" or "oh, this will be too hard to do 'cuz it's embedded". -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-03-28 19:29 -0500 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <obeuni$kkv$1@dont-email.me> |
| In reply to | #26323 |
David Brown wrote: > On 28/03/17 08:42, Paul Rubin wrote: >> Tim Wescott <tim@seemywebsite.com> writes: >>> I don't write many bugs that have to do with overrunning array >>> boundaries, particularly because I both inspect and test for it. >> >> It helps if you're writing embedded code, which tends to not deal with >> too much variable sized data or have complicated control flow. >> Otherwise how can you really tell? Inspection stops helping much once >> the program is large enough. Do you do any fuzz testing etc.? >> > > I think the key point is program design, rather than testing. Testing > can help show that you /have/ bugs, it doesn't show that you /don't/ > have bugs. > But design is about constraints, and testing can show that constraints are met. That has a seriously Pareto ( 90/10 ) effect on development outcomes. The other 10 percent takes the other 90 percent of time allotted. > I don't have many bugs involving overrunning arrays either (despite > being a mere human). I just make sure I know the size of my arrays when > I use them. > Me too. Apparently, that is too hard and we'll all suffer deadly incursions. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-29 10:31 +0200 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <obfr85$g0i$1@dont-email.me> |
| In reply to | #26329 |
On 29/03/17 02:29, Les Cargill wrote: > David Brown wrote: >> On 28/03/17 08:42, Paul Rubin wrote: >>> Tim Wescott <tim@seemywebsite.com> writes: >>>> I don't write many bugs that have to do with overrunning array >>>> boundaries, particularly because I both inspect and test for it. >>> >>> It helps if you're writing embedded code, which tends to not deal with >>> too much variable sized data or have complicated control flow. >>> Otherwise how can you really tell? Inspection stops helping much once >>> the program is large enough. Do you do any fuzz testing etc.? >>> >> >> I think the key point is program design, rather than testing. Testing >> can help show that you /have/ bugs, it doesn't show that you /don't/ >> have bugs. >> > > But design is about constraints, and testing can show that constraints > are met. That has a seriously Pareto ( 90/10 ) effect on development > outcomes. The other 10 percent takes the other 90 percent of time > allotted. > >> I don't have many bugs involving overrunning arrays either (despite >> being a mere human). I just make sure I know the size of my arrays when >> I use them. >> > > Me too. > > Apparently, that is too hard and we'll all suffer deadly incursions. > There are some kinds of defects that can be avoided by good design. Some kinds can be spotted by static error checking at compile time. And some kinds can be best spotted using tests. Array overruns are best avoided by good programming practice - you know exactly what size your array is when you use it. You don't make assumptions - make sure you /know/. And they are usually very hard to find by tests - the effect of an array overrun is typically "something odd is happening" because you have written to a different memory object unexpectedly. You cannot sensibly use run-time checks of array sizes, except occasionally during development. You can only check the array bounds on access if you know the bounds - and if you know the bounds during the access, then the code that makes the accesses already knows these bounds and should not attempt such accesses. At best, you might spot typographical errors - using "sizeOfInBuffer" when you meant "sizeOfOutBuffer".
[toc] | [prev] | [next] | [standalone]
| From | Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> |
|---|---|
| Date | 2017-03-30 00:23 +0000 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <obhj60$a4n$3@dont-email.me> |
| In reply to | #26331 |
On 2017-03-29, David Brown <david.brown@hesbynett.no> wrote: > > There are some kinds of defects that can be avoided by good design. > Some kinds can be spotted by static error checking at compile time. And > some kinds can be best spotted using tests. > > Array overruns are best avoided by good programming practice - you know > exactly what size your array is when you use it. You don't make > assumptions - make sure you /know/. And they are usually very hard to > find by tests - the effect of an array overrun is typically "something > odd is happening" because you have written to a different memory object > unexpectedly. > > You cannot sensibly use run-time checks of array sizes, except > occasionally during development. You can only check the array bounds on > access if you know the bounds - and if you know the bounds during the > access, then the code that makes the accesses already knows these bounds > and should not attempt such accesses. At best, you might spot > typographical errors - using "sizeOfInBuffer" when you meant > "sizeOfOutBuffer". > If you have to do those checks manually, then some developers might not include them or may remove them when building the production release. Leaving those checks (either manual or compiler generated) in the production build may stop your code from turning into a CVE if an attacker can influence your program logic via an external mechanism in a way that you never thought to test for during development. IOW, I do believe that run-time checks have a vital place, even in production use, especially in today's heavily interconnected world. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-03-29 19:31 -0500 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <obhj86$hb8$1@dont-email.me> |
| In reply to | #26331 |
David Brown wrote: > On 29/03/17 02:29, Les Cargill wrote: >> David Brown wrote: >>> On 28/03/17 08:42, Paul Rubin wrote: >>>> Tim Wescott <tim@seemywebsite.com> writes: >>>>> I don't write many bugs that have to do with overrunning >>>>> array boundaries, particularly because I both inspect and >>>>> test for it. >>>> >>>> It helps if you're writing embedded code, which tends to not >>>> deal with too much variable sized data or have complicated >>>> control flow. Otherwise how can you really tell? Inspection >>>> stops helping much once the program is large enough. Do you do >>>> any fuzz testing etc.? >>>> >>> >>> I think the key point is program design, rather than testing. >>> Testing can help show that you /have/ bugs, it doesn't show that >>> you /don't/ have bugs. >>> >> >> But design is about constraints, and testing can show that >> constraints are met. That has a seriously Pareto ( 90/10 ) effect >> on development outcomes. The other 10 percent takes the other 90 >> percent of time allotted. >> >>> I don't have many bugs involving overrunning arrays either >>> (despite being a mere human). I just make sure I know the size >>> of my arrays when I use them. >>> >> >> Me too. >> >> Apparently, that is too hard and we'll all suffer deadly >> incursions. >> > > There are some kinds of defects that can be avoided by good design. And that is really all this is. > Some kinds can be spotted by static error checking at compile time. > And some kinds can be best spotted using tests. > Static checking won't find much amongst people who have good self-checking habits. I've seen two cases where ancient code bases were cleaned up using static checkers, and it was mostly noise. Where static analysis shines is "before every checkin." But it all adds up. > Array overruns are best avoided by good programming practice - you > know exactly what size your array is when you use it. Now how hard was that? > You don't > make assumptions - make sure you /know/. And they are usually very > hard to find by tests - the effect of an array overrun is typically > "something odd is happening" because you have written to a different > memory object unexpectedly. > you effectively cannot reliably test for them. They must be prevented by other practices. > You cannot sensibly use run-time checks of array sizes, except > occasionally during development. You can only check the array bounds > on access if you know the bounds - and if you know the bounds during > the access, then the code that makes the accesses already knows these > bounds and should not attempt such accesses. Yep. > At best, you might > spot typographical errors - using "sizeOfInBuffer" when you meant > "sizeOfOutBuffer". > So I often start with "all buffers are the same size", and then reduce them as needed, using a typedef enum to ... enumerate all the possible sizes. In that case, you change one at a time, following it through its entire lifetime. If you can't follow it through its entire lifetime, then you have a much bigger problem. And to be totally honest, I'll at times "write an MMU" - have an array of struct of the addresses and lengths of all the buffers, then add extent checks that can be turned off. Most people who have buffer overrun problems have opaque void * style buffer being flung around. Tsk. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Phil Martel <pomartel@comcast.net> |
|---|---|
| Date | 2017-03-30 11:51 -0400 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <rQ9DA.159971$Ip6.32530@fx38.iad> |
| In reply to | #26344 |
On 3/29/2017 20:31, Les Cargill wrote: > David Brown wrote: >> On 29/03/17 02:29, Les Cargill wrote: >>> David Brown wrote: >>>> On 28/03/17 08:42, Paul Rubin wrote: >>>>> Tim Wescott <tim@seemywebsite.com> writes: >>>>>> I don't write many bugs that have to do with overrunning >>>>>> array boundaries, particularly because I both inspect and >>>>>> test for it. >>>>> >>>>> It helps if you're writing embedded code, which tends to not >>>>> deal with too much variable sized data or have complicated >>>>> control flow. Otherwise how can you really tell? Inspection >>>>> stops helping much once the program is large enough. Do you do >>>>> any fuzz testing etc.? >>>>> >>>> >>>> I think the key point is program design, rather than testing. >>>> Testing can help show that you /have/ bugs, it doesn't show that >>>> you /don't/ have bugs. >>>> >>> >>> But design is about constraints, and testing can show that >>> constraints are met. That has a seriously Pareto ( 90/10 ) effect >>> on development outcomes. The other 10 percent takes the other 90 >>> percent of time allotted. >>> >>>> I don't have many bugs involving overrunning arrays either >>>> (despite being a mere human). I just make sure I know the size >>>> of my arrays when I use them. >>>> >>> >>> Me too. >>> >>> Apparently, that is too hard and we'll all suffer deadly >>> incursions. >>> >> >> There are some kinds of defects that can be avoided by good design. > > And that is really all this is. > >> Some kinds can be spotted by static error checking at compile time. >> And some kinds can be best spotted using tests. >> > > Static checking won't find much amongst people who have good > self-checking habits. I've seen two cases where ancient > code bases were cleaned up using static checkers, and it was mostly > noise. > > Where static analysis shines is "before every checkin." But it > all adds up. > >> Array overruns are best avoided by good programming practice - you >> know exactly what size your array is when you use it. > > Now how hard was that? > >> You don't >> make assumptions - make sure you /know/. And they are usually very >> hard to find by tests - the effect of an array overrun is typically >> "something odd is happening" because you have written to a different >> memory object unexpectedly. >> > > you effectively cannot reliably test for them. They must be > prevented by other practices. > >> You cannot sensibly use run-time checks of array sizes, except >> occasionally during development. You can only check the array bounds >> on access if you know the bounds - and if you know the bounds during >> the access, then the code that makes the accesses already knows these >> bounds and should not attempt such accesses. > > Yep. I'd be concerned about code reuse. *I* will know about the array bounds and hopefully document them well and remember them when I pick up the code in six months. I'm not so sure that the next guy will do the right thing, particularly after I've left a project... > >> At best, you might >> spot typographical errors - using "sizeOfInBuffer" when you meant >> "sizeOfOutBuffer". >> > > So I often start with "all buffers are the same size", > and then reduce them as needed, using a typedef enum to ... > enumerate all the possible sizes. > > In that case, you change one at a time, following it through > its entire lifetime. If you can't follow it through its entire lifetime, > then you have a much bigger problem. > > And to be totally honest, I'll at times "write an MMU" - have an array > of struct of the addresses and lengths of all the buffers, then add > extent checks that can be turned off. > > Most people who have buffer overrun problems have opaque void * style > buffer being flung around. Tsk. > -- Best wishes, --Phil pomartel At Comcast(ignore_this) dot net
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web