Re: Prevent macro expansion of mblen

[Gabriel Dos Reis <gdr at codesourcery dot com>]

Alexandre Oliva <aoliva@redhat.com> writes:

| On Dec 31, 2000, Gabriel Dos Reis <gdr@codesourcery.com> wrote:
| 
| > Which doesn't exist either since the conditions are that we _don't_
| > have a mblen() function, but just a macro -- having just a macro is the
| > deficieny of target we're trying to solve.
| 
| I still don't know of any target that has a macro but not a function.
| The targets I've known about have a macro *and* a function, and I
| believe this implementation is in accord with the ISO C Standard;
| offering it just as a macro isn't (I think).
| 
| Unless you know of some implementation that offers it only as a macro,
| I don't see a reason to keep debating this issue.

Fair enough.  *You* are the person who first made the assumption, 
in http://gcc.gnu.org/ml/gcc-patches/2000-12/msg01333.html, that
an implementation might just the function only as a macro:

   > 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?
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Now, you're asking me to name such an implementation.
There is indeed no point in continuing this discussion.

As for your patch, std::mblen should name the same entity as ::mblen,
in addition of #undefing mblen.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com