[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rpm-devel
Subject:    Re: Why is AutoFu testing --std-gnu99 ?!?
From:       Jeff Johnson <n3npq () mac ! com>
Date:       2009-03-23 17:26:11
Message-ID: 7A5A5F7A-FCE2-4CC7-8AD2-A31FBDE184B1 () mac ! com
[Download RAW message or body]


On Mar 23, 2009, at 1:11 PM, Anders F Björklund wrote:

> Jeff Johnson wrote:
>
>>>
>>> I believe this is because xz's configure.ac uses AC_PROG_CC_C99 ?
>>>
>>
>> Is XZ the only issue? Splint (which is non-C) is routinely
>> finding C declarations in-line outside of XZ, all of which are full- 
>> stop
>> parser failures for C99.
>>
>> And perl was being built with --std=gnu99 ...
>
> Well, those lines you quoted seemed to be from it at least.
> As in: I only looked at the autofoo and not at the C code.
>

I'm pretty sure (I'm positive but I've fooled myself before, recheck++)
that perl is being built with --std-gnu99.

Again and again and again, I ain't averse to C99, only creeping crud ...

>> Again and again, I'm not at all averse to switching to C99.
>> Its the creeping crude which I have to clean up, and the
>> code conversions from C99 to non-C99 to conform, that
>> are a huge time waste for me.
>
> Maybe we need some easy toggle to build it all with -std=c89,
> so that these can be found earlier on ? (like in devtool.conf)
>

Good idea ...

(aside)
What makes C99 an issue atm is that I need to see /*@abstract@*/
and /*@killref@*/ annotations using splint to efficiently
rearrange RPM code. I plain and simply cannot keep all these
code paths in my HEAD, which is why I started using splint
years ago.

FWIW, the benefits of /*@abstract@*/ and /*@killref@*/ are
just starting to be realized. If I hadn't vetted RPM
routinely with splint, then refactoring would not
be feasible, the code would have long since
wandered all over the place ...

>>> But I also believe that it was converted back to standard C now,
>>> so that part could be changed to the normal AC_PROG_CC again...
>>
>> Yes, I've converted XZ back to non-C99 3 times now. Its not hard,
>> just tedious.
>
> Tedious but necessary for internalizing into RPM, I suppose.
> (then again, it could have been written in C++ or something)
>

The "object model" with constructors/destructors that I'm
currently implementing to attach posix mutexes to rpm objects
is straight from OO afaik of which C++ is one implementation.

So I'm not averse to C++ either if planned and methodically
implemented. Its the creeping crud that eats huge amounts of
my time ...

73 de Jeff
> --anders
>
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org

______________________________________________________________________
RPM Package Manager                                    http://rpm5.org
Developer Communication List                        rpm-devel@rpm5.org

[prev in list] [next in list] [prev in thread] [next in thread]