Re: [lmi] '--disable-apple_ieee'

[Vadim Zeitlin]

On Thu, 23 Jul 2020 21:35:42 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> It seems to be in 'lame':
GC> 
GC> 
http://lab.llvm.org:8080/artifacts/opt-view_test-suite/build/MultiSource/Benchmarks/MiBench/consumer-lame/CMakeFiles/consumer-lame.dir/html/_org_test-suite_MultiSource_Benchmarks_MiBench_consumer-lame_portableio.c.html
GC> 
GC> and in 'python', which blithely re-copyrights it:
GC> 
GC> 
https://ftp.nice.ch/pub/next/audio/converter/_GISO.3.3.s/GISO/Sox/_aiff.c.html
GC> 
GC> It's also here:
GC> 
GC> https://plan9.io/sources/plan9/sys/src/games/mp3enc/portableio.c
GC> 
GC> but relicensed there in a way incompatible with the GPL:
GC> 
GC> https://www.gnu.org/licenses/license-list.en.html#lucent102
GC> 
GC> > AFAICS this licence doesn't really contradict anything,
GC> 
GC> That's good sense, but not necessarily a legally safe interpretation.

 Yes, exactly, which is why I'd rather replace this code instead of trying
to interpret it in a legally-safe manner.

GC> > but it would still be simpler if we could avoid using this code
GC> > completely. I'll add this to my TODO...
GC> 
GC> AFAICT, this code enables wx to serialize and deserialize 80-bit
GC> floating-point numbers written to binary files, so the use case is
GC> making such files readable (and even writable) on platforms that
GC> don't support that format (otherwise, something like this:
GC> 
GC>   unsigned char ten_bytes[10];
GC>   fread(&ten_bytes, 10, 1, file_ptr);
GC>   long double x = *(long double*) ten_bytes;
GC>   double y = bourn_cast<double>(x);
GC> 
GC> would suffice). Is that use case important to anyone? in 2020?

 I'm not sure at all, as I wrote, I successfully spent the last 20 years
resisting the urge to look at this code. But generally speaking IME if
there is some functionality, there is always some code somewhere which
relies on it to work exactly as it did.

 Looking at it (with one eye closed, so not to succumb completely to the
urge of starting to change it immediately), I wonder if this code hasn't
been broken for a long, long time. AFAICS whatever it does only makes sense
if we pass it "long double" on x86, while we never do this and always pass
them just "double", which is 8 bytes everywhere -- so there doesn't seem
any possibility for them to meaningfully store it as 10 bytes.

 However we still must be able to read the bytes produced by these
functions in the previous wx versions in the newest one. And I'm not
certain if it's going to be that simple to ensure this without reusing any
of the existing code...

GC> If you're thinking of reimplementing it, let me know so that I
GC> can design some tests that try to break it.

 I'll create some simple tests myself first and will show them to you, so
that you could laugh at my naivety.

GC> > GC> I'm thinking maybe we should just get rid of
GC> > GC>   --disable-apple_ieee
GC> > GC>   --disable-gif
GC> > GC> for lmi.
GC> 
GC> But now I have second thoughts about the apple ieee part, so...

 So I'll really have no choice but to try to get rid of it.

GC> >  I definitely wouldn't object to doing this but, on their own, these
GC> > options are not a problem -- as long as we're building our private wx
GC> > anyhow, we can use whichever options we want for it. Getting rid of the
GC> > corresponding checks in wx_checks.cpp would be helpful, however.
GC> 
GC> Okay, I'll do that. Otherwise, those checks would probably
GC> prevent us from using a debian wx package.

 Yes, they certainly would: I've grepped Debian repository and there is no
trace of neither --disable-gif nor --disable-apple_ieee there, so they
don't disable them (after doing it, I've realized that I could have tried
just installing the packages instead, but this would have been too simple,
of course).

VZ

pgpNwNm99870a.pgp
Description: PGP signature