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

[tlaronde@polynum.com]

On Thu, Jul 09, 2020 at 09:55:08AM -0700, ori@eigenstate.org wrote:
> > 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.

Thank you, but I will have to reduce it because with the pecularities of
RISK (the compilation framework) and the pecularities of the TeX web-to-raw-C
translation process, you will waste a significant amount of time just to get
your way around before succeeding to tackle the problem.

BTW, I tried to truss (with the acid program) the binary, but it gives
absolutely no clue. I hit the problem with classic printf bisection on
the resulting C files.

I will return back to it this week-end and will post an update (whether
the hit on the core or some simplified code exhibiting the problem) at
the begining of next week.

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