Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!uunet!codonics!bret
From: bret@codonics.COM (Bret Orsburn)
Newsgroups: comp.lang.c
Subject: Re: Zero Length Arrays Allowed in C Standard?
Message-ID: <526@codonics.COM>
Date: 7 Dec 89 04:58:05 GMT
References: <2298@jato.Jpl.Nasa.Gov> <11715@smoke.BRL.MIL> <480@codonics.COM> <1989Dec2.210042.12668@twwells.com>
Reply-To: bret@codonics.com (Bret Orsburn)
Organization: Codonics, Inc., Middleburg Heights, OH
Lines: 63

Too bad I was out of town and missed most of the fun on this one!

In article <1989Dec2.210042.12668@twwells.com> bill@twwells.com (T. William Wells) writes:
>In article <480@codonics.COM> bret@codonics.com (Bret Orsburn) writes:
>: >No; Standard C does not support zero-sized objects.
>:
>: Aargh! Whatever happened to "don't break existing code"?!
>:
>: What was the rationale behind this (IMHO) arbitrary obstruction?
>
>Here we !@#$ing go again. Someone mistaking the details of their
>particular implementation for legal C.

Read my posting again.

I did not say (a) zero length objects are a Good Thing, (although some of
the follow-ups have got me pretty convinced) or (b) zero length
objects are portable, or (c) zero length objects are widely implemented.
I certainly don't "mistake the details of [my] particular implementation
for legal C." In fact, the C I have been working in for the last three
years is a dialect that runs on a *bit* *addressable* processor. I have *no*
illusions about any of that code being standard or portable. (Although
T.W. Wells has used a wonderful piece of ex post facto reasoning there,
as it is precisely the ANSI standard that will determine what is "legal C". :-)

>This "arbitrary obstruction" is common practice; most of the C
>compilers I've worked with do *not* support zero sized objects.

Which doesn't change the fact that some existing code uses zero sized
objects, and that such code will be broken by the ANSI restriction.

>I like the idea but life is that it is not portable.

And life is also that portability is not an issue and not an option for
a lot of software. A lot of us use C primarily as an assembly language
substitute and develop code that is as un-portable as the special-purpose
systems we have built. (Try porting the device drivers from a custom-designed
embedded system some time!)

(Please direct all wonderful anecdotes about that piece of code you never
thought you'd have to port to /dev/null. :-)

But that is ALSO not the point of my original posting.

>That ANSI chose not to require it is unfortunate but does not
>change anything for those of us who believe that programs should
>be portable.

"That ANSI chose not to require it" is ALSO not the point of the original
posting. That ANSI chose to FORBID it is the point. And that ANSI chose
to forbid it in the face of existing implementations and existing code
deserves at least an "Aargh!".

Well, I've had my turn. Thank you all for your time.

Cheers!


-- 
-------------------
bret@codonics.com
uunet!codonics!bret
Bret Orsburn