Re: Pretty please: no more lower-case macros !!!

[Adrian Bocaniciu <a.bocaniciu@xxxxxxxxxxxx>]

Simon 'corecode' Schubert wrote:
> I think you are mistaking something here. Macros are traditionally written 
> upper case if they evaluate their arguments more than one time, iirc.

	No, the convention had nothing to do with macro arguments.  However, 
there exists a very large number of exceptions, which are documented in 
the standards for the C language libraries and for the UNIX libraries. 
Nevertheless, these have always been exceptions, where macros have been 
used because no better tools existed.


> If you want to be portable, #define POSIX_SOURCE or what it is called and 
> don't include sys/* files. These lower case macros are usually for

	I do not refer to new code, but to the huge number of existing *BSD 
ports.  Most of these ports *MUST* include sys/*, net/* etc. headers, as 
there is no other way to accomplish their functions.


> For example <netdb.h>:
> as you can see, it's an often used compatibility define. and those are usually 

	Like I have said, in the standard headers there are lot of well 
documented lower-case macros.  Nevertheless, most of these have been 
introduced at least 10 to 20 years ago, when they did not have to be 
very concerned about breaking the existing code.

	Now, in 2005, the situation is different for DragonFly, there will 
never be enough developers to rewrite all the thousands of existing 
open-source applications.  Because of that, great care must be taken not 
to do things that will conflict with the existing ports.

	When you replace the legacy functions and data types from an old API, 
this normally does not produce significant compatibility problems, 
because it is always possible to also maintain some wrapper functions 
that will keep happy the old applications, which will not care that a 
new API has been added, while the new applications will take advantage 
of the new improved API.

	However, when you put a new macro that could conflict with local 
identifiers in a standard header, you no longer have any control and you 
cannot predict what will happen when various *BSD ports will be recompiled.


> I'm not sure if this will always work. Could you give an example which will 
> compile with gcc2 and gcc34 without warnings?

I have tried in DragonFly a test program that defined the type

typedef struct {
	union {
		int i_array[3];
		struct {int i1, i2, i3;};
	};
} s_type;

Then it declared a variable of this type
s_type x;

Then it wrote and read its components either as x.i1, x.i2, x.i3 or as 
x.i_array[0], x.i_array[1] and x.i_array[2].

With "CCVER=gcc34 cc -Wall test.c", the program is compiled without any 
warnings and it runs OK.

But with CCVER=gcc2, the compilation fails :-(

Sorry, I guess that a lot of years have passed since I have last used a 
gcc 2.x.  Nevertheless, new lower-case macros are not an acceptable 
solution, even if the conversion to gcc34 will be still delayed.

Actually, it is not clear for me which are the problems with gcc 3, as 
on Linux I have compiled in the recent years with gcc 3 and without 
noticing any problems or later run-time errors a much larger number of 
source packages, including all the huge ones like X, KDE, OpenOffice or 
Mozilla (and I use aggresive optimization options, except for the strict 
aliasing which breaks many old applications).  FreeBSD 5.3 also has gcc 
3.4 as its default compiler, so any problems with it can be solved.

	Best regards !