Re: [Mingw-users] glibc searching and sorting

[Greg C. <chi...@co...>]

On 2007-06-16 02:06Z, Keith Marshall wrote:
> On Friday 15 June 2007 20:19, Danny Smith wrote:
    [Keith had asked:]
>>> But why uglify the names?  
>> Because some people want ANSI standard.  
> 
> And we satisfy that by providing the core set of functions, each 
> behaving *exactly* as specified, as required by whichever version of 
> the ANSI Standard for which we wish to claim conformance.  That alone 
> is a necessary and sufficient condition of conformance. If we choose
> to provide additional functions, however we choose to name them, they 
> have no bearing whatsoever on ANSI conformance.

Suppose they were guarded with __STRICT_ANSI__ instead?
Would that meet everyone's goals here?

Consider:

C:/tmp[0]$cat m_e.c
#include <math.h>
int M_E(int x) { return x; }
int main() { M_E(0); return 0; }
C:/tmp[0]$/MinGW-20061119/bin/gcc -ansi m_e.c
C:/tmp[0]$/MinGW-20061119/bin/gcc m_e.c
m_e.c:3: error: syntax error before numeric constant
m_e.c: In function `main':
m_e.c:5: error: called object is not a function

I think that's a "strictly conforming program" (C99 [4.5]),
which every "conforming hosted implementation" (C99 [4.6])
must accept.

And 'gcc -ansi' should be a "conforming hosted implementation",
as in the first compile command above. But 'gcc' without '-ansi'
needn't be, as in the second compile command.

Either guarding with __STRICT_ANSI__ or uglification with a
leading '_[_A-Z]' would preserve conformance, AIUI. Also, BTW,
AIUI, that kind of uglification isn't specific to one monopoly;
it's just a consequence of [7.1.3/1] and [4.6] footnote 3.
That footnote seems to be the crux of this matter.

In the M_E case above, somebody, probably a decade ago, just
happened to choose the __STRICT_ANSI__ method, but both
ways have advantages.

__STRICT_ANSI__ lets people call twalk() by its POSIX name.
Or use M_E by its X/Open name.

Uglification prevents polluting the namespace if whatever
header POSIX puts it in is included, but people define their
own function called twalk() that doesn't do what the POSIX
one does. I could have defined rwalk(), swalk()... without
knowing about POSIX. Once, I tried defining an enumeration
with the standard postal abbreviations of US states as
enumerators:
  enum us_states
    {AK // Alaska
...
    ,OK // Oklahoma
...
but some nonconforming implementation (not gcc) had defined
a non-uglified OK macro.