NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/lang/c/19088

Internet Message Format | 1992-12-31 | 3.7 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!crdgw1!rdsunx.crd.ge.com!bart!volpe
From: [e-mail] (Christopher R Volpe)
Newsgroups: comp.lang.c
Subject: Re: Arrays with variable dimensions?
Message-ID: <[e-mail]>
Date: 31 Dec 92 19:29:50 GMT
References: <[e-mail]> <[e-mail]>
Sender: volpe@bart (Christopher R Volpe)
Reply-To: [e-mail]
Organization: GE Corporate Research & Development
Lines: 71
Nntp-Posting-Host: bart.crd.ge.com

In article <[e-mail]>, [e-mail] (Bernard Farrell) writes:
|> [e-mail] (D'Arcy J.M. Cain) writes:
|> : [e-mail] (Bernard Farrell) writes:
|> : >[e-mail] (John B. Lee) writes:
|> : >: Is it possible to create an array that would change size according
|> : >: to user input?
|> : >float fl_arr[] = NULL;   /*  This is actually a float * -- no space  */
|> :
|> : You didn't even try this did you?  This actually does assign space to an
|> : array.  I don't know what your compiler does with the "= NULL" but assuming
|> : it even accepts it (mine doesn't) it certainly doesn't do what you think it
|> : does.  If you want a float * why didn't you just declare that:
|> :
|> : float *fl_arr = NULL;
|> :
|>
|> D'Arcy,
|>
|> First of all, the approach I've outlined works for me on a number
|> of machines.  Second, ff I'm going to treat the pointer as an array,
|> I'd rather make this OBVIOUS in the declaration, even if the variable
|> name does help.

Bernard,
  I hate to tell you this, but D'Arcy is absolutely right and you are
dead wrong. Pointers are not arrays, no matter how much they look alike
in usage. Incorrect declarations will get you into trouble. The approach you
outlined shows a misunderstanding of the differences between pointers and
arrays. I will reiterate the faulty declaration above and explain what it
actually means and what is actually being done (most likely) on YOUR machine:

    float fl_arr[] = NULL;   /*  This is actually a float * -- no space  */

The reason your compiler doesn't complain is that on your machine, NULL is
defined as "0" (a perfectly legitimate definition) and thus the declaration
becomes "float fl_arr[] = 0;". Technically, "0" is an invalid initializer
list for an array, but your compiler seems to have an extension that allows
you to omit braces for an aggragate initializer when there is only one
element in the initializer list. So, the declaration is effectively
"float fl_arr[] = {0};", which initializes an array of one element to
contain the value 0.0. Note that the length of the initializer list implicitly
determines the size of the array, even though the size was omitted between
the brackets. It's the same as saying "float fl_arr[1] = {0};".

The resulting array CANNOT be dynamically resized. The identifier
"fl_arr" cannot be used on the left side of an assignment, as
in "fl_arr = malloc(n * sizeof(float));" This is a constraint violation,
and a conforming implementation is required to diagnose it.

The reason D'Arcy's compiler would not accept the initial declaration
is probably twofold: One, his NULL may be defined as "(void *) 0", a
perfectly good definition of NULL, but not a valid initializer for
a float. Two, his compiler may very well reject an array initialization
(except for char arrays being initialized with string literals, of course)
in which braces are omitted.

|>
|> I'd be interested to know the kind of machine you compiled this
|> on, the ones I've done this before on may not be very ANSI compliant.

I probably missed the rest of your outlined method, but judging by your
comment to the right of the declaration, I would imagine it's quite
illegal.

-Chris

--
==================
Chris Volpe
G.E. Corporate R&D
[e-mail]