bug#45433: 28.0.50; byte/native-compiling ivy and ox-publish possibly miscompiled

[Andrea Corallo]

Mauricio Collares <mauricio@collares.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>> All right I did some investigation.  This is how the top level form
>> looks in the .elc file:
>>
>> (byte-code
>> "\300\301\302\303!\203\f^@\303\202^M^@\304\"\210\305\306!\207"
>> [defalias xxx--file-local-name fboundp file-local-name #[257
>> "\300^A\301\"\206^H^@\211\207" [file-
>> remote-p localname] 4 "\n\n(fn FILE)"] provide xxx] 4)
>>
>> When we execute this from the .elc in exec_byte_code we have:
>>
>> (gdb) p *(bytestr_data+10)
>> $43 = 13 '\r'
>>
>> While loading from .eln we have:
>>
>> (gdb) p *(bytestr_data+10)
>> $31 = 10 '\n'
>>
>> ATM I've no idea why of this difference, I'm pretty sure in the eln we
>> have 13 so might be a reader miss-configuration?
>>
>> I'll look into it more to see where the difference is coming from,
>> hopefully should be pretty narrowed at this stage.
>
> Hi Andrea,
>
> You're definitely onto something here! The numbers 13 and 10 seem very
> suspicious, and the esxml-query code also only fails with 13
> variables. Maybe the .elc is being opened as a text file when
> native-compiling and the newlines are being converted to Unix style when
> reading?

Indeed this smells of EOL conversion as one is '/r' and the other '/n'.
Yesterday I tried quickly setting 'inhibit_eol_conversion' to true while
reading but had no success.  I might have been wrong as well and perhaps
the issue is while printing?

I'll look into it more this evening or tomorrow.

  Andrea