Front page | perl.perl5.porters |
Postings from June 2010
Re: ANSI requirement
Thread Previous
|
Thread Next
From:
George Greer
Date:
June 12, 2010 11:53
Subject:
Re: ANSI requirement
Message ID:
alpine.LFD.2.00.1006121449080.2784@ein.m-l.org
On Sat, 12 Jun 2010, Dominic Dunlop wrote:
> On 20100611, 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).
It looks like you have -flto confusion since the warning says it didn't
use -flto but then it tried to do LTO anyway. I don't use that option at
all in my smoke runs.
clang version 1.1 (branches/release_27)
llvm version 2.7 ( 2.7-0ubuntu1)
Optimized build.
Built Apr 28 2010 (14:19:53).
Host: x86_64-pc-linux-gnu
Host CPU: corei7
--
George Greer
Thread Previous
|
Thread Next