[net.micro.amiga] possible bug in 1.1 file redirection

mende@topaz.RUTGERS.EDU (Mende) (07/25/86)

  I am posting this for a friend of mine who has no access to the net.
I have looked at the problem and it baffles me.  So here it is....


/*
I am programming on an Amiga with Aztec C (developer's package) and have come
accross the following problem. It may be a bug in the Aztec compiler or a
bug in AmigaDOS.  My program is simply a filter to do a word-wrap on standard
ASCII files.  The program below is just enough to demonstrate the problem.
The below program should read standard input (line by line) and output it
(line by line) to standard output.  When I compile this (or the filter) and
issue the command:  THRU <MYFILE
Everything is fine.  If I issue the command:  THRU <MYFILE >FOO
then:  TYPE FOO
the output is different.  The end is cut off.  Why would this work if the
IO is sent to the screen but not to a file?  I have written filters before
but they worked purely on a getchar()/putchar() basis.  Could I be misusing
the fgets()/fputs() commands?

P.S.  THRU <MYFILE >* works fine too!
*/

#include <stdio.h>
#define MAXLINE	100
main()                  /* Program thru.c */
{
	register char *line[MAXLINE];

	while ( (fgets(line, MAXLINE, stdin)) != 0 )
		fputs(line, stdout);
}


                    Bob Mende
               posting for Tom Limoncelli

ARPA: MENDE@AIM.RUTGERS.EDU
UUCP: {anywhere}!{topaz!caip}!aim!mende

jdt@bucsb.bu.edu.UUCP (Dave Tenny) (07/31/86)

[...]
It sounds like you're not having all the output flushed to stdout.
When using Amiga Aztec C, be sure to use exit() in your main program,
or stdout may not be flushed.  This does not happen with Lattice,
since the _main() program does a exit() for you, if you return from main().

higgin@cbmvax.cbm.UUCP (Paul Higginbottom) (08/03/86)

In article <5420@topaz.RUTGERS.EDU> mende@topaz.RUTGERS.EDU (Mende) writes:
>I am programming on an Amiga with Aztec C (developer's package) and have come
>accross the following problem. It may be a bug in the Aztec compiler or a
>buf in AmigaDOS.

Note the programmer's ego - it couldn't be your program! 8-)

>My program is simply a filter to do a word-wrap on standard
>ASCII files.  The program below is just enough to demonstrate the problem.
>The below program should read standard input (line by line) and output it
>(line by line) to standard output.  When I compile this (or the filter) and
>issue the command:  THRU <MYFILE
>Everything is fine.  If I issue the command:  THRU <MYFILE >FOO
>then:  TYPE FOO
>the output is different.  The end is cut off.  Why would this work if the
>IO is sent to the screen but not to a file?  I have written filters before
>but they worked purely on a getchar()/putchar() basis.  Could I be misusing
>the fgets()/fputs() commands?
>
>P.S.  THRU <MYFILE >* works fine too!
>*/
>
>#include <stdio.h>
>#define MAXLINE	100
>main()                  /* Program thru.c */
>{
>	register char *line[MAXLINE];
>
>	while ( (fgets(line, MAXLINE, stdin)) != 0 )
>		fputs(line, stdout);
>}
>
>
>                    Bob Mende
>               posting for Tom Limoncelli
>
>ARPA: MENDE@AIM.RUTGERS.EDU
>UUCP: {anywhere}!{topaz!caip}!aim!mende

1) register char *line[MAXLINE] is meaningless.  What you've declared is
an array of pointers to chars, not an array of chars, and I expect the
compiler ignores the attempt to put an array in a register 8-).

2) fgets() returns the address of the buffer (in this case 'line') if all
goes well, and NULL upon EOF or an error.  You have not externed fgets()
but if you're compiling with the 32 bit ints option, all will work (although
it's sloppy).  I'm not attacking your programming style, I realize you just
gave the example to get the message across.  BUT - if you're using 16 bit
ints and compiled the above, you would get unpredictable results, e.g if
the low (or high, I'm not sure) word of the result of fgets which is not
externed is 0 the program will stop (probably not what you want).

Hope this helps,
		Sincerely,
			Paul Higginbottom

Disclaimer: I do not work for Commodore, my opinions are my own, and I probably
won't be around to see any replies to this.