Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: bugs, Bugs and BUGS!

Author: Keith Evans

Date: 09:58:36 05/28/04

Go up one level in this thread


On May 28, 2004 at 11:00:45, Uri Blass wrote:

>On May 28, 2004 at 07:23:28, Richard Pijl wrote:
>
>>On May 28, 2004 at 05:54:43, Uri Blass wrote:
>>
>>>On May 27, 2004 at 20:11:52, Filip Tvrzsky wrote:
>>>
>>>>On May 27, 2004 at 19:05:42, Uri Blass wrote:
>>>>
>>>>>On May 27, 2004 at 18:41:59, Randall Shane wrote:
>>>>>
>>>>>>On May 27, 2004 at 18:10:47, Uri Blass wrote:
>>>>>><snippage>
>>>>>>>
>>>>>>>I do not get the same move twice when I have
>>>>>>>printf("%s ",move_str(0));
>>>>>>>printf("%s ",move_str(1));
>>>>>>>
>>>>>>>I thought that
>>>>>>>printf("%s %s ",move_str(0),move_str(1));
>>>>>>>should be exactly the same instruction.
>>>>>>>
>>>>>>>I understand now that it is not and the second printf does not print move_str(1)
>>>>>>>immediatly after it calculates it but calculates also move_str(0) and change the
>>>>>>>value of move_str(1) by doing it.
>>>>>>>
>>>>>>>I think that it is a bug in the language or in the compiler because it is clear
>>>>>>>that the programmer mean the same in both cases.
>>>>>>>
>>>>>>>
>>>>>>>correct compiler can solve the problem by translating
>>>>>>>
>>>>>>>printf("%s %s ",move_str(0),move_str(1));
>>>>>>>to
>>>>>>>printf("%s ",move_str(0));
>>>>>>>printf("%s ",move_str(1));
>>>>>>>
>>>>>>>I see no logical reason not to translate it in that way from human point of
>>>>>>>view.
>>>>>>
>>>>>>Ah, but how is the compiler supposed to know that you didn't mean to overwrite
>>>>>>the array, which is defined internal to your move_str routine?
>>>>>  Without
>>>>>>extensive and deep analysis of the routines, it can't make that assumption.
>>>>>
>>>>>
>>>>>I think it can make this assumption.
>>>>>I see no reason to write one printf of 2 strings and to mean different thing
>>>>>than the thing that is done by 2 printf.
>>>>>
>>>>>It is a confusing code.
>>>>
>>>>Uri, I am sorry, but this is really YOUR fault, not compiler fault. I am also
>>>>little bit suprised at your complaints about compiler behaviour knowing your
>>>>strictly logical style of thinking. Because when you read language specification
>>>>and think thoroughly about it then you should realize that compiler does exactly
>>>>what is supposed to do and not what it could assume to be your wish. And thank
>>>>God for it! Because I am sick of software which knows better than me what I
>>>>want.
>>>>Filip
>>>
>>>In that case it is a mistake in defining the language.
>>>
>>>I did not read language specification and I simply generalized based on previous
>>>experience.
>>>
>>>I also think that the compiler should at least give a warning in that case
>>>because I guess that I am not the first person and not the last person to do
>>>that kind of mistake.
>>
>>If you really think that is the case you should probably use a language like
>>Pascal or Modula-II instead. Or perhaps Java? Those languages prevent a lot of
>>these mistakes by not allowing the constructions that cause them.
>>
>>Point is that C gives you a lot of possibilities in fiddling with data and data
>>access. That gives great flexibility, but asks of the programmer to take care
>>when using those tricks.
>>
>>move_str() returns a pointer. And the memory location will contain the stuff you
>>have asked for. In principle you don't care where it is located. The
>>disadvantage is that you should be aware of the limited validity of this
>>content. In this case until the next call to move_str().
>>
>>If you do not want this restriction, you have to rewrite move_str by either
>>supplying a memory location that the calling function controls, or by
>>dynamically allocation memory to store the string (slow!!) where you should not
>>forget to free that memory again when you no longer need it (i.e. after the
>>printf).
>>
>>>I guess that in big majority of the cases that programmers write printf("%s %s
>>>",a,b);
>>>they mean printf("%s ",a); orintf(" %s ",b);
>>
>>printf is a function. Printf is a special function because it allows an
>>unspecified number of parameters, and handles them correctly.
>>Before a function is called, all of its arguments are evaluated.
>
>It is exactly the problem.
>
>I did not know that printf works in that way and I thouhgt that it prints an
>argument immediately after it is evaluated and only later goes to the next
>argument.
>
>It seems more logical to define printf in that way and it does not prevent the
>programmer to first evaluate all argument before printing by special varaibles
>that have the evaluation result.
>
>Uri

How would you pass arguments to a function in an unevaluated state? Can you draw
a stack frame showing exactly what would be done?



This page took 0.01 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.