Re: Pretty please: no more lower-case macros !!!
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 !
討論串 (同標題文章)
完整討論串 (本文為第 4 之 14 篇)：