HDTenEightyP/NetNews huggingface dataset:
From: ctoth@magnus.acs.ohio-state.edu (Christopher M Toth)
Subject: THANKS!!!! (was: programming in time)
Organization: The Ohio State University
Date: Sat, 12 Dec 1992 00:42:08 GMT

	Thanks to all those who replied to my original posting(including
the flames!) :) I recieved enough advice to figure out how to do it.
Thanks again! :)

-Chris


-- 
Christopher M. Toth             | "... We travel in the dark of a new moon
The Ohio State University       | A starry highway traced on the map of the sky
Columbus State                  | Like lovers and heroes,
CIS/History/Classics/ect..Major | Lonely as the eagle's cry..." -Peart
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.c
Subject: Re: alias acess
Date: 17 Dec 1992 18:11:07 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <980@rc1.vub.ac.be> jcu@dec5.ulb.ac.be (Jean-Christophe Ury) writes:
>I 've  some aliases defined in my shell.I would access these aliases via
>a C program. Is it possible.

system("csh -c 'command line'");

where "command line" is a shell command line that uses your aliases, should
work.  When the C shell starts up it will source your .cshrc, which will
define the aliases.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.c
From: pal@regent.e-technik.tu-muenchen.dbp.de (Peter Loibl)
Subject: Re: pointer assignment problem
Organization: Technical University of Munich, Germany
Distribution: usa
Date: Tue, 15 Dec 1992 10:55:39 GMT

bandy@netnews.jhuapl.edu (Mike Bandy) writes:

>saud@seas.gwu.edu (Temporary account (slc 11/19/92)) writes:

>>Hi:

>>I am having problem with pointer assignment 

>>look at this pleae
>>	
>>	function_node	*tmp_node;

>>	tmp_node = (function_node *) malloc (sizeof(tmp_node));

>Think about what tmp_node is; it's a pointer to a structure.  What gets
>malloc'ed is (probably) 4 bytes of memory.  Stick a '*' in the sizeof
>to tell it to allocate how much tmp_node _points to_ .  Like:

>	tmp_node = (function_node *) malloc (sizeof(*tmp_node));

If you have something like
typedef struct function_node
{ ...
} function_node;

then you can also write
    tmp_node = (function_node *) malloc (sizeof(function_node));

Peter Loibl
pal@regent.e-technik.tu-muenchen.de
Newsgroups: comp.lang.c
From: reddy@spso.gsfc.nasa.gov (Jagan Reddy)
Subject: How to do inter process/program communication ?
Summary: How to commumicate with a child program from parent program.
Keywords: inter process communication.
Organization: Goddard Space Flight Center
Date: Tue, 15 Dec 1992 10:07:31 GMT

Hi,
	I have question many of you might have encountered already. In an
Unix environment suppose

			Program A statemnet 1;
			Program A statemnet 2;
			...
			Program A statemnet x;
			call program B with its own main();
			Now program A need to find out the status ofthe
			program A.
			if (status == SUCCESS)
				contnue;
			else
			{
				error_handler();
				return(0);
			}

		e.g: Program A would send query statment to a pseudo server
on the same machine. Upon the completion of query execution the application
(program A) need to know the status and continue or abort.

		I think there is no such spawn command as in VMS.
		System command would not return any status.

any clues.

Thanks 
Jagan
From: Aurelius@cup.portal.com (Mark Christian Barnes)
Newsgroups: comp.lang.c
Subject: Re: How to do an efficient ROTATE in C?
Date: Sat, 12 Dec 92 12:49:03 PST
Organization: The Portal System (TM)
Distribution: ba

Eric A. Raymond writes:

|C has those lovely >> and << ops for shifting, but no built in rotate
|operators?
|Anyone have an efficent way to trick a compiler into generating a
|rotate? (either direction is fine).

  Most C compilers will do rotates, i.e. logical shifts, using
the << and >> operators, when the type of argument is UNSIGNED.
Otherwise arithmetic shifts must be used to preserve the sign
of the argument.

   {
    int      sign  = -1;
    unsigned unsign = 1;

    sign   = sign   << 2; /* this should be an arithmetic shift */
    unsign = unsign << 2; /* this should be a logical shift */
   }

			Regards, Aurelius@cup.portal.com
From: hartman@ulogic.UUCP (Richard M. Hartman)
Newsgroups: comp.lang.c
Subject: Re: pointer assignment problem
Date: 18 Dec 92 18:50:58 GMT
Distribution: usa
Organization: negligable

In article <Bz9Gxp.DMz@netnews.jhuapl.edu> bandy@netnews.jhuapl.edu (Mike Bandy) writes:
>saud@seas.gwu.edu (Temporary account (slc 11/19/92)) writes:
>
>>Hi:
>
>>I am having problem with pointer assignment 
>
>>look at this pleae
>>	
>>	function_node	*tmp_node;
>
>>	tmp_node = (function_node *) malloc (sizeof(tmp_node));
>
>Think about what tmp_node is; it's a pointer to a structure.  What gets
>malloc'ed is (probably) 4 bytes of memory.  Stick a '*' in the sizeof
>to tell it to allocate how much tmp_node _points to_ .  Like:
>
>	tmp_node = (function_node *) malloc (sizeof(*tmp_node));

I tend to take the other tactic.  I *never* use a variable name
as the argument to sizeof() used in a malloc(), I always use the
type name.  e.g.:

	tmp_node = (function_node *) malloc(sizeof(function_node));

This can even be encapsulated into a generic "give me a" macro:

	#define NEW(xxx) (xxx *) malloc(sizeof(xxx))
	tmp_node = NEW(function_node);

I actually don't use the NEW macro, I just give it as an option.

The main reason I use the type is that I always know what I
wanted.  If I use the variable we have the problem you have
(forgetting the *) and ambiguity.

	ptr = malloc(sizeof(*ptr));

what does that tell me?

	ptr = malloc(sizeof(struct employee_rec));

tells me that ptr is supposed to hold employee information.

Of course, so should the declaration of ptr....

And, "ptr" may not be the best name....

However, I think it is safest and clearest to only use types
for malloc/sizeof statements and stay away from the implicit
"you figure out the type and give me one" style that using
the variable names represents.


		-Richard Hartman
		hartman@ulogic.COM

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Who knows what evil lurks in the hearts of men?"

Xref: sparky comp.lang.c:18724 gnu.gcc.help:2787
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.lang.c,gnu.gcc.help
Subject: Re: How precise is preprocessor math? (I'm using gcc)
Date: 20 Dec 92 23:57:58 GMT
Organization: McGill Research Centre for Intelligent Machines

In article <1992Dec18.104956.11433@flood.com>, tom@flood.com (Tom Chatt) writes:
> volpe@ausable.crd.ge.com writes:

>> And then the compiler evaluates it, or more likely, just the
>> constant expression part of it. (It probably isn't likely that it
>> evaluates sin(70) at compile time, but it's allowed to.)
> The compiler is allowed to evaluate routine calls at compile time???
> I think not!

In general, no; in the case of sin(), it is.  sin() (and the rest of
the stuff in ANSI's spec) are fully specified; the compiler is allowed
to know everything there is to know about them, including, in this
case, that sin() computes a value that depends on nothing but its
argument, and how to compute that value, and hence actually do so.

> Given that an arbitrary routine may be called repeatedly with a
> constant argument without any guarantee that the return value will be
> the same,

Right.  It's not allowed to do so except when calling routines it knows
behave nicely, like sin().  (This all comes under the "as if" rule: the
compiler is allowed to emit anything that behaves as if it were
executed as written.  Since a conforming program cannot tell the
difference between actually calling sin() at run-time and compiling the
resulting value into the code, the compiler is allowed to do the
computation at compile time.)

> If Chris Volpe was suggesting the more limited proposition that
> certain standard calls, such as sin(), are "known" to the compiler,

Isn't that what was said?

>> (It probably isn't likely that it evaluates sin(70) at compile time,
>> but it's allowed to.)

Nothing about evaluating any other calls at compile time.

> that's plausible, but still seems dubious.  "sin" is not a resrved
> word in C, and nothing would prevent me from writing my own "sin()"
> routine which did something completely different.

Since ANSI, it effectively is a reserved word, when it occurs as an
identifier with external scope.  You can write you own sin(), yes,
provided you declare it with file scope, and in that case, the compiler
is not justified in constant-folding it.  (I think you may also have to
either omit <math.h> or #undef sin; not sure.)

> Even if [...], there would still be different implementations, and a
> compiler would be presumptuous to pick one for me.

Huh?  sin() computes the sine function.  The implementation is
irrelevant; only the return value matters.  The compiler may use a
completely different implementation from the run-time version, but *you
can't tell*, because the return value is - must be! - the same.

> [T]he "sin" routine being used by the example above apparently
> expects degrees.

If so, that's a bug in the program.  sin() is specced to take its
argument in radians.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
Newsgroups: comp.lang.c
From: bandy@netnews.jhuapl.edu (Mike Bandy)
Subject: Re: a question about if and case
Organization: JHU/Applied Physics Laboratory
Date: Mon, 14 Dec 1992 18:11:12 GMT

"hans friedrich steffani" <GM08@DKAUNI2.BITNET> writes:


>i have something like

>int i;

>if( i == 1 || i == 25 || i == 125 )
> {
>  /* do something sophisticated */
> }
>if( i == 2 || i == 30 || i == 244 )
> {
>  /* do something different */
> }

>or should i use

>switch( i )
> {
>  case 1:
>  case 25:
>  case 125:
>  /* do something sophisticated */
>  break;

>  case 2:
>  case 30
>  case 244:
>  /* do something different */
>  break;

>  default:
>  break
> }

IMHO people worry about this sort of thing too much.  The important thing
is to develop a strong *maintainable* style.  The performance differences
are insignificant, so do what you thing works best.

-- 

	Mike Bandy
	bandy@aplcomm.jhuapl.edu
	Johns Hopkins University / Applied Physics Lab
Newsgroups: comp.lang.c
From: draper@ais.org (Patrick Draper)
Subject: Re: Does any one know about c-tree /r-tree ?
Organization: UMCC
Date: Sun, 20 Dec 1992 02:07:42 GMT

In article <1992Dec18.163357.21724@jarvis.csri.toronto.edu> jinl@csri.toronto.edu (Jin Liu) writes:
>
>   Hi, has any one used CTREE or RTREE package (I'm using c-tree
>   Plus ver.6.0)?  To build a database, basically there are two ways,
>   one is with Lowlevel functions, the other is with ISAM functions.
>   I noticed they are quite memory consuming. I thought Lowlevel function

Don't know too much about comparative memory usage, but on a DOS executable,
the minimum size seems to be about 170-180 K of EXE size. We use the ISAM
functions mostly.


------------------////////////////////\\\\\\\\\\\\\\\\\\\\------------------
| Patrick Draper-ZBT       Disclaimer:  I can't control my fingers,        |
| draper@umcc.ais.org                   I can't control my toes! - Ramones |
| University of Michigan Computer Club                                     |
NO CARRIER                     We are a nation of laws, not people         |
------------------\\\\\\\\\\\\\\\\\\\\////////////////////------------------

Newsgroups: comp.lang.c
From: g0pereir@cdf.toronto.edu (Rui M. Pereira)
Subject: Re: Power C(Mix) and PDS .OBJ
Organization: UofT.Terra.Sol.Western-Spiral-arm.Milky-Way.Universe
Date: Fri, 18 Dec 1992 16:31:16 GMT

ST21519@VM.CC.LATECH.EDU writes:
| I believe one cannot take Power C's .OBJ code and link it with PDS's Link,
| but can you maybe take PDS .OBJ code and link with Power C to get the best
| of both worlds?


Power C comes with a program called (appropriately) 'MIX'.  According
to the manual, it converts .OBJ files to .MIX files, which you can
then use the linker (pcl) on.  You'll have to know how the function
names are stored on the PDS .OBJ file (e.g.  all caps, leading caps,
no caps, with/out a leading _) in order to make use of the functions
in a program.

-- 
 -=[Rui M. Pereira]=- <g0pereir@cdf.toronto.edu>|<rui@r-node.{pci.on.ca|uucp}>
  DANGER:  This user's Brain has been declared non-functional with null	
     pointers and extremely volatile memory.  You have been Warned!
Newsgroups: comp.lang.c
From: perryd@cognos.COM (Perry Devetzis)
Subject: Re: Questions about token merging and trigraphs
Organization: Cognos Incorporated, Ottawa CANADA
X-Newsreader: Tin 1.1 PL3
Date: Wed, 16 Dec 1992 19:14:32 GMT

misar@rbg.informatik.th-darmstadt.de (walter misar) writes:

     ... Stuff about token merging deleted

: 
: > (2) There is a command-line switch to disable the 'trigraph' feature
: > in the gcc compiler.  What are trigraphs?  From the comments in the
: > gcc documentation I gather that they are something that the ANSI
: > committee has added to C and that Richard Stallman doesn't care for
: > them.  If that is the case, I'm wondering what purpose the ANSI
: > committee saw for them, why anyone would object to them, and, most
: > importantly, what they are.
: 
: Trigraphs are only of interest, if your machine hasn't got a full set of ASCII
: characters. All begin with ??, only following nine replacements take place:
: ??( [   ??< {   ??' ^
: ??) ]   ??> }   ??- ~
: ??= #   ??! |   ??/ \ 
: The replacement takes effect before any other preprocessor action, thus ??/
: may be used at the end of a line to merge it with the next. In general, I can't
: see a good reason for it - I can't believe one will actually programm s.th like
: this (Yeah it's ANSI)
: 
: ??=include <stdio.h>
: int main(int argc,char * argv??(??))
: ??<
: printf("Hello world !")
: return 0;
: ??>
: 
: Worse, trigraph can turn otherwise correct programs into garbage (especially
: ??! is a prime candidat)
: -- 
: Walter Misar                        It is impossible to enjoy idling thoroughly
: misar@rbg.informatik.th-darmstadt.de       unless one has plenty of work to do.

	Granted trigraphs are really stupid but you are forgetting the primary
reason that they exist.  Machines that don't use ASCII!  I am speaking
of course of the vast majority of IBM machines that use EBCDIC and don't 
even have some of the characters listed above.  Or the character are not
available on IBM keyboards. 

	They are meant to be a lowest common denominator.  No matter what system
or which character set you use your 'C' program will compile.  It may not
run but it will compile.

Ta Dah...Perry

Perry Devetzis                           Cognos Incorporated
Voice   : (613) 738-1338 ext.3224        3755 Riverside Dr.
Fax     : (613) 738-0002                 P.O. Box 9707
UUNet   : perryd@cognos.UUCP             Ottawa, Ontario
Internet: perryd@cognos.COM              CANADA  K1G 3Z4
Newsgroups: comp.lang.c
From: millertr@cuugnet.cuug.ab.ca (Trever Miller hm 276-2120 wk 263-2600)
Subject: Re: Executing Code during SYSTEM() calls?
Organization: Calgary UNIX Users' Group Association
X-Newsreader: TIN [version 1.1 PL8]
Date: Wed, 16 Dec 1992 13:16:47 GMT

jwilson@kuhub.cc.ukans.edu wrote:
: I am working on writing a front end program which will transfer
: files from a VAX/VMS system to a SUN/UNIX system via FTP.  I have
: the file handling and idiot-proofing done but I have not discovered
: a method of using the FTP mechanism while the c code is still executing.
: I have been using the ANSI function system().  However, once the intrepreter
: has control of the system, I can no longer issue commands to login to the
: sun system with USER and PASSWD.  It is necessary to hide the login from
: the user for reasons of simplicity and security.  Does anyone know of a
: mechanism which 'C' or FTP provides to accomplish this task?  Any help
: would be greatly appreciated.

I got the guts of this (pipe/dup/execlp) from "Advanced Unix Programming"
by Marc J. Rochkind, and then hacked it from there.  It should be
modifiable for your ftp driver.

/*
** weather.c
*/

#include <stdio.h>
#include <stdlib.h>

#ifndef TRUE
# undef TRUE
# undef FALSE
# define TRUE 1
# define FALSE 0
#endif

void waitfor(char *trigger);
void send(char *spew);

FILE *To_Telnet, *From_Telnet;
int Capture = FALSE;

int main(int argc, char **argv)
{
	int  pfdout[2], pfdin[2];
	
	pipe(pfdout);                        /* make some pipes */
	pipe(pfdin);

	To_Telnet = fdopen(pfdout[1],"a+"); /* get proper streams happening */
	From_Telnet = fdopen(pfdin[0],"r");

	if(fork() == 0) /* child */
	{
		close(0);		/* hook stdin/out up to the pipes */
		dup(pfdout[0]);
		close(1);
		dup(pfdin[1]);

		close(pfdout[0]);	/* close unneeded fd's */
		close(pfdout[1]);
		close(pfdin[0]);
		close(pfdin[1]);

		printf("Child - firing up telnet\n");
		fflush(stdout);
		execlp("telnet","telnet","madlab.sprl.umich.edu","3000",NULL);
		fprintf(stderr,"\nfell thru execlp?\n");
		exit(1);
	}

	/* parent */

	close(pfdout[0]); /* close unneeded fd's */
	close(pfdin[1]);

	waitfor("code:");     send(""); /* null means just send newline */
	waitfor("election:"); send("c");
	waitfor("election:"); send("4");
	waitfor("election:"); send("2");
	waitfor("election:"); send("1");

	Capture = TRUE;
	waitfor("election:"); send("X");
	sleep(5);
	exit(0);
}

void send(char *spew)
{
	fprintf(To_Telnet,"%s\n",spew);
	fflush(To_Telnet);
}

void waitfor(char *trigger)
{
	char c;
	int i=0;
	char buf[512];

	for(;;)
	{
		c=fgetc(From_Telnet);
		if(Capture == TRUE && c != 13)
		{
			putc(c,stdout);
			fflush(stdout);
		}
		buf[i++]=c;
		buf[i]=NULL;

		if(strstr(buf,trigger)!=NULL) /* found it? break out if so */
			break;

		if(c=='\n' || i>=(sizeof(buf)-2))
			i=0;
	}
}

: -Jason
: jwilson@kuhub.cc.ukans.edu

Yeah, it's primitive, but it works.  Enjoy.

Trever

--
#include <standard.disclaimer>                "Boot to the head! Nyah Nyah!"
                                                       - The Frantics
Internet : millertr@cuug.ab.ca (preferred)  
           trever%pixel@fsa.cpsc.ucalgary.ca    PGP2.0 PubKey avail on request
From: hoh@lorelei.approve.se (Goran Larsson)
Newsgroups: comp.lang.c
Subject: Re: SCCS eats good code -- help requested
Date: 20 Dec 92 20:15:22 GMT
Organization: Home of the Hacker of Hackefors

In article <1992Dec18.215413.65833@evolving.com> jww@evolving.com (John W. Woolley) writes:

>Evolving Systems recently began using a new source control system,
>CMVC, which as I understand it is a wrapper around SCCS.  The new
>source control system interacted with our code in an unintended way.

>We had a chunk of source so:
>  if (strftime(time_str, 64, "%w%H%M%S", time_struct) != 7)
>
>Nice normal ANSI C.  But SCCS had spotted the string %H% in the
>above bit of code, and had done its replacement thing so:
>
>  if (strftime(time_str, 64, "%w12/14/92M%S", time_struct) != 7)
>
>which caused strftime to yield results differing somewhat from those
>intended.

The handling of these version strings is in itself a very good reason
to avoid SCCS. The decision to only expand version strings when compiling
is wrong. If I send source to someone, I want to expand version strings
so "someone" can report problems - but "someone" might also want to
keep the source under revision control system. SCCS can't do this. RCS can.

>So does anyone know anything good we can do about this?  We can't be
>the first site ever to struggle with format strings and SCCS.

1) find /usr -name sccs -exec rm -rf {} \;

2) Install RCS

3) Use RCS

btw  :-)
-- 
 Gvran Larsson                   Phone: +46 13 155535  FAX: +46 13 160533
 Approve AB                             +46 589 12810       +46 589 16901
 hoh@lorelei.approve.se               ...!uunet!mail.swip.net!lorelei!hoh
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: Question to test general C knowledge
Date: 12 Dec 92 23:05:20 GMT
Organization: McGill Research Centre for Intelligent Machines

In article <1992Dec11.180939.20726@crd.ge.com>, volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe) writes:
> In article <1992Dec11.091819.26636@thunder.mcrcim.mcgill.edu>, mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
>> In article <19980@ksr.com>, jfw@ksr.com (John F. Woods) writes:

>>> 	int i = 2;
>>> 	i = ++i;
>> "Anything or nothing.  3 seems most probable, with 4 next."
>                                                ^^^^^^^^^^^^
> Why?

Based on a sequence like

        ! compute needed values
        addl3   _i,$1,r0        ! compute value of ++i
        ! sequence point; do accumulated side-effects
        movl    r0,_i           ! store value of ++i into i
        incl    _i              ! increment i

Thus we see the wisdom of ANSI's rule :-)

> The effect of the "++" is to assign 3 to i.

The effect of the ++ is to increment i.  Whether this results in
assigning 3 to it depends on whether it still has the value 2 when the
increment gets around to happening.

> (Other than, of course, a vindictive compiler that detected
> violations of the letter of the law and went out of its way to give
> you garbage.)

I have often wished that compilers had a flag that said "please be as
perverse as you can and break as many invalid assumptions as you can",
as an aid to bug-finding.  gcc with loads of warnings turned on is
fairly good at finding invalid code, but there are some things that it
by its nature can't do.  For example,

double sqrt(double);
int isqrt(int);

struct {
  char *name;
  int type;
#define T_D_D 1 /* double xxx(double) */
#define T_I_I 2 /* int xxx(int) */
  void (*fn)(void);
  } optable[] = { { "sqrt", T_D_D, (void (*)(void)) sqrt },
                  { "isqrt", T_I_I, (void (*)(void)) isqrt },
....
                  { 0 } };
....
 for (i=0;optable[i].name;i++)
  { if (!strcmp(optable[i].name,opname))
     { switch (optable[i].type)
        { case T_D_D:
             push_result( TYPE_DOUBLE,
                          (*(double (*)(double))optable[i].fn)
                                (*(double *)pop_value()) );
             break;
          case T_I_I:
             push_result( TYPE_INTEGER,
                          (*(double (*)(double))optable[i].fn)
                                (*(double *)pop_value()) );
             break;
....

Now, the T_I_I case is broken: the casts should be (int (*)(int)) and
(int *).  But the compiler is required to accept the code anyway; it
takes run-time checking to catch this.  (This is not real code, but
very similar code is likely to exist in interpreters of some sorts.)
Nonetheless, on some systems, it may work anyway because doubles are
passed and returned in ways similar to those use for ints....

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: A better mousetrap
Date: 11 Dec 92 19:47:03 GMT
Organization: McGill Research Centre for Intelligent Machines

In article <alien.01tq@acheron.amigans.gen.nz>, alien@acheron.amigans.gen.nz (Ross Smith) writes:
> In article <18287@mindlink.bc.ca> Marc_North@mindlink.bc.ca (Marc North) writes:

>> [...uuencode...less expansion ratio...]

>    Standard uuencode (?) : log(256)/log(69) = 1.3096

Standard uuencode expands by 3:4, plus M characters and line breaks;
fiddling with logarithms is a meaningless exercise when the encoding
method is well-defined.  It's fewer than 69, though, since any system
that can't take lower case probably can't take a bunch of other
characters too; uuencode is careful to limit itself to a relatively
portable set of characters.  (For example, all the characters uuencode
uses are the same under ASCII->EBCDIC->ASCII mapping with any known
version of the mapping for each step.)

>    Limit using ASCII : log(256)/log(95) = 1.2177

I'm glad someone finally did this little bit of arithmetic.

> (BTW, does anyone know *why* uuencode uses only uppercase letters?
> Surely no mail/news system is so braindead that it mangles case?)

Can you say "card images"?  Gooooood!  (Notice that uuencode format is
also tolerant of having every line padded with spaces to 80 columns.)

Few systems will mangle case nowadays.  But they exist, and back when
uuencode was first written, they were (apparently) common enough that
they had to be kludged around.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu