Re: Ping K.Haley: latest testing branch updates, I get compiler error in post-ui.cc line 742: ‘_c lose’ not declared.

Hi,

On Mon, 18 Oct 2010 18:09:33 -0600, "K. Haley" wrote:
> On 10/17/2010 9:21 AM, walt wrote:
>> On 10/17/2010 03:48 AM, SciFi wrote:
>>
>>> Now I am getting a compiler error:
>>>> post-ui.cc: In member function ‘void pan::PostUI::spawn_editor()’:
>>>> post-ui.cc:742: error: ‘_close’ was not declared in this scope
>> Here are the two relevant added lines from K.Haley's patch:
>>
>> +#include <unistd.h>
>> +      _close(fd);
>>
>> Grepping through unistd.h, I find the function 'close(fd)' but not
>> '_close(fd)', so I'm assuming for the moment that the underscore is
>> a typo.
> It's not a typo.  Non-standard names like close are supposed to have an
> _ prefix.  My headers have both versions  I changed it when I was
> testing with the --std=c++0x option which disables such names.

I do not know what “--std=c++0x” actually means (the 0x part).

Someone might be asking:  “What is the fuss with ‘_’ symbols?”
Here is how I understand it:

The ‘_’ prefix usually denotes such symbols are found in the /object/
code, not the /source/ code, of most libraries, and are (made to be)
resolved at /link/ time, and I’ve seen this a lot across different
projects, and which works here AFAICT.

When the /source/ calls for such a ‘_’–prefixed symbol, there ought to
be a header that defines it, and is what’s wrong here it seems on
some *ix platforms and others.

Also, some projects (e.g. ffmpeg, mplayer) treat a ‘_’–prefixed symbol
as part of the (GNU?) private symbols, which they abstain from using.

But even at that, the /object/ code creates yet another ‘_’ added in
front of the declared one, resulting in a doubled ‘__foo’–type symbol
at /link/ time, again which works here when it’s intended that way.

I just happened to know ‘close(fp)’ matches the man–page, and that it
should work by removing the leading ‘_’, as I indicated on my little
note at the github site.
I am running Pan now with this modification.

> By the way, is the xface handling correct?  I can't tell if the colors
> are inverted.

All I can say is that a scant few people use this on the “worldwide”
Usenet system (Giganews, Astraweb, etc), and I was pleasantly surprised
to see a “colored” rendition on the From/To/etc message–bar.  ;D
However, I do not know if the colors are accurate.
We probably need someone to whip-up a set of tests.  ;)

At any rate, thank you very much for continuing work on Pan.

[I do still have some big problems that I’ve mentioned over the years
on this list, mainly to do with “No Multi-threading” being done in key
areas, that Mr.Kerr might not want to tackle, since it reminds him of
the earlier version–0.xx.xx days <lol>]

:)