"Uwe Salomon" <post@uwesalomon.de> wrote:

[...]
> Yep. Other code, same problem. That's what i was trying to say.

Agreed. The problem inherently presented by my OP is likely to come in many different shapes.

-manfred

In article <ddej2h$20ha$1@digitaldaemon.com>, Manfred Nowak says...
>
>llothar <llothar_member@pathlink.com> wrote:
>
>[...]
>> And if you use inout parameter like a local variable then your personal programming skills must be improved, not the language.
>
>Sorry. If this is your professional opinion for the needs of QA in the production of a piece of software that by malfunction my cause loss of lives, would you trust your life to such software delivered by your own company?

For this tasks you shouldn't either use dynamically allocated memory and also no inout parameter and also a few other things.

Get a lesson in 'Z' and try to formally verify the code.
This is what is done in so critical pieces of software, like aviation or nuclear
power plant control systems,

I think you should rethink the purpose of a language in a safe design, as it is almost a minor part.

And by the way did you ever work with QA teams in the real world ? Sounds more like you are still part of the strange academic world.

Manfred Nowak wrote:
> llothar <llothar_member@pathlink.com> wrote:
> 
> [...]
> 
>>And if you use inout parameter like a local variable then your personal programming skills must be improved, not the language.
> 
> 
> Sorry. If this is your professional opinion for the needs of QA in the production of a piece of software that by malfunction my cause loss of lives, would you trust your life to such software delivered by your own company? 

I don't think there is a way to solve the problem of f(i, i)
in an engineering/QA sense (with safety in mind), even when
your language were to forbid two paths of access to a variable.
Thinking otherwise can be a dangerous illusion, I think.

Suppose in f(i, j), &i not &j, assigning to i and j has external
effects, direct or indirect. How can a compiler cover external
effects, and show that at some point in time, the external effects
don't incur risk? Relying on &i not being &j isn't a bit more
secure then.

Or suppose that in f(i, j), i and j denote composite values
and the composite values happen to share a common object,
at some point while the programs is running. For example,
via a pointer. What now? Can/Should proper program design be
delegated to the language definition here, too?

Extending the argument, if two simple pointers point to the same
object, deallocating via one pointer has the effect of ...
So simple pointers should be disallowed in languages? ;-)

Or

   some_list.some_algorithm(here, there)

A perfectly useful call is

   some_list.some_algorithm(this_place, this_place)

The algorithm just happens to work on only one list element,
possibly modyfing this_place after the work is done (and
the element has been moved or some such).

Georg

Manfred Nowak wrote:
> I really like developers getting personal and through my hole 

This part was the joke right?

Alan West <alan@alanz.com> wrote:

> Manfred Nowak wrote:
>> I really like developers getting personal and through my hole
> 
> This part was the joke right?

Yeah. The only expression that rhymed to wording _and_ subject.

-manfred

On Sun, 7 Aug 2005 01:05:27 +0000 (UTC), Manfred Nowak wrote:

> 1) Review this code:
> 
> void f( inout int i, inout int j){
>   i= 1;
>   j= 2;
> }
> 
> 2) Pass or Fail?
> 
> 3) Explain.
> 
> -manfred

A colleague has suggested that all we need is to be able to specify both compile-time and run-time checks for overlapping arguments in order to capture unexpected situations whenever we use 'inout' arguments.

We need run-time checks because such a function could be incorporated into a dll or closed-source library, where not all source is available at compile time and/or link time.

We need compile-time checks because there are some situations in which a run-time check is too late, such as when lives are at stake.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
12/08/2005 9:41:53 AM

In article <1mlum6oxxo3p7.1n415a8bwdrzr$.dlg@40tude.net>, Derek Parnell says...
>
>On Sun, 7 Aug 2005 01:05:27 +0000 (UTC), Manfred Nowak wrote:
>
>> 1) Review this code:
>> 
>> void f( inout int i, inout int j){
>>   i= 1;
>>   j= 2;
>> }
>> 
>> 2) Pass or Fail?
>> 
>> 3) Explain.
>> 
>> -manfred
>
>A colleague has suggested that all we need is to be able to specify both compile-time and run-time checks for overlapping arguments in order to capture unexpected situations whenever we use 'inout' arguments.
>
>We need run-time checks because such a function could be incorporated into a dll or closed-source library, where not all source is available at compile time and/or link time.
>
>We need compile-time checks because there are some situations in which a run-time check is too late, such as when lives are at stake.
>

IMO - I would think runtime checks for overlapping references would be Ok, plus a simple compile-check check to see if the same variable was being passed for more than one argument. So it would be like this:

- Pointers stay as-is
- Non -release runtime check of the same reference passed for more than one
param. of the same type.
- Non -release runtime check for overlapping arrays (what would be a good
algorithm for checking for overlapping multi-dim arrays or a combination of
single and multi-dim arrays of the same type passed?).

As far as aliasing goes, that still leaves the case of:

int i;
void foo(inout int param) { i++; param++; }
void main() { foo(i); }

But at least the above criteria for overlapping parameters would be useful, IMO.

- Dave

>-- 
>Derek
>(skype: derek.j.parnell)
>Melbourne, Australia
>12/08/2005 9:41:53 AM

llothar schrieb:
> In article <dd8b1o$4an$1@digitaldaemon.com>, Manfred Nowak says...

[snip]

>>And in D dead code is as illegal as expressions that do not have an effect.
> 
> Sorry but there is no reason to forbid a effectless expressions, and there is no language in the world that forbids this. So this statement is simply wrong.

http://www.digitalmars.com/d/statement.html#expression
# Expressions that have no effect, like (x + x), are illegal in
# expression statements.

http://www.digitalmars.com/d/warnings.html
# While dead code is poor style in released code, it can legitimately
# happen a lot when rapidly trying to isolate down a bug or experiment
# with different bits of code.

While effectless expressions are illegal, dead code is legal.

Thomas

llothar <llothar_member@pathlink.com> wrote:

[...]
> Get a lesson in 'Z' and try to formally verify the code.
[...]

Oooops. I am trustfully looking forward to your formal proof of correctness in "Z" for the call of `ackermann( uint.max / 2)'.

-manfred

Hi,

>http://www.digitalmars.com/d/statement.html#expression
># Expressions that have no effect, like (x + x), are illegal in
># expression statements.

Why is it assumed that expression has no effect? x could have + overloaded. If so, is it still illegal?

Thanks,
--AJG.