[comp.os.minix] Bug in Minix C compiler

rmtodd@uokmax.UUCP (Richard Michael Todd) (07/04/87)

When porting John Gilmore's PD tar to MINIX, I discovered an incompatibility
between MINIX's C compiler and others.  The code contained numerous 
constructs of this form:
	struct stat statbuf[1];
	...
	size = statbuf->st_size;
The MINIX C compiler objects violently, saying "error: -> applied to array".
Aztec C gives warnings but creates correct code output.  UNIX C compilers
obviously see nothing wrong with this, and my reading of K&R is that there
is nothing wrong with this construct -- whenever array names appear they
are converted to pointers, and -> is a valid operation on a pointer to a
structure.
___________________________________________________________________________
Richard Todd
USSnail:820 Annie Court,Norman OK 73069
UUCP: {allegra!cbosgd|ihnp4}!okstate!uokmax!rmtodd

dtynan@altos86.UUCP (Dermot Tynan) (04/08/89)

I don't know if anyone has noticed this, but
	ch = *"ABCDEF";

doesn't work.  Before anyone bitches about using such code, INEWS does the
following;

#define STRCMP(a, b)	(*(a) == *(b) ? strcmp((a)+1, (b)+1) : *(a) - *(b))

Or something to that effect.  Anyway, it doesn't work with the latest &
greatest version of the compiler.  Comments?
					- Der
-- 
Favored Path:	dtynan@zorba.Tynan.COM  (Dermot Tynan @ Tynan Computers)
Otherwise:	{apple,mips,pyramid,uunet}!zorba!dtynan

  ---  If God wanted us to fly, he would have given us Hang-Gliders  ---

regan@jacobs.CS.ORST.EDU (Dave Regan) (07/02/90)

While working with the "uux" program, I found a possible bug in the
C compiler.

Consider the following test file:
	char	array1[1000] = "test";
	char	array2[1000];

Both of these arrays should be 2000 bytes long with "array1" having
the first 5 bytes initialized.  However, this is not what the compiler
generates.  Type:
	cc -S test.c
	libupack <test.s >test.S

You get the following:
	.globl _array1
	.data
	_array1:			| 3 words of storage
	.word 25972
	.word 29811
	.globl _array2
	.word 0
	.bss
	_array2: .zerow 1000/2		| 500 words of storage
	.text

I am running with 1.5.10 and current compiler binaries.

I am currently avoiding the problem by initializing arrays at runtime.
I am sorry if this has been brought up before; I hadn't noticed before.

			regan@jacobs.cs.orst.edu

kjh@pollux.usc.edu (Kenneth J. Hendrickson) (07/02/90)

New material follows this reply.  Keep on reading.

In article <19169@orstcs.CS.ORST.EDU> regan@jacobs.CS.ORST.EDU (Dave Regan) writes:
>I found a possible bug in the C compiler.
>Consider the following test file:
>	char	array1[1000] = "test";
>	char	array2[1000];
>Both of these arrays should be 2000 bytes long with "array1" having
>the first 5 bytes initialized.

Both should be 500 bytes long.  Also, if they are declared static
outside a function, they they should go in the .bss segment, and
they should be initialized to 0's unless explicitly initialized to
another value.

>You get the following:
>	.globl _array1
>	.data
>	_array1:			| 3 words of storage
                                        ^^^^^^^^^^^^^^^^^^^^
You are right here.  This is a SERIOUS BUG!  There should be 500 words
of storage allocated, instead of only 3.

>	.word 25972
>	.word 29811
>	.globl _array2
>	.word 0
>	.bss
>	_array2: .zerow 1000/2		| 500 words of storage
>	.text
>I am currently avoiding the problem by initializing arrays at runtime.

Smart.  Very smart.

>I am sorry if this has been brought up before; I hadn't noticed before.

Thanks for bringing it up.  We all needed to see this.

BEWARE YE, BEWARE YE, BEWARE YE:
If you declare static variables outside of a function, and initialize
them, they go in the .bss segment in the order in which they are declared.
If you declare static variables outside of a function, and do not
initialize them, then they go in the .bss segment in the opposite order
from which they are declared.  (This is the way the Minix C compiler
does it.)

The wise guy that wrote crypt() for BSD wrote code that was system
dependant, and required that variables would go into the bss segment in
the order in which they were declared.  While he probably thought he
was very clever, his code jumped up and bit me in the *ss.

Now maybe the wise guy was wiser than I, and K&R insist that variables
go into their respective segments in the order in which they are
declared.  However, I am not aware of this.  If I was defining the C
language, I would not have done it this way.  Of course, if K&R did do
it this way, that means the Minix C compiler is broken.

Ken Hendrickson N8DGN/6      kjh@usc.edu      ...!uunet!usc!pollux!kjh