Forwarding a failure notice (fwd)

[Adrian Ratnapala <s369625@student.uq.edu.au>]

---------- Forwarded message ----------
Date: 26 Sep 1998 16:01:22 -0000
From: MAILER-DAEMON@laaratna.staff.uq.edu.au
To: s369625@student.uq.edu.au
Subject: failure notice

Hi. This is the qmail-send program at laaratna.staff.uq.edu.au.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<penguinplay@sunsite.auc.dk>:
130.102.2.14 does not like recipient.
Remote host said: 550 <penguinplay@sunsite.auc.dk>... Relaying denied
Giving up on 130.102.2.14.

--- Below this line is a copy of the message.

Return-Path: <s369625@student.uq.edu.au>
Received: (qmail 419 invoked by uid 500); 23 Sep 1998 08:18:47 -0000
From: s369625@student.uq.edu.au
Reply-To: s369625@student.uq.edu.au
To: PenguinPlay <penguinplay@sunsite.auc.dk>
Subject: Re: PenguinPlay.h analysis
Date: Wed, 23 Sep 1998 17:57:06 +1000
X-Mailer: KMail [version 0.7.9]
Content-Type: text/plain
References: <98092615241500.00911@server>
MIME-Version: 1.0
Message-Id: <98092318184600.00406@gonzo>
Content-Transfer-Encoding: 8bit
X-KMail-Mark: 

Wee!  Yet more fun with this file!  I doo so love it, every time I touch it,
the whole project must be rebuilt.  All hail "make depend"!

On Sat, 26 Sep 1998, Christian Reiniger wrote:
>[Caution - long mail]
And it will probably be a long reply.


>
>#ifndef _PenguinPlay_h
>#define _PenguinPlay_h
>
>> What convention do we have for these macros? I used __PENGUINPLAY_H__ 
>> up to now. Perhaps we should write some "PenguinPlay coding standards"
>> doc ;)
We don't have a convention.  _SampeCapitalizationAsFilename_h is just my own
habit.  Yes we should have a coding standard.  (No indentation flamewars
though).

>
>#include <config.h>
>
>#include <unistd.h>
>
>> Stop! You can't be sure that unistd.h exists - that's why I inserted the
>> buggy AC_CHECK_HEADERS(unistd.h) test in configure.in
Correct.   

>> We should make a list of all constants defined by PenguinPlay
>> (PenguinPlay.h, config.h, ...)
What do you mean?

>
>/***
>  Do 64 bit integers exist?
>  Thanks Yong Chi for the hack for detecting
>  64 bit architectures.
>***/
>
>#if INT_MAX < LONG_MAX
>
>> sure that this is true for all 64bit archs?
I think so.  It is still a bit of a hack though.


>
>> IIRC the gcc docs state that long long can't be relied on for all things,
>> e.g. multiplicating long longs isn't necessarily possible, taking their
>> addresses is propably undefined etc. IMHO we shouldn't use them
>> (or at least not define ppInt64 etc to be long long)
>
There is no other way to do ppInt64 on 32 bit architectures (in C at least).
At the end of the day, users should not be _using_ ppInt64, defining is
harmless (but then there isn't much _point_ in defining it).


>/*
>
>#ifdef _PP_CPLUSPLUS
>  #define _PP_EXTC extern "C"
>#else
>  #define _PP_EXTC extern
>
>> that one should be empty instead of "extern", at least if it will be used
>> for exten "C" {} blocks
No that's not what it is for, it is a replacement for "extern".  I can't
remember why I didn't use extern "C" {} blocks


>/*
>  Always felt that defining all these types is a bit excessive.
>  But it seems like standard practice, so I'll do it anyway.
>  (Besides, these are about the only original fragment of the
>  sources I inherited from Steve Baker, so I'll keep them for
>  nostalgic reasons:) )
>*/
>typedef          bool     ppBool   ;
>
>> useful, but we can't rely on an existing "bool" type (or does autoconf
>> define it ?)
Don't know.  ppBool I think is the only one with a reason for existence.

>
>typedef signed   char     ppByte   ;
>
>> useful, but IMHO a Byte type should be unsigned
OK so maybe this has a reason to exist too, even if
that reason is pure neatness.  Yes, it should be unsigned.

>
>typedef          short    ppShort  ;
>typedef unsigned int      ppuInt   ;
>
>> Hmm, do we want to have shortcuts for unsigned types? 
What do you mean?

>
>> again: this could backfire
My same reply.



>_PP_EXTC int ppInit (int* argc, char** argv) ;
>
>> The code for this is in src/ppUtils.cc, right?
Right.

>
>> see my mail concerning debug levels.
Hmm, if I can find it.

>
>> My Oxford dictionary says:
>> leek (n) - vegetable related to the onion but with wider green leaves
>> above a long white bulb ;)
>> Things get tasty here ;)
Sorry.


>  /*
>   * Real work.
>   */
>
>  void Link(){link_count++;}
>
>> What about returning "this" here? Would allow for
>> FooPointer = bar->Link ();
>> Just an idea
I think it did that once apon a time.  Can't remember why I got
rid of it.  It can't have been a very good reason.

>
>> Ok, I changed that stuff. Have a look at it and tell me if you don't agree
Hmm, when I log on to my not-the-ISP-with-the-insane-firewall-that-wont-
let-me-use-CVS account, I'll do just that.


>> I'd leave it out to keep the class as minimalistic as possible
I'll think about this.





>
>God is real (unless declared as integer).
>
This is the problem with Pascal.  In C we avoid all such heresy because no one
would consider God a "float".