Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.albasani.net!news.mixmin.net!aioe.org!.POSTED!not-for-mail From: =?UTF-8?b?xLVlc3M=?= stone Newsgroups: comp.lang.java.programmer Subject: Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi] Date: Wed, 22 Oct 2014 14:00:11 +0000 (UTC) Organization: A noiseless patient Spider Lines: 39 Message-ID: References: <6c324a98-b16e-4904-b014-c53fd799cb1b@googlegroups.com> NNTP-Posting-Host: lQA7rOFasboES0+IO4savg.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Forte Agent 6.00/32.1186 X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.java.programmer:30156 In article m289av$gdo$1@dont-email.me, Eric Sosman said... >> The problem is mainly the interaction with that and the signedness of >> bytes. So you end up with binary 11001001 turning into >> 10000000000000000000000001001001 > > [calls me a liar] No! None of the nasty things that you have said or implied about me are at all true. >> and when you later truncate or mask off the high bytes you wind up with >> 01001001, which is wrong. > > [calls me a liar] No! None of the nasty things that you have said or implied about me are at all true. >> So you have to >> watch that you don't lose the high bit when something causes auto- >> promotion. And it's tricky, because it can happen even if you have a >> computation "entirely in bytes", i.e. nothing but bytes in and >> assignment to a parameter or local of byte size. > > [calls me a liar] No! None of the nasty things that you have said or implied about me are at all true. > Ultimately, the need for promotion arises from the inability of > most computers nowadays to do arithmetic on narrow integers. Nope. > [irrelevant stuff about the hardware implementation deleted] That has nothing to do with how a HLL's type system works, and you know it.