Re: [9front] putc/fputc incorrect return?

[ori@eigenstate.org]

> Hello,
> 
> On Thu, Jul 09, 2020 at 07:27:13AM -0700, ori@eigenstate.org wrote:
>> 
>> > I write, say 0xaa, it returns 0xffffffaa. So when comparing, this
>> > failed.
>> > 
>> > But the problem is that if I write 0xff it returns 0xffffffff that is
>> > EOF...
>> > 
>> > Isn't putc/fputc supposed to return a "char" as a value that is
>> > 0x000000nn so precisely one can differenciate from EOF error?
>> 
>> Hey -- thanks for the report, but I can't reproduce your issue.
>> Here's my test code:
>> 
>> #include <stdio.h>
>> 
>> int
>> main(int argc, char **argv)
>> {
>> 	printf("\n'%x'\n", putc(0xaa, stdout));
>> 	return 0;
>> }
>> 
>> It prints
>> <junk>
>> 'aa'
>> 
>> I'm running on 9front tip, on amd64.
> 
> Yep, if I compile just this, I get the same and the correct result.
> 
> But if I print the returned value in the kerTeX code, I get the
> promotion ("0xffffffaa") (whether calling putc or fputc)...
> 
> I will have to try to reduce the code to the strict minimum to
> understand what the hell is going on (it works everywhere and it used to
> work under 9front too).
> 
> But there is a fair amount of cascading cpp substitutions due to the
> pseudo-pascal to raw C dance plus system patching and it triggers something...
> 
> And (last minute memory), it tries to use registers too (I will need to
> test this too to see if that makes a difference).

If you can post the code somewhere, I can also take a look.