Re: Question about genassym, locore.s and 0-sized arrays(showstopper for an icc compiled kernel)
On Sat, Sep 06, 2003 at 10:57:52AM +0200, Alexander Leidinger wrote:
>
> ---snip---
> % #include
>
> struct foo {
> int tag;
> char obj[];
> };
>
> int main(void) {
> struct foo bar;
>
> printf("%d\n", sizeof(struct foo));
> printf("%d\n", sizeof(bar));
>
> return 0;
> }
>
> % ./a.out
> 4
> 4
> ---snip---
The compiler seems to behave correctly WRT C99. However, when
presented with code that uses extensions the compiler behaves
inconsistently or erratically. If the compiler cannot do any-
thing useful with zero-sized arrays, it should reject them
completely. Only then can one reasonably fall back on C99 to
explain the behaviour of the compiler. However, since the
compiler accepts zero-sized arrays, it is already in violation
with C99 and one cannot use C99 as a basis to explain the
any behaviour of the compiler in the context of the non-compliant
construct. The creation of single-element array instead of
the declared zero-element array is downright broken.
My $0.02
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about genassym, locore.s and 0-sized arrays(showstopper for an icc compiled kernel)
On Sat, 6 Sep 2003 01:42:59 -0700
John-Mark Gurney <[EMAIL PROTECTED]> wrote:
> Alexander Leidinger wrote this message on Sat, Sep 06, 2003 at 10:33 +0200:
> > struct {
> ^ try moving foo to here.
> > int tag;
> > char obj[];
> > } foo;
> ^^^ from here.
>
Uhm... yes, sorry.
---snip---
%
struct foo {
int tag;
char obj[];
};
int main(void) {
struct foo bar;
printf("%d\n", sizeof(struct foo));
printf("%d\n", sizeof(bar));
return 0;
}
% ./a.out
4
4
---snip---
Bye,
Alexander.
--
Yes, I've heard of "decaf." What's your point?
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about genassym, locore.s and 0-sized arrays(showstopper for an icc compiled kernel)
Alexander Leidinger wrote this message on Sat, Sep 06, 2003 at 10:33 +0200:
> struct {
^ try moving foo to here.
> int tag;
> char obj[];
> } foo;
^^^ from here.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about genassym, locore.s and 0-sized arrays(showstopper for an icc compiled kernel)
On Fri, 5 Sep 2003 09:55:57 -0700
Marcel Moolenaar <[EMAIL PROTECTED]> wrote:
> Interesting, What does icc do with:
>
> struct {
> int tag;
> char obj[];
> } foo;
>
> And what does the sizeof() operator give.
---snip---
%
struct {
int tag;
char obj[];
} foo;
int main(void) {
struct foo bar;
printf("%d\n", sizeof(struct foo));
printf("%d\n", sizeof(bar));
return 0;
}
% icc marcel.c
marcel.c(9): error: incomplete type is not allowed
struct foo bar;
^
marcel.c(11): warning #70: incomplete type is not allowed
printf("%d\n", sizeof(struct foo));
^
compilation aborted for marcel.c (code 2)
%
struct {
int tag;
char obj[];
} foo;
int main(void) {
printf("%d\n", sizeof(struct foo));
return 0;
}
% icc marcel.c
marcel.c(9): warning #70: incomplete type is not allowed
printf("%d\n", sizeof(struct foo));
^
% ./a.out
0
---snip---
Bye,
Alexander.
--
Loose bits sink chips.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about genassym, locore.s and 0-sized arrays(showstopper for an icc compiled kernel)
On Fri, Sep 05, 2003 at 10:55:07AM +0200, Alexander Leidinger wrote:
> >
> > It does, according to my reading of it. They may have an issue with
> > dead code removal or element aliasing. The way to find out would be
> > to see what they emit for "[]"... 0 lenth, or 1?
>
> % char array[];
>
> % nm icc.o
> 0001 C array
Interesting, What does icc do with:
struct {
int tag;
char obj[];
} foo;
And what does the sizeof() operator give.
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about genassym, locore.s and 0-sized arrays(showstopper for an icc compiled kernel)
On Fri, Sep 05, 2003 at 07:34:39PM +1000, Bruce Evans wrote: > On Fri, 5 Sep 2003, I wrote: > > > ... > > If some values are unrepresentable then they need to be represtended > > using other values. E.g., add 1 to avoid 0, or multiply by the alignment > > size if some element of the tool chanin instsists on rounding up things >chain insists > > for alignment like a broken aout version used to do. 16-bit values > > would need 17 bits to represent after adding 1. > > Better, add 0x1 to avoid 0. awk has no support for parsing hex numbers > so subtracting the bias of 1 would take a lot more code, but ignoring > leading hexdigits requires no changes in genassym.sh -- it already ignores > everything except the last 4 hexdigits. > This works, too. Thanks for the detailed explanation Bruce! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)
On Thu, Sep 04, 2003 at 11:28:58AM -0500, Dan Nelson wrote: > In the last episode (Sep 04), Alexander Leidinger said: > > - If we depend on it: how hard would it be to rewrite it to not depend > >on 0-sized arrays (and does someone volunteer to rewrite it)? It > >would be nice if someone could point me to the source if it isn't > >an easy task, my contact @Intel is willing to convince the > >developers to change icc, but he has to "present a persuasive > >argument to development to pursue a solution". > > If you're talking FreeBSD 5, you should be able to simply subsitute a > C99 "flexible array member" (basically replace "[0]" with "[]") and get > the same effect. 0-length arrays are a gcc extension: But even with flexible array members you cannot create an object with size 0. The struct must have at least one additional member and you cannot use sizeof on the flexible array member itself as its type is incomplete. Cheers, Stefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about genassym, locore.s and 0-sized arrays(showstopper for an icc compiled kernel)
On Fri, 05 Sep 2003 01:38:29 -0700 Terry Lambert <[EMAIL PROTECTED]> wrote: > Dan Nelson wrote: > > I guess the correct question to be asking is "does the ELF format allow > > 0-length symbols?" > > It does, according to my reading of it. They may have an issue with > dead code removal or element aliasing. The way to find out would be > to see what they emit for "[]"... 0 lenth, or 1? % http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about genassym, locore.s and 0-sized arrays(showstopper for an icc compiled kernel)
On Thu, 4 Sep 2003, Marcel Moolenaar wrote: > On Fri, Sep 05, 2003 at 02:59:22AM +0200, Marius Strobl wrote: > > > > > > We use the size of the symbol (ie the size of the object identified > > > by the symbol) to pass around values. This we do by creating arrays. > > > If we want to export a C constant 'FOOBAR' to assembly and the constant > > > is defined to be 6, then we create an array for the sign, of which the > > > size is 1 for negative numbers and 0 otherwise. In this case the array > > > will be named FOOBARsign and its size is 0. We also create 4 arrays (*w0, > > > *w1, *w2 and *w3), each with a maximum of 64K and corresponding to the > > > 4 16-bit words that constitutes a single 64-bit entity. > > > In this case > > > 0006 C FOOBARw0 > > > C FOOBARw1 > > > C FOOBARw2 > > > C FOOBARw3 > > > > > > If the compiler creates arrays of size 1 for arrays we define as a > > > zero-sized array, you get exactly what you've observed. > > > > Is this rather complex approach really necessary? > > In theory, yes. In practice, maybe not. If I remember correctly, > the problem we're trying to solve is twofold: More like fourfold: -1: A cross-compiler must be used for the first stage. The old method of printf()'ing the results of sizeof(), etc., only works if the host machine is the same as the target machine, since sizeof() must be evaluated by a compiler for target machine and printf() can only be run on host machines. 0: Compiler output is to unportable to parse easily, so arrange to use a small portable subset of it after passing it through some standard filters. nm output was the most portable binutils-related output that I could think of. > 1. 64-bit constants given the limitations of the object format, > which included widths of 32-bit and a.out. After choosing to use nm output, there are some minor problems representing all relevant numbers using it. Numbers larger than 2^32 need to be represented but cannot be represented directly as symbol values or sizes in nm output on 32-bit machines. Numbers nearly as large as 2^32 can be represented as absolute symbols, but there is no way to generate absolute symbols in semi-portable C AFAIK. asm() statements might work but would be very unportable (apart from not being standard C, different ones might be needed for the aout and elf cases). The technique of using array sizes for all numbers works for most sizes, but the compiler might object to creating arrays almost as large as the address space, and as we have just found, to creating arrays of size 0. > 2. Sign extension or datatype limitations in awk(1)? I'm not > sure about this point. Bruce? Yes: one-true-awk uses "typedef double Awkfloat;", and gawk uses something similar by default IIRC, so awk can't hanele numbers larger than 2^53 without losing precision. "typedef long double Awkfloat;", would be no better because of my restriction of the precision of long doubles on i386's and (when genassym.sh was written) the incomplete library support for long doubles, and the nonexisted support for more than 53 bits of precision on some supported (?) hardware. Long doubles with 64 bits of precision wouldn't work for representing 128-bit integers anyway. > > ... The genassym.sh(8) of NetBSD kind > > of directly exports the C-constants so it just needs one symbol per > > constant and doesn't require zero sized arrays. Given that it's from > > NetBSD their approach also should be very MI. > > I wouldn't have a problem using NetBSD's genassym implementation, > provided we understand completely how it differs from ours and to > what extend and how it affects us and provided of course we can > live with whatever it is that's worse of just different from what > we have now. The main differences seem to be that it parses the assembler output. This is less portable and not as easy -- it takes about 5 times as much code. If some values are unrepresentable then they need to be represtended using other values. E.g., add 1 to avoid 0, or multiply by the alignment size if some element of the tool chanin instsists on rounding up things for alignment like a broken aout version used to do. 16-bit values would need 17 bits to represent after adding 1. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)
On Thu, 4 Sep 2003 15:57:31 -0700 Marcel Moolenaar <[EMAIL PROTECTED]> wrote: > On Thu, Sep 04, 2003 at 05:51:23PM -0500, Dan Nelson wrote: > > > > I guess the correct question to be asking is "does the ELF format allow > > 0-length symbols?" > > Of course. What size do you think a label should have otherwise? After mentioning the difference between gcc and icc I've got this response: ---snip--- Regarding the zero size array issue: Objects with zero size are incomplete objects and cannot be used in any meaningful way. Zero length arrays are explicitly prohibited by the Standard. We allowed zero length arrays as a feature request. We set their size to one so operations involving them can make some kind of sense. ---snip--- Can you please give me "something" a compiler developer should understand (an URL, a reference into some standard, a description, ...)? As long as we can provide strong evidence that gcc doesn't do the wrong thing Intel will change icc to be compatible with gcc. Bye, Alexander. -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)
< said: > In theory, yes. In practice, maybe not. If I remember correctly, > the problem we're trying to solve is twofold: Actually, the problem we were trying to solve is simpler than that. genassym needs to be able to compute the values of certain constants from header files which are only accessible to kernel code. At the same time, it needs to be able to run as a user process. One compilation unit cannot include both Standard headers like and kernel-specific headers like . In fact, we muck with the include path to ensure that Standard headers cannot be included while compiling kernel source. Cross-compilation does engender other issues, but that wasn't the original motivation. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)
On Fri, Sep 05, 2003 at 02:59:22AM +0200, Marius Strobl wrote: > > > > We use the size of the symbol (ie the size of the object identified > > by the symbol) to pass around values. This we do by creating arrays. > > If we want to export a C constant 'FOOBAR' to assembly and the constant > > is defined to be 6, then we create an array for the sign, of which the > > size is 1 for negative numbers and 0 otherwise. In this case the array > > will be named FOOBARsign and its size is 0. We also create 4 arrays (*w0, > > *w1, *w2 and *w3), each with a maximum of 64K and corresponding to the > > 4 16-bit words that constitutes a single 64-bit entity. > > In this case > > 0006 C FOOBARw0 > > C FOOBARw1 > > C FOOBARw2 > > C FOOBARw3 > > > > If the compiler creates arrays of size 1 for arrays we define as a > > zero-sized array, you get exactly what you've observed. > > Is this rather complex approach really necessary? In theory, yes. In practice, maybe not. If I remember correctly, the problem we're trying to solve is twofold: 1. 64-bit constants given the limitations of the object format, which included widths of 32-bit and a.out. 2. Sign extension or datatype limitations in awk(1)? I'm not sure about this point. Bruce? > ... The genassym.sh(8) of NetBSD kind > of directly exports the C-constants so it just needs one symbol per > constant and doesn't require zero sized arrays. Given that it's from > NetBSD their approach also should be very MI. I wouldn't have a problem using NetBSD's genassym implementation, provided we understand completely how it differs from ours and to what extend and how it affects us and provided of course we can live with whatever it is that's worse of just different from what we have now. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)
On Thu, Sep 04, 2003 at 03:47:09PM -0700, Marcel Moolenaar wrote: > > We use the size of the symbol (ie the size of the object identified > by the symbol) to pass around values. This we do by creating arrays. > If we want to export a C constant 'FOOBAR' to assembly and the constant > is defined to be 6, then we create an array for the sign, of which the > size is 1 for negative numbers and 0 otherwise. In this case the array > will be named FOOBARsign and its size is 0. We also create 4 arrays (*w0, > *w1, *w2 and *w3), each with a maximum of 64K and corresponding to the > 4 16-bit words that constitutes a single 64-bit entity. > In this case > 0006 C FOOBARw0 > C FOOBARw1 > C FOOBARw2 > C FOOBARw3 > > If the compiler creates arrays of size 1 for arrays we define as a > zero-sized array, you get exactly what you've observed. > Is this rather complex approach really necessary? I have successfully generated assyms.s' using genassym.sh(8) from NetBSD and both ICC and GCC on i386 which have exactly the same values as one generated with sys/kern/genassym.sh from FreeBSD. The genassym.sh(8) of NetBSD kind of directly exports the C-constants so it just needs one symbol per constant and doesn't require zero sized arrays. Given that it's from NetBSD their approach also should be very MI. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)
On Thu, Sep 04, 2003 at 05:51:23PM -0500, Dan Nelson wrote: > > I guess the correct question to be asking is "does the ELF format allow > 0-length symbols?" Of course. What size do you think a label should have otherwise? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)
In the last episode (Sep 05), Alexander Leidinger said: > On Thu, 4 Sep 2003 11:28:58 -0500 > Dan Nelson <[EMAIL PROTECTED]> wrote: > > If you're talking FreeBSD 5, you should be able to simply subsitute > > a C99 "flexible array member" (basically replace "[0]" with "[]") > > and get the same effect. 0-length arrays are a gcc extension: > > > > http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html > > > > Under FreeBSD 4.x, you can't use them because gcc 2.95 only > > supports the gcc extension. Intel has added support for a lot of > > gcc extensions recently; they may be willing to add this to the > > list. > > Please read my mail again, icc already supports my_array[0], but the > resulting array in the binary has size '1'. The actual showstopper is > the output of genassym.sh. To me it seems it's just a genassym.sh > issue, but I don't really know what's going on in the kernel, so I > ask here. Ok, I reread the original message, and it's still a zero-length array problem, but in a different place. What it looks like to me is that icc silently converts zero-length arrays to 1 element when creating the assembly output. While it's processing C source, sizeof(my_array) returns 0, but the emitted assembly says otherwise: $ cat > test.c int test0[0]; int test1[1]; int test2[2]; ^D $ gcc -c test.c -S -o test.gcc $ icc -c test.c -S -o test.icc $ grep comm test.?cc test.gcc: .comm test0,0,4 test.gcc: .comm test1,4,4 test.gcc: .comm test2,8,4 test.icc: .comm test2,8,4 test.icc: .comm test1,4,4 test.icc: .comm test0,4,4 So gcc emitted symbols with the same size as in the source file, with an alignment of 4 bytes (since I'm using ints in this example), but icc adjusted the test0 symbol to be one int long. I used ints to make it more obvious what icc is doing; the effect is the same if you use chars. I guess the correct question to be asking is "does the ELF format allow 0-length symbols?" If not, then gcc is generating invalid objects, and genassym will have to be rewritten to not use them (maybe add one to the array size, and have genassym.sh subtract it). If it does, then genassym.c (sys/assym.h actually) is legal code. If Intel doesn't want to change icc, we can still work around it, but there may be other code that will break on icc just like assym.h. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)
On Fri, Sep 05, 2003 at 12:14:11AM +0200, Alexander Leidinger wrote: > On Thu, 4 Sep 2003 11:28:58 -0500 > Dan Nelson <[EMAIL PROTECTED]> wrote: > > > If you're talking FreeBSD 5, you should be able to simply subsitute a > > C99 "flexible array member" (basically replace "[0]" with "[]") and get > > the same effect. 0-length arrays are a gcc extension: > > > > http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html > > > > Under FreeBSD 4.x, you can't use them because gcc 2.95 only supports > > the gcc extension. Intel has added support for a lot of gcc extensions > > recently; they may be willing to add this to the list. > > Please read my mail again, icc already supports my_array[0], but the > resulting array in the binary has size '1'. The actual showstopper is > the output of genassym.sh. To me it seems it's just a genassym.sh issue, > but I don't really know what's going on in the kernel, so I ask here. We use the size of the symbol (ie the size of the object identified by the symbol) to pass around values. This we do by creating arrays. If we want to export a C constant 'FOOBAR' to assembly and the constant is defined to be 6, then we create an array for the sign, of which the size is 1 for negative numbers and 0 otherwise. In this case the array will be named FOOBARsign and its size is 0. We also create 4 arrays (*w0, *w1, *w2 and *w3), each with a maximum of 64K and corresponding to the 4 16-bit words that constitutes a single 64-bit entity. In this case 0006 C FOOBARw0 C FOOBARw1 C FOOBARw2 C FOOBARw3 If the compiler creates arrays of size 1 for arrays we define as a zero-sized array, you get exactly what you've observed. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)
On Thu, 4 Sep 2003 11:28:58 -0500 Dan Nelson <[EMAIL PROTECTED]> wrote: > If you're talking FreeBSD 5, you should be able to simply subsitute a > C99 "flexible array member" (basically replace "[0]" with "[]") and get > the same effect. 0-length arrays are a gcc extension: > > http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html > > Under FreeBSD 4.x, you can't use them because gcc 2.95 only supports > the gcc extension. Intel has added support for a lot of gcc extensions > recently; they may be willing to add this to the list. Please read my mail again, icc already supports my_array[0], but the resulting array in the binary has size '1'. The actual showstopper is the output of genassym.sh. To me it seems it's just a genassym.sh issue, but I don't really know what's going on in the kernel, so I ask here. Bye, Alexander. -- Weird enough for government work. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)
In the last episode (Sep 04), Alexander Leidinger said: > At the moment I discussing an issue with Intel regarding 0-sized > arrays. gcc seems to be violating the standard and produces code with > an array size of "0", whereas icc produces code where an 0-sized > array has the size "1". This results in different nm output of > genassym.o: [snip] > - If we depend on it: how hard would it be to rewrite it to not depend >on 0-sized arrays (and does someone volunteer to rewrite it)? It >would be nice if someone could point me to the source if it isn't >an easy task, my contact @Intel is willing to convince the >developers to change icc, but he has to "present a persuasive >argument to development to pursue a solution". If you're talking FreeBSD 5, you should be able to simply subsitute a C99 "flexible array member" (basically replace "[0]" with "[]") and get the same effect. 0-length arrays are a gcc extension: http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html Under FreeBSD 4.x, you can't use them because gcc 2.95 only supports the gcc extension. Intel has added support for a lot of gcc extensions recently; they may be willing to add this to the list. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
