DragonFly BSD
DragonFly bugs List (threaded) for 2005-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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


From: Adrian Bocaniciu <a.bocaniciu@xxxxxxxxxxxx>
Date: Thu, 06 Jan 2005 11:03:37 +0000

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 !



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]