Dimension of a matrix

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

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!

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.

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!

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?

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

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.

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 ;-).

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.

On Mon, 27 Mar 2017 23:42:08 -0700, 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.?

This _is_ an embedded group.

When I'm writing desktop code I'm more prone to use 'at', or otherwise 
actively test for overrunning boundaries.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!