svn commit: trunk/busybox/util-linux

[Bernhard Fischer]

On Fri, Sep 22, 2006 at 10:21:50AM +0200, Denis Vlasenko wrote:
>On Thursday 21 September 2006 20:43, Rob Landley wrote:
>> On Thursday 21 September 2006 2:53 am, Denis Vlasenko wrote:
>> > 	if (_IO_ferror_unlocked(stdio))  // cryptic error messags from gcc
>> > 		bad();
>> 
>> #defining something you're using as a ->member name is stupid, agreed.  
>> Especially when you're using that member name in another #define, and thus 
>> should know better.  However in that case, if I make a change to the source 
>> code and the build breaks, what change I just made to the source code is an 
>> important part of tracking down what I just broke.
>> 
>> I've encountered dozens of really strange cases where gcc produces horrible 
>> error messages.  One more doesn't phase me.  It's still doing better than 
>> Borland C did.
>> 
>> > enum would work here just fine.
>> 
>> *shrug*  My attitudes formed back when there were cases where #defines that 
>> became if(0) would optimize out and enums wouldn't, although that hasn't been 
>> the case in a longish time now.  But I still just don't see anything wrong 
>> with #defines in this instance.
>
>Well, I think we used up all our arguments,
>let's decide what the rules are.
>
>I won't go thru tree replacing existing #defines
>with enums, but will use enums in new code.
>
>If you want me using #defines even in new code,
>please let me know that. It's not a big problem for me.

As said, I'm used to defines but if enums are mandated, then it's
acceptable for me, fwiw. Not my call, though.

cheers,