Dimension of a matrix - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Type-safety and C++, was: Re: Dimension of a matrix
On Sun, 26 Mar 2017 05:45:54 -0400, George Neuner wrote:

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Type-safety and C++, was: Re: Dimension of a matrix
Quoted text here. Click to load it

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

Re: Type-safety and C++, was: Re: Dimension of a matrix
On Mon, 27 Mar 2017 00:09:48 +0000, Simon Clubley wrote:

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Type-safety and C++, was: Re: Dimension of a matrix
On 27/03/17 01:43, Tim Wescott wrote:
Quoted text here. Click to load it

And my, that theory has worked out well in practice, hasn't it. :(


Re: Type-safety and C++, was: Re: Dimension of a matrix
On Mon, 27 Mar 2017 16:57:02 +0100, Tom Gardner wrote:

Quoted text here. Click to load 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
We've slightly trimmed the long signature. Click to see the full one.
Re: Type-safety and C++, was: Re: Dimension of a matrix
On 27/03/17 18:53, Tim Wescott wrote:
Quoted text here. Click to load it

Ah ha!  I always had my suspicions about you.  Those videos you  
published are just a con to make us /think/ you are human!



Re: Type-safety and C++, was: Re: Dimension of a matrix
On 27/03/17 17:53, Tim Wescott wrote:
Quoted text here. Click to load it

Excellent.

How do you suggest we clone your special powers a few million
times? :)


Quoted text here. Click to load it

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.

Re: Type-safety and C++, was: Re: Dimension of a matrix
Quoted text here. Click to load 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.?

Re: Type-safety and C++, was: Re: Dimension of a matrix
On 28/03/17 08:42, Paul Rubin wrote:
Quoted text here. Click to load it

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.


Re: Type-safety and C++, was: Re: Dimension of a matrix
Quoted text here. Click to load it

That's what everyone says, yet those bugs keep turning up ;-).

Re: Type-safety and C++, was: Re: Dimension of a matrix
On 28/03/17 08:22, David Brown wrote:
Quoted text here. Click to load it

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.


Re: Type-safety and C++, was: Re: Dimension of a matrix
Tom Gardner wrote:
Quoted text here. Click to load it

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

Re: Type-safety and C++, was: Re: Dimension of a matrix
On Tue, 28 Mar 2017 09:07:06 +0100, Tom Gardner wrote:

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Type-safety and C++, was: Re: Dimension of a matrix
David Brown wrote:
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Me too.

Apparently, that is too hard and we'll all suffer deadly incursions.

--  
Les Cargill


Re: Type-safety and C++, was: Re: Dimension of a matrix
On 29/03/17 02:29, Les Cargill wrote:
Quoted text here. Click to load it

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".


Re: Type-safety and C++, was: Re: Dimension of a matrix
Quoted text here. Click to load it

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

Re: Type-safety and C++, was: Re: Dimension of a matrix
David Brown wrote:
Quoted text here. Click to load it

And that is really all this is.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Now how hard was that?

Quoted text here. Click to load it

you effectively cannot reliably test for them. They must be
prevented by other practices.

Quoted text here. Click to load it

Yep.


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

Re: Type-safety and C++, was: Re: Dimension of a matrix
On 3/29/2017 20:31, Les Cargill wrote:
Quoted text here. Click to load it
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...
Quoted text here. Click to load it


--  
Best wishes,
--Phil
We've slightly trimmed the long signature. Click to see the full one.
Re: Type-safety and C++, was: Re: Dimension of a matrix
Phil Martel wrote:
Quoted text here. Click to load it


I keep hoping to see a single example of effective code reuse before
I stop working. A wise man once told me "reuse is at the team level" -
you reuse teams familiar with the code, not just the code. No
point in paying for the learning curve twice...

Quoted text here. Click to load it

Yes!

Quoted text here. Click to load it

That's up to him/her. When I get a new code base, I tend to
create a to-be-deleted branch and put in all sorts of
instrumentation to establish what the rules of it are.

IMO, the biggest sin programmers commit is trying to make ever second
count as "productive time ", working towards an assigned goal. You gotta
spend time with a code base to get to know it.

Quoted text here. Click to load it

--  
Les Cargill

Re: Type-safety and C++, was: Re: Dimension of a matrix
On 30/03/17 17:51, Phil Martel wrote:
Quoted text here. Click to load it


There are really just two simple rules here.

1. Make sure it is obvious how large your array is.

2. Don't access arrays unless you know its size.

The next guy working on your code should not /be/ working on your code,
or any code, if these rules are not blindingly obvious to him.

Some "traditional" C mistakes, like overrunning string buffers, I can
understand - people are sometimes lazy or make unwarranted assumptions
about sizes, beginners have read books with functions like "strcat",
"strcpy" and "sprintf", and even more advanced users can easily
misunderstand the subtle details of the "n" variants.

But arrays are well-defined structures with specific sizes.  You /know/
the size when the array is created, and you need to know the size when
you use it.  Getting this wrong is not just making unwarranted
assumptions - it is misunderstanding the point of the code you are
trying to write.

Of course all sorts of mistakes can creep into a program, especially
during heavy development and before checks, code reviews, and testing.
But array size errors should be a rare event - they are not something
that should be common enough to be singled out.



Site Timeline