Interesting code

[v4vijayakumar]

Happened to see my old (last millennium) c code. Almost forgot that I
wrote it .
It is interesting. :-)

int sqrt(int no)
{
int t;
no = t * t;
return t;
}

[DhaneshNair@gmail.com]

Re: Interesting code

Can u tell me what is interesting in this code ??


v4vijayakumar wrote:

Happened to see my old (last millennium) c code. Almost forgot that I
wrote it .
It is interesting. :-)
>
int sqrt(int no)
{
int t;
no = t * t;
return t;
}

[Richard Heathfield]

Re: Interesting code

DhaneshNair@gma il.com top-posted, but I've fixed that. He said:

v4vijayakumar wrote:

>Happened to see my old (last millennium) c code. Almost forgot that I
>wrote it .
>It is interesting. :-)
>>
>int sqrt(int no)
>{
> int t;
> no = t * t;
> return t;
>}

>
Can u tell me what is interesting in this code ??

No, there isn't any regular comp.lang.c contributor called "u".
(Translation: abbreviating "you" to "u" marks you out as someone who can't
even spell "you" properly. Take the time to type "you" in full, in the
interests of clear communication and of not looking idiotic.)

Here are the principal points of interest:

1) function name choice invades implementation namespace, thus invoking
undefined behaviour;
2) function name choice gives a misleading impression of what the function
tries to do;
3) t's value is indeterminate, but the function still attempts to use t's
value regardless, thus invoking undefined behaviour;
4) a parameter is used solely for assigning a value to, and this value will
be lost at the same time that the parameter itself is lost, at the end of
this function;
5) an indeterminate value is returned from this function, thus invoking
undefined behaviour in any caller that evaluates it;
6) even if all those faults were fixed, the function would still need major
repair work (type choices, range validation, etc).

Summary: it was written by someone who didn't know C very well six or seven
years ago. Whether they have learned their lessons in the meantime, I
cannot say.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[Ben Pfaff]

Re: Interesting code

"DhaneshNair@gm ail.com" <DhaneshNair@gm ail.comwrites:

v4vijayakumar wrote:

>int sqrt(int no)
>{
> int t;
> no = t * t;
> return t;
>}

>
Can u tell me what is interesting in this code ??

Just the misconception that it illustrates.
--
"I've been on the wagon now for more than a decade. Not a single goto
in all that time. I just don't need them any more. I don't even use
break or continue now, except on social occasions of course. And I
don't get carried away." --Richard Heathfield

[v4vijayakumar]

Re: Interesting code


Richard Heathfield wrote:

DhaneshNair@gma il.com top-posted, but I've fixed that. He said:
>

v4vijayakumar wrote:

Happened to see my old (last millennium) c code. Almost forgot that I
wrote it .
It is interesting. :-)
>
int sqrt(int no)
{
int t;
no = t * t;
return t;
}

Can u tell me what is interesting in this code ??

>
No, there isn't any regular comp.lang.c contributor called "u".
(Translation: abbreviating "you" to "u" marks you out as someone who can't
even spell "you" properly. Take the time to type "you" in full, in the
interests of clear communication and of not looking idiotic.)
>
Here are the principal points of interest:
>
1) function name choice invades implementation namespace, thus invoking
undefined behaviour;
2) function name choice gives a misleading impression of what the function
tries to do;
3) t's value is indeterminate, but the function still attempts to use t's
value regardless, thus invoking undefined behaviour;
4) a parameter is used solely for assigning a value to, and this value will
be lost at the same time that the parameter itself is lost, at the end of
this function;
5) an indeterminate value is returned from this function, thus invoking
undefined behaviour in any caller that evaluates it;
6) even if all those faults were fixed, the function would still need major
repair work (type choices, range validation, etc).
>
Summary: it was written by someone who didn't know C very well six or seven
years ago. Whether they have learned their lessons in the meantime, I
cannot say.
>
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

You take the fun out of the post. The post was not asking any help or
correction in the code. It is just for fun.

I wrote (1999) this to find square root of a number. I was then new to
c. I got wrong results and didn't know why it was not working. Then,
someone told me about the sqrt library function. Anyhow I saved the
code for future reference (?) and I forgot about it. Suddenly happened
to see the code and recollected the past.

[Keith Thompson]

Re: Interesting code

Ben Pfaff <blp@cs.stanfor d.eduwrites:

"DhaneshNair@gm ail.com" <DhaneshNair@gm ail.comwrites:

>v4vijayakuma r wrote:

>>int sqrt(int no)
>>{
>> int t;
>> no = t * t;
>> return t;
>>}

>>
>Can u tell me what is interesting in this code ??

>
Just the misconception that it illustrates.

Um, which one?

Apart from the multiple instances of undefined behavior, it's amusing
that the value it returns is (likely to be) the square root of the
parameter "no" -- though the value of the parameter "no" bears no
relationship to the argument with which the function was called.

I suppose the author assumed that an assigment statement causes the
left and right hand sides to become equal (by magic if necessary),
rather than merely evaluating the right operand and copying its value
to the object designated by the left operand. In other words, that
no = t * t;
would cause no to become equal t * t by changing the value of t;
obviously the way to do this is to set t to the square root of no.

To someone who knows what "=" means in mathematics, but hasn't been
exposed to the concept of assignment, it's not an entirely insane
misconception.

(Exercise: Design and implement a language that really works this
way.)

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Re: Interesting code

v4vijayakumar said:

You take the fun out of the post.

What fun?

The post was not asking any help or correction in the code.

I didn't say it was. But someone asked why it was interesting, so I listed
the principal points of interest.

I wrote (1999) this to find square root of a number.

Oh deary deary me.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[Richard Bos]

Re: Interesting code

Keith Thompson <kst-u@mib.orgwrote:

Ben Pfaff <blp@cs.stanfor d.eduwrites:

"DhaneshNair@gm ail.com" <DhaneshNair@gm ail.comwrites:

v4vijayakumar wrote:
>int sqrt(int no)
>{
> int t;
> no = t * t;
> return t;
>}

I suppose the author assumed that an assigment statement causes the
left and right hand sides to become equal (by magic if necessary),
rather than merely evaluating the right operand and copying its value
to the object designated by the left operand. In other words, that
no = t * t;
would cause no to become equal t * t by changing the value of t;
obviously the way to do this is to set t to the square root of no.

(Exercise: Design and implement a language that really works this
way.)

Too late. Prolog already exists.

Richard

[Nelu]

Re: Interesting code

Richard Bos wrote:

Keith Thompson <kst-u@mib.orgwrote:
>

>Ben Pfaff <blp@cs.stanfor d.eduwrites:

>>"DhaneshNair@ gmail.com" <DhaneshNair@gm ail.comwrites:
>>>v4vijayakuma r wrote:
>>>>int sqrt(int no)
>>>>{
>>>> int t;
>>>> no = t * t;
>>>> return t;
>>>>}

>

>I suppose the author assumed that an assigment statement causes the
>left and right hand sides to become equal (by magic if necessary),
>rather than merely evaluating the right operand and copying its value
>to the object designated by the left operand. In other words, that
> no = t * t;
>would cause no to become equal t * t by changing the value of t;
>obviously the way to do this is to set t to the square root of no.

>

>(Exercise: Design and implement a language that really works this
>way.)

>
Too late. Prolog already exists.
>

You beat me to it.

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)

[Richard Tobin]

Re: Interesting code

In article <455c1103.13970 8911@news.xs4al l.nl>,
Richard Bos <rlb@hoekstra-uitgeverij.nlwr ote:

>(Exercise: Design and implement a language that really works this
>way.)

>Too late. Prolog already exists.

Prolog doesn't really do this.

If you write a predicate carefully, it may well be possible to call it
with various combinations of uninstantiated variables. So for example
append(X, Y, [1,2,3]) will generate pairs of lists whose concatenation
is the list [1,2,3]. But it doesn't do general arithmetic solving -
10 is X*X will not find the square root of 10.

On the other hand, several spreadsheets do provide this, allowing you
to ask "how many units must we sell to make $1m profit?", or perhaps
adjust your sales figures to match what you told the tax office about
your profits.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Bill Medland]

Re: Interesting code

Keith Thompson wrote:

Ben Pfaff <blp@cs.stanfor d.eduwrites:

>"DhaneshNair@g mail.com" <DhaneshNair@gm ail.comwrites:

>>v4vijayakum ar wrote:
>>>int sqrt(int no)
>>>{
>>> int t;
>>> no = t * t;
>>> return t;
>>>}
>>>
>>Can u tell me what is interesting in this code ??

>>
>Just the misconception that it illustrates.

>
Um, which one?
>
Apart from the multiple instances of undefined behavior, it's amusing
that the value it returns is (likely to be) the square root of the
parameter "no" -- though the value of the parameter "no" bears no
relationship to the argument with which the function was called.
>
I suppose the author assumed that an assigment statement causes the
left and right hand sides to become equal (by magic if necessary),
rather than merely evaluating the right operand and copying its value
to the object designated by the left operand. In other words, that
no = t * t;
would cause no to become equal t * t by changing the value of t;
obviously the way to do this is to set t to the square root of no.
>
To someone who knows what "=" means in mathematics, but hasn't been
exposed to the concept of assignment, it's not an entirely insane
misconception.

Which is why I liked the fact that Pascal used a symbol other than = to mean
assignment.

>
(Exercise: Design and implement a language that really works this
way.)
>

--
Bill Medland

[August Karlstrom]

Re: Interesting code

Keith Thompson skrev:

To someone who knows what "=" means in mathematics, but hasn't been
exposed to the concept of assignment, it's not an entirely insane
misconception.

I'd say: "...hasn't been exposed to C's unfortunate choice of symbol for
assignment". ;-)


August

[Gordon Burditt]

Re: Interesting code

>Happened to see my old (last millennium) c code. Almost forgot that I

>wrote it .
>It is interesting. :-)
>
>int sqrt(int no)
>{
int t;
no = t * t;
return t;
>}

This reminds me a bit of the hypothetical BUT statement which I
wanted to add to a language (FORTRAN at the time, but it could
sorta fit into C also):

y = a*x*x + b*x + c BUT y = 0;

would solve a quadratic equation. If a, b, and c weren't constants
there wasn't anything in particular that prohibited it from changing
them instead of x to satisfy the condition. There wasn't anything
guaranteeing which root you got, either, although you could do:

y = a*x*x + b*x + c BUT y = 0 and x 0;

Naturally, something like:

y = 0*x + 3 BUT y = 4;

is likely to have infinite run time.

[James Dow Allen]

Re: Interesting code


v4vijayakumar wrote:

Happened to see my old (last millennium) c code. Almost forgot that I
wrote it .
It is interesting. :-)

I thought the pedantic responses to this were
perversely bizarre. Obviously vijay was joking;
beginners often have misconceptions; and it is
not impossible that some programming language
behave the way beginner vijay hoped.

Anyway, since the C compiler is free to set
undefined variables to any value, a minor change
to vijay's code makes it work:

#include <launch_codes.h >

/*
* This sqrt function relies
* on the Compiler obeying Asimov's
* First Law of Robotics.
*/

int sqrt(int no)
{
int t;
if (no == t * t)
return t;
else
aim_and_launch( "/dev/icbm", 1, TGT_TEHERAN);
}

James

[Chris Thomasson]

Re: Interesting code

"James Dow Allen" <jdallen2000@ya hoo.comwrote in message
news:1163906225 .730471.169840@ h54g2000cwb.goo glegroups.com.. .
[...]

#include <launch_codes.h >
>
/*
* This sqrt function relies
* on the Compiler obeying Asimov's
* First Law of Robotics.
*/
>
int sqrt(int no)
{
int t;
if (no == t * t)
return t;
else
aim_and_launch( "/dev/icbm", 1, TGT_TEHERAN);
}

:O