Re: ANSI requirement

On Sat, 12 Jun 2010, Dominic Dunlop wrote:

> 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).

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