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:
| 
| > 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:
| 
| That's because I was under the impression you had mis-understood the
| problem,

The only sensible problem we've been faced is that of having a
function implemented both as a macro and a real function.  The
solution to that problem is to #undef the macro and introduce a
corresponding declaration for an external function with C linkage
declaration in namespace std.  Is that what you're questioning? If
yes, then I don't think I misunderstood the problem.

| ... and was suggesting a more complicated implementation because
| you thought the function was missing.  Looks like my impression was
| correct :-)
| 
| > As for your patch, std::mblen should name the same entity as ::mblen,
| > in addition of #undefing mblen.
| 
| I still fail to understand why they should be the same entity. 

Because the following has to evaluate to true:

	::mblen == std::mblen

And it is also the library requirement 17.4.1.2/7 which diretly refers
to Annexe D/2

  Each C header, whose name has the form name.h, behaves as if each
  name placed in the Standard library namespace by the corresponding
  cname header is also placed within the namespace scope of the
  namespace std and is followed by an explicit using-declaration
  (7.3.3). 

Am I still being dense?

| ... We'd
| lose the optimization opportunity that the header files of the system

Is optimization more important than correctness?
My opinion is: No.  But I can understand you may disagree.

| attempt to offer, and failing to work in case the name is only
| available as a macro (which is not the case at hand, but it might be
| on other systems).  

So, again you're pointing out an imaginary implementation which offers
only the macro name.  No comment.

| ... These two problems are absent with the
| implementation in my latest patch, as proposed by Ben.  
| 
| But, if you have a good argument against the patch I last proposed,
| here's one that does it as you suggest.  Ok to install?

Yes.

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