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

[tlaronde@polynum.com]

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).

Best,
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C