Date: Sun, 10 Aug 1997 04:05:08 -0400 From: "Joel N. Weber II" <devnull@gnu.ai.mit.edu> To: wpaul@skynet.ctr.columbia.edu Cc: chat@FreeBSD.ORG Subject: Re: variable sized arrays and gcc Message-ID: <199708100805.EAA04922@ethanol.gnu.ai.mit.edu> In-Reply-To: <199708100722.DAA03236@skynet.ctr.columbia.edu> (message from Bill Paul on Sun, 10 Aug 1997 03:22:28 -0400 (EDT))
next in thread | previous in thread | raw e-mail | index | archive | help
I believe that this is mentioned in the info file for glibc 1.09
near the description of alloca. I don't know if it's in the gcc manual.
I think you could get the same effect with something like
char *buf;
buf = alloca (strlen(str) + 10);
Note that most GNU hackers try to write code that will compile on any
ANSI C compiler anyway, although the Hurd hackers write code which
depends on new versions of gcc.
It will be interesting to see if five or ten years from now, GNU packages
continue to support all Un*x systems, or if they will just support
Hurd. I suspect that we'll keep the existing flexibility, since many
GNU hackers will likely ahve reasons to use kernels other than Hurd
(like the fact that FSF has some old HP300s, one of which the Hurd hackers
use as an X terminal; I doubt those machines will ever run Hurd, but NetBSD
runs fine on them).
From: Bill Paul <wpaul@skynet.ctr.columbia.edu>
Date: Sun, 10 Aug 1997 03:22:28 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-freebsd-chat@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk
This technically isn't a problem with FreeBSD so I think it's best to
post about it here. Earlier tonight I was looking through a snapshot
of some of the Linux NIS+ client code when I noticed something that
just struck me as really strange. Basically, there was code like the
following:
int some_random_function(str)
char *str;
{
char buf[strlen(str) + 10];
/* do some junk */
return(0);
}
The problem here is that the array 'buf' is being declared with
a variable size. My mommy always told me that you couldn't do that:
buf[10] is okay, buf[strlen(foo) + 10] is not. At first I thought I
was losing my marbles, but it that seems gcc will compile this code.
No other compiler I tried would though (the SunOS 4.1.x unbundled ANSI C
compiler, Solaris 2.5.1 unbundled C compiler, HP-UX 10.20 ANSI C
compiler, SGI IRIX C compiler and the IBM AIX 4.1.x C compiler all
complained about the variable sized array and aborted compilation).
Gcc will not complain about this unless you use -ansi -pedantic:
even then you get a warning, but it compiles the code anyway.
Okay, maybe I haven't been paying attention, but this is the first
time I've ever noticed that gcc would let you do this. Personally,
I think it's damn strange, especially since _no_ other C compiler I
can find behaves the same way. (Well, no other UNIX C compiler; I don't
have an M$ C compiler or Borland or Watcom C compiler handy so I
don't know what those do. Elvis only knows what horrors M$ Visual C++
lets you perpetrate.) If it's a feature, I don't think it's a
particularly good one since it encourages the use of non-ANSI (and
apparently non-portable) code. If it's a bug, it's got to be the most
carefully engineered bug of all time. :)
Is this a side-effect of GNU C and GNU C++ being joined together at
the hip, or did I just miss a memo somewhere?
-Bill
--
=============================================================================
-Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu
Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research
Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
=============================================================================
"It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
=============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708100805.EAA04922>