Re: ANSI requirement

On 2010–06–11, at 20:56, Aaron Crane wrote:

>  struct foo {
>      size_t len;
>      unsigned char buf[1];
>  } *foo;
> 
> The intention of such structures is that `foo->buf` is a
> variable-length array; the whole thing is allocated with malloc or
> similar, with a calculated size that is the sum of `sizeof(struct
> foo)` and the desired length of the array.  The alternatives in C89
> all involve overhead in either space or speed (or both).
> 
> A quick grep suggests that we have such constructs in hv.h (twice),
> os2/os2ish.h (several times), and regcomp.h (several times).
> 
> Programs containing this construct are *not* considered to be
> strictly-conforming ANSI/ISO C; Dennis Ritchie has allegedly referred
> to the technique as "unwarranted chumminess with the C implementation"
> (and a variant of that phrase crops up in a comment on one of the
> occurrences in regcomp.h).  However, I'm not aware of anyone ever
> pointing to a widely used compiler which handles such code other than
> intended, or why (modulo perhaps strict-me-harder run-time bounds
> checking) anyone would build such a compiler for any machine with a
> half-way sane memory model).  And given the popularity of the
> technique (Perl is by no means the only large application to do it),
> that seems likely to remain true indefinitely.

Ah. This may be why clang refuses to build gv.c and dump.c -- although only when debugging is enabled. See my post <http://nntp.perl.org/group/perl.perl5.porters/159865>. I filed it as a (currently unassigned) clang bug: <http://llvm.org/bugs/show_bug.cgi?id=7008>. But maybe the real problem is that clang is adhering to the letter of the C89 law.

George Greer fixed the issue in the time-honoured way (casting) in <http://nntp.perl.org/group/perl.perl5.porters/160510>, although he saw the problem in different source files than I did; this _could_ be down to his use of a different clang version.

All is still not well with clang for me, however -- see, for example <http://www.nntp.perl.org/group/perl.daily-build.reports/2010/06/msg82333.html>. This turns out to be due to a llvm code generation error:

Making all in ext/DynaLoader
 make all PERL_CORE=1 LIBPERL_A=libperl.a LINKTYPE=static CCCDLFLAGS=
clang -o perl  -flto -fstack-protector -L/usr/local/lib -L/opt/local/lib  perlmain.o  libperl.a `cat ext.libs` -ldl -lm -lutil -lc 
clang: warning: argument unused during compilation: '-flto'
clang: warning: argument unused during compilation: '-fstack-protector'
lto-llvm.s:1093619:FATAL:Symbol Linfo_begin44 already defined.
ld: could not do LTO codegen: error in assembly
make: *** [perl] Error 1

Again, only the -DDEBUGGING builds are affected. Probably time I opened another ticket with clang (and honed the previous one).
-- 
Dominic Dunlop