Mail Archives: geda-user/2016/09/21/08:17:56
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?
- Raw text -