Subject: Re: Global variable name which equals to func name causes coredump(gcc).
To: None <firstname.lastname@example.org>
From: =?GB2312?B?seXJ3MDX?= <email@example.com>
Date: 09/27/2007 20:37:38
2007/9/27, Pelle Johansson <firstname.lastname@example.org>:
> 27 sep 2007 kl. 13.49 skrev Greg Troxel:
> > Obviously fread called the wrong func address of read.
> > To answer if this is a bug, I think you'll need to read the C standard
> > very carefully. read(2) is not part of C; man 2 read says it's in
> > POSIX.1.
> > But fread is part of C89.
> Which indicates that it is indeed a bug, and probably one not that
> difficult to fix, by having fread call some alias of read instead. Of
> course, it gets more complicated when the same has to be done for all
> possible conflicts.
> The second example is not as clearly a bug. I would argue that you're
> simply not allowed to have a local symbol called mlock if you want to
> use the pthread library. I don't know what POSIX says on the issue
> specifically though.
> Pelle Johansson
In fact the 2nd example is from unp v1 3e source: pthread07.h. I found
it simple enough to regenerate the problem. I met it when I made and
ran serv07 in the source directory unpv13e/server.
Now I think it is a very terrible problem: I can't have any global
varible whose name is the same with those in libraries. For example,
__srefill, __sread called by fread, or thounds of any other function
names in any libraries that I needed.
I will check why FreeBSD, OpenBSD and Mingw + gcc don't have the same
problem, and check what the c99 standard says.