Apropos casting...

Log in or register to post comments
Go To Last Post
6 posts / 0 new
Author
Message
barnacle
barnacle's picture
Level: Raving Lunatic
Joined: Tue. Jan 3, 2006
Posts: 6608 View posts
Location: Berlin DE
#1
Posted by barnacle: Sat. Oct 31, 2020 - 07:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just as an example, and only because it slowed me down for a moment or two...

 

	while ((uint16_t)regs.pc != next_instruction_address)
	{
		interpret_and_disassemble();
	}

next_instruction_address is uint16_t; regs.pc is int16_t.

 

Without the cast, in some circumstances (e.g. regs.pc = 0xff00) the while loop takes forever... why?

 

Because regs.pc can have a negative value and next_instruction_address can't. Hence when regs.pc is negative, they can never be equal and so the loop never terminates. Yet the bit pattern is identical... it's all a question of how it's interpreted.

 

And why is regs.pc signed I hear you ask? Short answer: can't remember. I think it was so some of the indexed addressing modes worked properly.

 

Neil

Neil Barnes
www.nailed-barnacle.co.uk

Tags:

Tools, Compilers and General Programming, PC-lint Plus, SEI CERT C, MISRA
Top
MrKendo
MrKendo's picture
Level: Resident
Joined: Mon. Nov 19, 2018
Posts: 537 View posts
Posted by MrKendo: Sat. Oct 31, 2020 - 08:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What platform is this ?

It would make sense if you have 32 bit int.

Doesn't make sense for 16 bit int (it would be the same without the cast in that case).

 

Integer promotions are applied for the != operation.

With 32 bit int, both uint16_t and int16_t promote to int (which is signed) and int is the type usd for the != operation.

So assuming 32 bit int,

uint16_t value of 65280 (0xff00) promotes to int, value unchanged so still 65280 (0x0000ff00)

int16_t value of -256 (0xff00) promotes to int, value unchanged so still -256 (0xffffff00)

and -256 is not equal to 65280

 

 

 

 

 

 

Top
gchapman
gchapman's picture
Level: 10k+ Postman
Joined: Tue. Jan 9, 2007
Posts: 13746 View posts
Location: Clay County, Texas, u.S.A.
Posted by gchapman: Sun. Nov 1, 2020 - 12:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

barnacle wrote:
Without the cast, in some circumstances (e.g. regs.pc = 0xff00) the while loop takes forever... why?
The first pass through a linter was acceptable; enabled MISRA for the next pass that identified Rule 10.4

In a C coding standard :

INT02-C. Understand integer conversion rules - SEI CERT C Coding Standard - Confluence

via MISRA C:2012 - SEI CERT C Coding Standard - Confluence

 

PC-lint Plus Online Demo - Gimpel Software - The Leader in Static Analysis for C and C++ with PC-lint Plus

 

"Dare to be naïve." - Buckminster Fuller

Top
N.Winterbottom
N.Winterbottom's picture
Level: Posting Freak
Joined: Tue. Oct 1, 2002
Posts: 1969 View posts
Location: Redbourn, Herts, UK
Posted by N.Winterbottom: Sun. Nov 1, 2020 - 11:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For avr-gcc (I suppose any gcc also) you must enable this specific warning -Wsign-compare to catch it.

 

https://godbolt.org/z/a31v5b

Top
barnacle
barnacle's picture
Level: Raving Lunatic
Joined: Tue. Jan 3, 2006
Posts: 6608 View posts
Location: Berlin DE
Posted by barnacle: Sun. Nov 1, 2020 - 06:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes - GCC on linux (I thought I'd said that in the original post - I certainly thought I did :) but as indicated, no warning - which I would argue is probably a mistake.

 

I just thought it was a useful reminder, given the recent thread on casting, that while the bits don't change, the interpretation of those bits does - in this case, with a hidden promotion to wider (probably 64-bit) int.

 

Neil

Neil Barnes
www.nailed-barnacle.co.uk

Top
Scroungre
Scroungre's picture
Level: Posting Freak
Joined: Wed. Apr 18, 2007
Posts: 1424 View posts
Location: Southern California
Posted by Scroungre: Sun. Nov 1, 2020 - 07:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wayell, if regs.pc monotonically changes, there are six possibilities, none of which involves looping forever1:

 

1) regs.pc is negative and descending

   1a) eventually, it'll wrap its counter and turn positive again, thus will, sooner or later, match

2) regs.pc is negative and ascending

   2a) eventually, regs.pc will become positive and match

3) regs.pc is positive. greater than and descending

   3a) Therefore it'll match soon

4) regs.pc is positive, less than, and descending

   4a) Therefore it'll wrap around, to negative, through all the negative numbers, and back down from top again, eventually matching

5) regs.pc is positive, greater than, and ascending

   5a) Therefore it'll wrap around, to negative, through all the negative numbers, and back up from zero again, eventually matching

6) regs.pc is positive, less than, and ascending

   6a) Then it'll match soon.

 

S.

 

1. Now, some of them might take a rather long time, especially if promoted to 64 bits, but not forever in a literal sense...

 

Edited to fix bad paste job.

Last Edited: Sun. Nov 1, 2020 - 07:35 PM
Top