Front page | perl.perl5.porters |
Postings from June 2010
Re: ANSI requirement
Thread Previous
|
Thread Next
From:
Dominic Dunlop
Date:
June 12, 2010 07:33
Subject:
Re: ANSI requirement
Message ID:
9A4E3A92-0757-4BE4-BE14-142EBAFF7260@computer.org
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
Thread Previous
|
Thread Next