This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Prevent macro expansion of mblen


On Fri, Dec 29, 2000 at 01:18:52AM -0200, Alexandre Oliva wrote:
> On Dec 28, 2000, Gabriel Dos Reis <gdr@codesourcery.com> wrote:
> > We want all C-functions, whether there are shadowed (i.e. brought in
> > scope through <cxxx> or <xxx.h> headers) have C linkage  -- this
> > ensures that those names ultimately refer to the same entities --
> 
> Will you please explain again what your plan is to accomplish this in
> case the C library offers a standard function as both a preprocessor
> macro and a function with C linkage in the global namespace, and in
> case it is only offered as a preprocessor macro?

It is not allowed in C89 for the C library to offer mblen "only ...
as a preprocessor macro".  C89 allows it to be offered as both a
global symbol *and* a masking macro.  If any target system lacks the
global symbol, it's a bug, and any arrangement to accommodate the bug 
is a target-specific workaround.

ISO 14882 requires that the C library symbols not be provided as
macros to C++ programs, except in a few cases where they _must_
be macros (e.g. errno).  Where they are not macros, the object
named (e.g.) ::mblen when you #include <string.h> and the object 
named std::mblen when you include <cstring> must actually be the 
same object, as far as the program can tell; i.e. 
&::mblen == &std::mblen. 

HTH
Nathan Myers
ncm at cantrip dot org

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]