Let's write a c program, without knowing what it does...

[gswork]

Let's write a c program, without knowing what it does...

Some of you may recall Jim Roger's excellent series of posts (on
comp.programming) exploring the implementation of common software
activities in different languages by requesting small working programs
as source.

Well, having thought & read about the benefits of teamwork, oss,
extreme programming etc i thought, instead of writing software that
has a known purpose - why not do the opposite, write a program the
purpose of which isn't known until it's done!

Kinda like the write a line and pass it along game of storytelling.

Now, i'm not sure if this will register as fun to anyone, or if it
will work out, but.....

I'd like some volunteers to write the functions that's aren't detailed
in the standard C program below.

I chose standard C because it's well known and cross posted to c.l.c
because clc residents can help pick out code issues, and perhaps have
some fun too - or just question the pointlessness of this exercise!
Hope this doesn't offend the purpose of clc.

Just pick one function, whatever you like, and write the function in
any way you see fit so that it will robustly fit into the simple
program below, the more imaginative it is, the more it will stretch
robustness and (hopefully) demonstrate the value of standards and
structured programming, or something..:

#include <stdio.h>

/* function definitions missing! */

int main()
{
int num1,num2,num3;

num1=GetAnInteger();
num2=GetAnInteger();

num3=DoAnOperation(num1, num2);

DisplayResult(num3);

return 0;
}

Note that anything that returns an integer must return a valid integer
whatever the size of int on the target platform. So the person who
chooses 'DoAnOperation' has an extra challenge, in designing something
interesting that produces a meaningful return (though it doesn't
*have* to be meaningful!). The other two functions might be easier,
but who knows what you may come up with.....

Regardless of the content of the functions, we should all be able to
compile any combination using the above on an iso standard compliant c
compiler and get a working program, even though we never planned what
it should do in detail!

 

[Bill Godfrey]

(e-mail address removed) (gswork) wrote:

#include <stdio.h>

/* function definitions missing! */

int DisplayResult(int num3)
{
PrepareResultForDisplay(&num3);
printf(FormatString(num3),num3);
}

int main()
{
int num1,num2,num3;

num1=GetAnInteger();
num2=GetAnInteger();

num3=DoAnOperation(num1, num2);

DisplayResult(num3);

return 0;
}

whatever the size of int on the target platform. So the person who
chooses 'DoAnOperation' has an extra challenge, in designing something

I'll let someone else do that part.

Bill, fun fun fun fun fun!

 

[Nils Petter Vaskinn]

int DisplayResult(int num3)
{
PrepareResultForDisplay(&num3);
printf(FormatString(num3),num3);
}

int GetAnInteger()
{
if (CheckSomething()) {
return AskUserForANumber();
}
if (CheckSomethingElse()) {
return DoAnotherOperation(AskUserForANumber());
}
return DoAnotherOperation(42);
}

 

[Irrwahn Grausewitz]

(e-mail address removed) (gswork) wrote:
<snip>
What the heck.

Yep; why not.

#include <stdlib.h>

void PrepareResultForDisplay( int *qezcoatl )
{
if ( qezcoatl == NULL )
{
fprintf( stderr,
"PrepareResultForDisplay choked on NULL pointer.\n" );
exit( EXIT_FAILURE );
}
*qezcoatl = Clip( *qezcoatl, LowerLimit(), UpperLimit() );
return;
}

int DisplayResult(int num3)
{
PrepareResultForDisplay(&num3);
printf(FormatString(num3),num3);
}


I'll let someone else do that part.

Bill, fun fun fun fun fun!

Irrwahn, no riks no fnu.

 

[Tom Evans]

int GetAnInteger()
{
if (CheckSomething()) {
return AskUserForANumber();
}
if (CheckSomethingElse()) {
return DoAnotherOperation(AskUserForANumber());
}
return DoAnotherOperation(42);
}

int AskUserForANumber() {
char buffer[10];

printf("On a scale of 1 to 10, how much do you like this program?");
fgets(buffer, sizeof(buffer), stdin);

/* Ignore user, they're probably wrong. */
return 10;
}

 

[bd]

int GetAnInteger()
{
if (CheckSomething()) {
return AskUserForANumber();
}
if (CheckSomethingElse()) {
return DoAnotherOperation(AskUserForANumber());
}
return DoAnotherOperation(42);
}

int AskUserForANumber() {
char buffer[10];

printf("On a scale of 1 to 10, how much do you like this program?");
fflush(stdout);

fgets(buffer, sizeof(buffer), stdin);

/* Ignore user, they're probably wrong. */
return 10;
}

 

[Tom Evans]

int GetAnInteger()
{
if (CheckSomething()) {
return AskUserForANumber();
}
if (CheckSomethingElse()) {
return DoAnotherOperation(AskUserForANumber());
}
return DoAnotherOperation(42);
}

int AskUserForANumber() {
char buffer[10];

printf("On a scale of 1 to 10, how much do you like this program?");

fflush(stdout);

doh.
(I'm used to c++, where cin and cout are tied so it wouldn't be a problem)
Knew I shouldn't have got involved in this..

 

[gswork]

(e-mail address removed) (gswork) wrote:


int DisplayResult(int num3)
{
PrepareResultForDisplay(&num3);
printf(FormatString(num3),num3);
}

Ah, I think i've been somewhat ambiguous!

I'd envisioned many version of the three 'missing' functions that,
regardless of what they do, or how imaginatively, would yield a
coherent working portable c program at the end, however you mixed the
various entrant's entries!

I quite like this idea of a second layer of functions though. perhaps
it should not go too deep or i fear we'd end up with something we
could never compile!

 

[rzed]

(e-mail address removed)9.co.uk.invalid (Bill Godfrey) wrote in


Ah, I think i've been somewhat ambiguous!

I'd envisioned many version of the three 'missing' functions that,
regardless of what they do, or how imaginatively, would yield a
coherent working portable c program at the end, however you mixed
the various entrant's entries!

I quite like this idea of a second layer of functions though.
perhaps it should not go too deep or i fear we'd end up with
something we could never compile!

The whole problem with this thread is that it strikes too close to
home. Most of my specs are hazy and targets are shifting in real time.
The code I write typically starts out with big charcoal gray areas
that look like the nested functions we're seeing here. Sometimes it
seems that it will never get out of that stage. You know, like this
thread.

 

[gswork]

The whole problem with this thread is that it strikes too close to
home.

As i write it's less that 24 hours old! You made it sound like some
many-months old thread that's been dragging you down!

Most of my specs are hazy and targets are shifting in real time.
The code I write typically starts out with big charcoal gray areas
that look like the nested functions we're seeing here. Sometimes it
seems that it will never get out of that stage. You know, like this
thread.

That's the reason to curtail it. You never know.....

 

[gswork]

(e-mail address removed) (gswork) wrote in message
ho hum....something silly...

#include <stdio.h>

/* function definitions missing! */

int DoAnOperation(int num1, int num2)
{
return ((num1 & num2) & (num1 | num2));
}

 

[Robert Stankowic]

----- Original Message -----
From: "Irrwahn Grausewitz" <[email protected]>
Newsgroups: comp.programming,comp.lang.c
Sent: Friday, October 10, 2003 3:50 PM
Subject: Re: Let's write a c program, without knowing what it does...

Yep; why not.


#include <stdlib.h>

int LowerLimit(void)
{
int how_much_darling;
int ret = 0;
int i = sizeof(int);
unsigned char *p = (unsigned char *)&how_much_darling;

if(i < 2)
{
return 42;
}
for(i = 0; i < sizeof(int); i++)
{
ret -= p;
}
return ret >> 3;
}

int UpperLimit(void)
{
static int how_much_darling;
int *pi = &how_much_darling;
int ret = 0;
int i = sizeof(int *);
unsigned char *p = (unsigned char *)&pi;

if(i < 2)
{
return 42;
}
for(i = 0; i < sizeof(int); i++)
{
ret += p;
}
return ret << (sizeof(int) - 1);
}

 

[Irrwahn Grausewitz]

int LowerLimit(void)
{
int how_much_darling;
int ret = 0;
int i = sizeof(int);
unsigned char *p = (unsigned char *)&how_much_darling;

Warning: unsigned char* and int* may have different representations.

if(i < 2)
{
return 42;
}
for(i = 0; i < sizeof(int); i++)
{
ret -= p;

Possible undefined behaviour here.

}
return ret >> 3;

Possible undefined behaviour here, see ISO/IEC 9899:1999 6.5#4.

}

int UpperLimit(void)
{
static int how_much_darling;
int *pi = &how_much_darling;
int ret = 0;
int i = sizeof(int *);
unsigned char *p = (unsigned char *)&pi;

See above.

if(i < 2)
{
return 42;
}
for(i = 0; i < sizeof(int); i++)
{
ret += p;

See above.

}
return ret << (sizeof(int) - 1);

See above.

}

Sorry, I just couldn't resist...

Regards

 

[Robert Stankowic]

int LowerLimit(void)
{
int how_much_darling;
int ret = 0;
int i = sizeof(int);
unsigned char *p = (unsigned char *)&how_much_darling;

Warning: unsigned char* and int* may have different representations.

if(i < 2)
{
return 42;
}
for(i = 0; i < sizeof(int); i++)
{
ret -= p;

Possible undefined behaviour here.

}
return ret >> 3;

Possible undefined behaviour here, see ISO/IEC 9899:1999 6.5#4.

}

int UpperLimit(void)
{
static int how_much_darling;
int *pi = &how_much_darling;
int ret = 0;
int i = sizeof(int *);
unsigned char *p = (unsigned char *)&pi;

See above.

if(i < 2)
{
return 42;
}
for(i = 0; i < sizeof(int); i++)
{
ret += p;

See above.

}
return ret << (sizeof(int) - 1);

See above.

}

Sorry, I just couldn't resist...

*g*
OK what about:

int LowerLimit(void)
{
int how_much_darling;
unsigned char h_m_repr[sizeof how_much_darling];
int ret = 0;
int i = sizeof how_much_darling;

memcpy(h_m_repr, &how_much_darling, sizeof how_much_darling);
/*This should be OK according to N869 6.2.6 verse 4*/

if(i < 2)
{
return 42;
}
for(i = 0; i < sizeof(int); i++)
{
ret -= h_m_repr;
/*If I don't misunderstand N869 6.3.1.3 this is implementation defined
behavior, which was my intention here -should work on all
implementations, but give different results*/
}
return ret >> 3;
/*same as above*/
}

/*Same notes apply to the modified UpperLimit()*/
int UpperLimit(void)
{
static int how_much_darling;
int *pi = &how_much_darling;
int ret = 0;
int i = sizeof(int *);
unsigned char pi_repr[sizeof pi];

memcpy(pi_repr, &pi, sizeof pi);

if(i < 2)
{
return 42;
}
for(i = 0; i < sizeof(int); i++)
{
ret += pi_repr;
}
return ret << (sizeof(int) - 1);
}

If I did not misunderstand the OP, some surprising/unexpected results are
wanted, bur no UB
Don't resist, strike )
Robert

 

[Irrwahn Grausewitz]

*g*
OK what about:

int LowerLimit(void)
{
int how_much_darling;
unsigned char h_m_repr[sizeof how_much_darling];
int ret = 0;
int i = sizeof how_much_darling;

memcpy(h_m_repr, &how_much_darling, sizeof how_much_darling);
/*This should be OK according to N869 6.2.6 verse 4*/

if(i < 2)
{
return 42;
}
for(i = 0; i < sizeof(int); i++)
{
ret -= h_m_repr;
/*If I don't misunderstand N869 6.3.1.3 this is implementation defined
behavior, which was my intention here -should work on all
implementations, but give different results*/
}
return ret >> 3;
/*same as above*/

But still there is ISO/IEC 9899:1999 6.5#4 (same wording in N869):

Some operators (the unary operator ~, and the binary operators <<, >>,
&, ^, and |, collectively described as bitwise operators) are required
to have operands that have integer type. These operators return values
that depend on the internal representations of integers, and have
implementation-defined and undefined aspects for signed types.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If I did not misunderstand the OP, some surprising/unexpected results are
wanted, bur no UB
Don't resist, strike )

Didn't resist, stroke. ))

 

[Joona I Palaste]

Didn't resist, stroke. ))

Grammar nitpick: ITYM "struck".

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Last year he disrespected me - and then he showed lack of respect."
- Anthony Mason

 

[Irrwahn Grausewitz]

Grammar nitpick: ITYM "struck".

Silly me. 'Struck', of course.

 

[Micah Cowan]

Warning: unsigned char* and int* may have different representations.

The fact that they may have different representations is
completely uninteresting. The result is well-defined for
conversion from any one pointer type to any other, including
those requiring casts. It is only the subsequent reading of that
value that can be dangerous: however, such is not the case for a
pointer-to-unsigned-char. This is *explicitly* sanctioned by the
standard.

if(i < 2)
{
return 42;
}
for(i = 0; i < sizeof(int); i++)
{
ret -= p;

Possible undefined behaviour here.

Implementation-defined result or signal, in the case of
underflow; but except in the case of the implementation-defined
signal invoking undefined behavior, I don't see it.

Possible undefined behaviour here, see ISO/IEC 9899:1999 6.5#4.


See above.

As before, no problems here.

if(i < 2)
{
return 42;
}
for(i = 0; i < sizeof(int); i++)
{
ret += p;

See above.

}
return ret << (sizeof(int) - 1);

See above.

}

-Micah

 

[Irrwahn Grausewitz]

The fact that they may have different representations is
completely uninteresting. The result is well-defined for
conversion from any one pointer type to any other, including
those requiring casts. It is only the subsequent reading of that
value that can be dangerous: however, such is not the case for a
pointer-to-unsigned-char. This is *explicitly* sanctioned by the
standard.

Yikes. I need some more coffee. =%]

BTW: Are you referring to ISO/IEC 9899:1999 6.3.2.3#7 or is there
any other section in the standard about this matter?

if(i < 2)
{
return 42;
}
for(i = 0; i < sizeof(int); i++)
{
ret -= p;

Possible undefined behaviour here.

Implementation-defined result or signal, in the case of
underflow; but except in the case of the implementation-defined
signal invoking undefined behavior, I don't see it.

Right.

 

[machine99]

too many cooks....