[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: double underscores in autoconf-defined symbol names

From: Keith MARSHALL
Subject: Re: double underscores in autoconf-defined symbol names
Date: Tue, 10 Jan 2006 15:23:25 +0000

Thomas Dickey wrote:
> That may be true, but other platforms (including Linux) deal in ugly
> header file internals.  The reason for it with Microsoft is that the
> names beginning with underscores don't match the behavior of the 
> similarly-named POSIX names.

That may have been true, at one time.  In the days of MSC-6 on MS-DOS
it was pretty much universally true, but today Microsoft seem to have
gone overboard, prefixing underscores to almost everything, even when
the functionality for standard names and prefixed names is identical.

There are certainly instances where the Microsoft functionality does
differ from the POSIX norm, and in such cases the decoration of the
name with the underscore is appropriate; there are many other cases
where this is untrue -- the cynic in me would suggest that this is
a Microsoft conspiracy to maximise vendor lock-in, for if your code
is sprinkled with M$ "uglified" function names, the porting effort
is increased, when you want to support more standardised platforms.

Even where the M$ functionality *does* differ from the POSIX norm,
I would respectfully suggest that there are better ways to handle
the distinction than trying to discriminate between names with
and without leading underscores, e.g.

  #if defined(_WIN32) || defined(_MSC_VER)
  # define mkdir(p,m) _mkdir(p)

then just use the standard POSIX format throughout your code; for
those functions where there is no discernable change in functionality,
just use the POSIX form as a matter of course.

> ...and unlike Microsoft's headers, MinGW's are not designed to be 
> maintainable or readable - just random cut/paste excerpts from other 
> headers.

You are certainly entitled to this opinion, and I respect that, but I
would also respectfully beg to differ.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]