NO

Author Topic: Casting bug?  (Read 616 times)

Offline Abdulai

  • Member
  • *
  • Posts: 0
Casting bug?
« on: December 15, 2019, 10:20:59 pm »
I'have a problem with casting priorities in Pelles C V9.00.9

Example:
Code: [Select]
#include <stdio.h>

char Buffer[0x1000] ;
char *pBuf = Buffer ;

int main(int argc, char *argv[])
{
    *((short int*)pBuf)++ = 0xA0D ;  // Wrong compilation

    return 0;
}

Other compilers, including version 7.00.355 , compile this line correctly.

That is: First 0xA0D is assigned and then the pointer is incremented (+2).

But this version first increases the pointer (+2) and then assigns 0xA0D.


Congratulations for your amazing work.

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 1998
    • http://www.smorgasbordet.com
Re: Casting bug?
« Reply #1 on: December 22, 2019, 06:31:42 pm »
This isn't standard C, so any result is possible (and may differ between releases, unfortunately for you).
/Pelle

Offline Akko

  • Member
  • *
  • Posts: 15
Re: Casting bug?
« Reply #2 on: December 30, 2019, 09:00:54 am »
Another comment from me after half a century of programming experience:

That example would not have happened had you followed any recommended good coding style.
Keep it simple, be more verbose, only one action per line, etc.
Let the compiler do the optimization!
Writing convoluted code can become even counterproductive for the optimizer!

Your profit: less errors, easier debugging, better readability, better maintenance.

Offline PabloMack

  • Member
  • *
  • Posts: 12
Re: Casting bug?
« Reply #3 on: March 29, 2020, 05:13:57 pm »
I have run into what I think is a casting bug and I think it is proper C
because the cast is an RValue. I greatly simplified the example just
for illustration of what I am trying to do. This example is just supposed
to copy an 8-byte value from a 64-bit integer to an 8-byte array. Endian-ness
shouldn't matter as it should just copy 8 bytes in memory order.
The Cmp image should end up exactly the same as the Val original,
but it doesn't. It looks like it is pre-incrementing instead of post-
incrementing.  The code does work correctly when I remove the auto
increments and add them on separate lines.

#define ub unsigned char
#define uo unsigned long long

uo Val=0xFEDCBA9876543210;
uo Nxt=0xBEEFABBACADF2468;
ub Cmp[8];

//Test Copy
void copy_uo(ub *Dst,uo *Src)
{
  int ix=0;
  while (ix < 8 )
    Dst[ix++] = *((ub *)Src)++;
}

void main()
{
  //Test Copy
  copy_uo(Cmp,&Val);

  //Print Original
  printf("Val:$%016llX\n",Val);
  printf("Cmp:$%016llX\n",*((uo *)Cmp));
}

Output:
Val:$FEDCBA9876543210
Cmp:$68FEDCBA98765432
« Last Edit: March 31, 2020, 12:16:18 am by PabloMack »

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 1998
    • http://www.smorgasbordet.com
Re: Casting bug?
« Reply #4 on: March 29, 2020, 06:18:40 pm »
This isn't standard C. Cast on an l-value (due to the increment) is a Microsoft extension. There is a known problem with this extension in the current version of Pelles C, and the next version will fix this and give a more expected result, but it's still an extension that should be avoided at all cost (at least IMO).
/Pelle