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!

gswork@mailcity.com (gswork) wrote:
<snip>
What the heck.

> #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!

-- 
   The address in the reply to header is correct, but I'll
   read it quicker if you drop the word "usenet".

On Fri, 10 Oct 2003 12:25:31 +0000, Bill Godfrey wrote:

>> #include <stdio.h>
>>
>> /* function definitions missing!  */
> 
> int DisplayResult(int num3)
> {
>     PrepareResultForDisplay(&num3);
>     printf(FormatString(num3),num3);
> }

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

> 
>> int main()
>> {
>>  int num1,num2,num3;
>>
>>  num1=GetAnInteger();
>>  num2=GetAnInteger();
>>
>>  num3=DoAnOperation(num1, num2);
>>
>>  DisplayResult(num3);
>>
>>  return 0;
>> }

-- 
NPV

"the large print giveth, and the small print taketh away"
                                Tom Waits - Step right up

billg-usenet@bacchae.f9.co.uk.invalid (Bill Godfrey) wrote:

>gswork@mailcity.com (gswork) wrote:
><snip>
>What the heck.
Yep; why not. 

>
>> #include <stdio.h>
>>
>> /* function definitions missing!  */
>

#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);
>}
>
>> 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!

Irrwahn, no riks no fnu.
-- 
Close your eyes and press escape three times.

Nils Petter Vaskinn wrote:
> 
> 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;
}

Tom Evans wrote:

> Nils Petter Vaskinn wrote:
>> 
>> 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;
> }

-- 
I never did it that way before.

bd wrote:
> 
> Tom Evans wrote:
> 
> > Nils Petter Vaskinn wrote:
> >>
> >> 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..

billg-usenet@bacchae.f9.co.uk.invalid (Bill Godfrey) wrote in message news:<20031010082531.224$sl@newsreader.com>...
> gswork@mailcity.com (gswork) wrote:
> <snip>
> What the heck.
> 
> > #include <stdio.h>
> >
> > /* function definitions missing!  */
> 
> 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!

gswork wrote:
> billg-usenet@bacchae.f9.co.uk.invalid (Bill Godfrey) wrote in
> message news:<20031010082531.224$sl@newsreader.com>...
>> gswork@mailcity.com (gswork) wrote:
>> <snip>
>> What the heck.
>>
>>> #include <stdio.h>
>>>
>>> /* function definitions missing!  */
>>
>> 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!

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.

--
rzed

"rzed" <Dick.Zantow@lexisnexis.com> wrote in message news:<bm71po$3k8$1@mailgate2.lexis-nexis.com>...
> gswork wrote:
> > billg-usenet@bacchae.f9.co.uk.invalid (Bill Godfrey) wrote in
> > message news:<20031010082531.224$sl@newsreader.com>...
> >> gswork@mailcity.com (gswork) wrote:
> >> <snip>
> >> What the heck.
> >>
> >>> #include <stdio.h>
> >>>
> >>> /* function definitions missing!  */
> >>
> >> 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!
> 
> 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@mailcity.com (gswork) wrote in message news:<81f33a98.0310100407.379a60fd@posting.google.com>...

ho hum....something silly...

> 
> #include <stdio.h>
> 
> /* function definitions missing!  */

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


> 
> int main()
> {
>  int num1,num2,num3;
> 
>  num1=GetAnInteger();
>  num2=GetAnInteger();
> 
>  num3=DoAnOperation(num1, num2);
> 
>  DisplayResult(num3);
> 
>  return 0;
> }

----- Original Message -----
From: "Irrwahn Grausewitz" <irrwahn33@freenet.de>
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...


> billg-usenet@bacchae.f9.co.uk.invalid (Bill Godfrey) wrote:
>
> >gswork@mailcity.com (gswork) wrote:
> ><snip>
> >What the heck.
> Yep; why not.
>
> >
> >> #include <stdio.h>
> >>
> >> /* function definitions missing!  */
> >
>
> #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[i];
   }
   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[i];
   }
   return ret << (sizeof(int) - 1);
}


> 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);
> >}
> >
> >> 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!
>
> Irrwahn, no riks no fnu.
> --
> Close your eyes and press escape three times.

"Robert Stankowic" <pcdoktor@netway.at> wrote:

>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[i];

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[i];

See above.

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

See above.

>}

Sorry, I just couldn't resist... :-)

Regards
-- 
Irrwahn 
(irrwahn33@freenet.de)

"Irrwahn Grausewitz" <irrwahn33@freenet.de> schrieb im Newsbeitrag
news:vnjiov8v8hhk6chsngcj59nvkrnkkjumec@4ax.com...
> "Robert Stankowic" <pcdoktor@netway.at> wrote:
>
> >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[i];
>
> 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[i];
>
> 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[i];
      /*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[i];
   }
   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

"Robert Stankowic" <pcdoktor@netway.at> wrote:

<SNIP>
>
>*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[i];
>      /*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.
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  

<SNIP>

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

Didn't resist, stroke. :)))

-- 
Irrwahn 
(irrwahn33@freenet.de)

Irrwahn Grausewitz <irrwahn33@freenet.de> scribbled the following:
> "Robert Stankowic" <pcdoktor@netway.at> wrote:
>>If I did not misunderstand the OP, some surprising/unexpected results are
>>wanted, bur no UB
>>Don't resist, strike :))

> Didn't resist, stroke. :)))

Grammar nitpick: ITYM "struck".

-- 
/-- Joona Palaste (palaste@cc.helsinki.fi) ---------------------------\
| 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

Joona I Palaste <palaste@cc.helsinki.fi> wrote:

>Irrwahn Grausewitz <irrwahn33@freenet.de> scribbled the following:
>> "Robert Stankowic" <pcdoktor@netway.at> wrote:
>>>Don't resist, strike :))
>>
>> Didn't resist, stroke. :)))
>
>Grammar nitpick: ITYM "struck".

Silly me. 'Struck', of course.
-- 
Irrwahn 
(irrwahn33@freenet.de)

Irrwahn Grausewitz <irrwahn33@freenet.de> writes:

> "Robert Stankowic" <pcdoktor@netway.at> wrote:
> 
> >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.

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[i];
> 
> 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.

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

As before, no problems here.

> 
> >
> >   if(i < 2)
> >   {
> >      return 42;
> >   }
> >   for(i = 0; i < sizeof(int); i++)
> >   {
> >      ret += p[i];
> 
> See above.
> 
> >   }
> >   return ret << (sizeof(int) - 1);
> 
> See above.
> 
> >}

-Micah

Micah Cowan <micah@cowan.name> wrote:

>Irrwahn Grausewitz <irrwahn33@freenet.de> writes:
>
>> "Robert Stankowic" <pcdoktor@netway.at> wrote:
>> 
>> >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.
>
>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[i];
>> 
>> 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.

-- 
Irrwahn 
(irrwahn33@freenet.de)

too many cooks....

Irrwahn Grausewitz <irrwahn33@freenet.de> writes:

> Micah Cowan <micah@cowan.name> wrote:
> 
> >Irrwahn Grausewitz <irrwahn33@freenet.de> writes:
> >
> >> "Robert Stankowic" <pcdoktor@netway.at> wrote:
> >> 
> >> >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.
> >
> >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?

I'm referring to 6.3.2.3#7 for conversions between pointer types;
6.5#7 for reading as a character array.

(Of course, alignment problems are nonexistent for the character types,
so actually evaluating the pointer without dereferencing it would
be okay without 6.5#7).

-Micah

Micah Cowan <micah@cowan.name> wrote:

>Irrwahn Grausewitz <irrwahn33@freenet.de> writes:
>
>> Micah Cowan <micah@cowan.name> wrote:
>> 
>> >Irrwahn Grausewitz <irrwahn33@freenet.de> writes:
>> >
>> >> "Robert Stankowic" <pcdoktor@netway.at> wrote:
>> >> 
>> >> >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.
>> >
>> >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?
>
>I'm referring to 6.3.2.3#7 for conversions between pointer types;
>6.5#7 for reading as a character array.
 ^^^^^
Ah, yes, that's what I was looking for. Thank you.  

>(Of course, alignment problems are nonexistent for the character types,
>so actually evaluating the pointer without dereferencing it would
>be okay without 6.5#7).

Regards
-- 
Irrwahn 
(irrwahn33@freenet.de)

"machine99" <core99@delite.dk> wrote:
> too many cooks....

Up to the point where this thread ran out of steam, it did remind me of the
team-based project I had to do for my degree.

On my own, I could have done a half-reasonable job over a weekend. But, we
had to work in a team and we were given the whole year to finish it.

It rather floundered, until one of us spent a weekend on it and came up
with something half-reasonable.

Bill, 'twas not I.

(Sorry, that post had very little point.)

-- 
   The address in the reply to header is correct, but I'll
   read it quicker if you drop the word "usenet".

billg-usenet@bacchae.f9.co.uk.invalid (Bill Godfrey) wrote in message news:<20031013192915.709$ni@newsreader.com>...
> "machine99" <core99@delite.dk> wrote:
> > too many cooks....
> 
> Up to the point where this thread ran out of steam, it did remind me of the
> team-based project I had to do for my degree.
> 
> On my own, I could have done a half-reasonable job over a weekend. But, we
> had to work in a team and we were given the whole year to finish it.
> 
> It rather floundered, until one of us spent a weekend on it and came up
> with something half-reasonable.
> 
> Bill, 'twas not I.
> 
> (Sorry, that post had very little point.)

Never really got steam, but that's ok.

rzed's "The whole problem with this thread " is a great way to ensure
no more contributions, but really it was just a little fun - and too
ambiguous from me.

If you look at sourceforge, or any set of open source open team
projects, an overwhelming number just taxi around and never take off. 
In the most successful projects, as in your example, things happen
when someone or some closely knit team, plan the project and work to
deadlines.

gswork wrote:
> billg-usenet@bacchae.f9.co.uk.invalid (Bill Godfrey) wrote in
> message news:<20031013192915.709$ni@newsreader.com>...
>> "machine99" <core99@delite.dk> wrote:
>>> too many cooks....
>>
>> Up to the point where this thread ran out of steam, it did remind
>> me of the team-based project I had to do for my degree.
>>
>> On my own, I could have done a half-reasonable job over a weekend.
>> But, we had to work in a team and we were given the whole year to
>> finish it.
>>
>> It rather floundered, until one of us spent a weekend on it and
>> came up with something half-reasonable.
>>
>> Bill, 'twas not I.
>>
>> (Sorry, that post had very little point.)
>
> Never really got steam, but that's ok.
>
> rzed's "The whole problem with this thread " is a great way to
> ensure no more contributions, but really it was just a little fun -
> and too ambiguous from me.
>
> If you look at sourceforge, or any set of open source open team
> projects, an overwhelming number just taxi around and never take
> off. In the most successful projects, as in your example, things
> happen when someone or some closely knit team, plan the project and
> work to deadlines.

Jeez, I didn't really mean to toss a wet blanket on it. I was just
getting the shakes, that's all. It was only a matter of time until
there was a steering committee and mandatory naming standards and code
reviews and another layer of management and budget overruns and ...
and ... migod, they're starting again!

--
rzed