From owner-freebsd-hackers  Thu Aug 14 07:45:54 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id HAA21139
          for hackers-outgoing; Thu, 14 Aug 1997 07:45:54 -0700 (PDT)
Received: from eiche.bik-gmbh.de (eiche.bik-gmbh.de [194.233.237.94])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA21134
          for <hackers@freebsd.org>; Thu, 14 Aug 1997 07:45:49 -0700 (PDT)
Received: from localhost (lgk@localhost)
	by eiche.bik-gmbh.de (8.8.5/8.8.5) with SMTP id QAA20138;
	Thu, 14 Aug 1997 16:44:37 +0200 (CEST)
Date: Thu, 14 Aug 1997 16:44:37 +0200 (CEST)
From: Lars Gerhard Kuehl <lgk@BIK-GmbH.DE>
To: hackers@freebsd.org
cc: peters@skye.icr.ac.uk, cracauer@cons.org
Subject: gcc bug?
Message-ID: <Pine.BSF.3.96.970814163730.19864A-100000@eiche.bik-gmbh.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk



I just encountered quite a seriously strange behaviour
of gcc (2.7.2.1 of 2.2.2-RELEASE) (maybe I've only
well slept and it's already well known ;).

In a program, reading, occasionally manipulating and writing
a fairly long string the strings get unhappily shortened.
Well I thought I made mistake but it turned out to be a compiler
'option':

Using '-O' option:

*	/* some stuff */
*
*	fputs(ln, iost->d_out);

or

*	/* some stuff... */
*	/* llen and strlen(ln) are expected to be equal */
*
*	if ( llen != strlen(ln) );	/* <- nota bene */
*	fprintf(iost->err, "mist: %d, %d\n", strlen(ln), llen);
*
*	fputs(ln, iost->d_out);

cause the line to contain an undesired '\0' somewhere, long before
its end.

*	/* some stuff... */
*
*	if ( llen != strlen(ln) )	/* <- nota bene */
*		fprintf(iost->err, "mist: %d, %d\n", strlen(ln), llen);
*
*	fputs(ln, iost->d_out);

In this case the condition is never true, i.e. the string is not
truncated.
'ln' is a 10240 byte long char array on the stack of main(). If declaring
'ln' static, the string is truncated at a different location but anyway it
is cut as well.

This does not happen if compiling with a higher optimisation level or
without at all. Do I remember correctly that the kernel is compiled with
option '-O'?	:-)

Lars