X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Wed, 21 Sep 2016 14:14:41 +0200 (CEST)
From: Roland Lutz <rlutz AT hedmen DOT org>
To: "dmn (graahnul DOT grom AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject: Re: [geda-user] Default gnetlist frontend changed
In-Reply-To: <CAAKZVJ=XtoyEZD7+x_9hxN5Sm0qLZNwKGe9TwdgZLH6XM-9nhA@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1609211347330.1597@nimbus>
References: <alpine DOT DEB DOT 2 DOT 11 DOT 1609192251560 DOT 30591 AT nimbus> <CAAKZVJk5eK+Jpo1vZ1-8rZGOKV239TAiTan3ysPVthf=b07cRw AT mail DOT gmail DOT com> <alpine DOT DEB DOT 2 DOT 11 DOT 1609201310470 DOT 17116 AT nimbus> <CAAKZVJ=XtoyEZD7+x_9hxN5Sm0qLZNwKGe9TwdgZLH6XM-9nhA AT mail DOT gmail DOT com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Tue, 20 Sep 2016, dmn (graahnul DOT grom AT gmail DOT com) [via 
geda-user AT delorie DOT com] wrote:
>>> - non-portable C++ code in key_iterator.h
>> It's in C++98, so how can it not be portable?
>
> Consider, for example, your operator == ():
>
>    bool operator == ( key_iterator x )
>    {
>        return i.operator == ( x.i );
>    }
>
> Here, i and x.i are bidirectional (and hence - forward) iterators.
> ISO C++ states ("forward iterator requirements") that if
> a and b are forward iterator objects, they must support
> expression a == b and the result of such expression must
> be convertible to bool. That's all.
> Standard does not tell compiler's developer how to
> implement it. operator == () can be either class member
> function or not. But you assumes that it IS a class member,
> thus relying on implementation details.

Thank you for this detailed explanation.  After looking at the code again, 
I don't see a reason why I would have used the operator notation in the 
first place, so I think it's safe to just remove it as you did.  Is there 
a reason why you didn't replace the notation in the last function, as well?

Would you be ok with including this rationale in the commit message of 
your patch?

>> The intention is that Xorn shouldn't depend on GNU sed; if it does, that's
>> a bug.  What problems did you encounter with non-GNU sed?
>
> xorn depends on GNU sed to be built. Otherwise, compilation stops in 
> xorn/po/ with 100+ gettext error messages. I can send you the output, if 
> necessary.

I believe this is an error in GNU gettext.  As a test, you could try 
building GNU Hello on you system--if this fails, too, it's not a bug in 
Xorn.  As a simple fix, I have removed the generated locales `en AT quot' and 
`en AT boldquot'.

>> The other obvious way to implement this would be to redirect the 
>> standard output, and let the backend output there.  I tried to avoid 
>> this as it may cause some messages printed to stdout to be included in 
>> the output, but maybe it's the better option considering portability.
>
> Sorry, but I have no idea what you are trying to implement.
> Could you explain, please?

The backend expects a file name as an argument, but the temporary output 
file has already been opened at this point in time.  There are two ways to 
address this: passing the backend a /dev/fd filename, or instructing it to 
output the netlist on the standard output and using dup2(2) to redirect 
this to the existing file descriptor.


I have assembled a series of five patches which should resolve all of the 
portability issues you reported, including the dependence on GNU sed:

     http://hedmen.org/xorn/freebsd-patches.tar.bz2

Could you please test them so I can commit them to master?  In addition, 
Don Kuenz reported an error in xorn/src/cpython/Makefile.am; the variable 
`$^' apparently doesn't work on FreeBSD.  Did you encounter this, too?