From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mimir.eigenstate.org ([206.124.132.107]) by ewsd; Thu Jul  9 12:55:19 EDT 2020
Received: from abbatoir.fios-router.home (pool-74-101-2-6.nycmny.fios.verizon.net [74.101.2.6])
	by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id d5787c50 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO);
	Thu, 9 Jul 2020 09:55:10 -0700 (PDT)
Message-ID: <8FE0EC1508CC89E5C8EC750F4FFAE0FB@eigenstate.org>
To: tlaronde@polynum.com, ori@eigenstate.org
CC: 9front@9front.org
Subject: Re: [9front] putc/fputc incorrect return?
Date: Thu, 9 Jul 2020 09:55:08 -0700
From: ori@eigenstate.org
In-Reply-To: <20200709161707.GA45@polynum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: virtualized object-oriented self-signing metadata 

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