Click here to Skip to main content
15,886,362 members
Home / Discussions / C / C++ / MFC
   

C / C++ / MFC

 
AnswerRe: Help with Heap Corruption "Critical error detected c0000374" Pin
Jochen Arndt19-Jul-17 21:36
professionalJochen Arndt19-Jul-17 21:36 
GeneralCards.dll Pin
Member 1171866719-Jul-17 1:40
Member 1171866719-Jul-17 1:40 
AnswerRe: Cards.dll Pin
Jochen Arndt19-Jul-17 3:29
professionalJochen Arndt19-Jul-17 3:29 
GeneralRe: Cards.dll Pin
Richard MacCutchan19-Jul-17 4:59
mveRichard MacCutchan19-Jul-17 4:59 
GeneralRe: Cards.dll Pin
leon de boer19-Jul-17 5:54
leon de boer19-Jul-17 5:54 
GeneralRe: Cards.dll Pin
Richard MacCutchan19-Jul-17 6:58
mveRichard MacCutchan19-Jul-17 6:58 
QuestionCompiler generated code Pin
ForNow13-Jul-17 14:43
ForNow13-Jul-17 14:43 
AnswerRe: Compiler generated code Pin
leon de boer13-Jul-17 16:43
leon de boer13-Jul-17 16:43 
You need to go and review C/C++ pointer arithmetic Smile | :)

Your pointer arithmetic asks it to do that .... you must have your warnings turn way down because really it should give a warning.

Since it is has escaped you, specifically what you have asked it to do is add 8 times the size of PSW to the pointer to PSW which is what it did. For some reason your expect byte operation on a pointer that isn't a pointer to a byte. If you wanted a byte operation then cast the pointer to a byte.

I can't make head nor tails of what appears to be bitcount numbers. I warn you that you need pack(1) for that, and even if packed those bitcounts don't match. It looks like some of the bit fields need unions because there seems to be variants.
I assume you were trying to point at the 8th byte in the struct but without packing it isn't guaranteed you will get what you expect. I strongly recommend you put the bitpacks in a struct so it's named and then set the pointer to the named element in the struct.

It would be a whole lot easier to pack that structure exactly as whatever those bitcounts you are writing because it seems like it's a real thing ... So make the struct match reality. This is my best guess what your struct is supposed to be and I have used the proper standard C/C++ types, it is ill advised to do such precise packing on user defined types like BYTE. C/C++ standard file stdint.h is your friend use it when not on Windows/Linux API. The uint8_t will cast to everything properly as C knows exactly what it is.
#include <assert.h> // I am going to check packing at compile time (generates no code)
#include <stdbool.h> // This defines bool we will need it if not included already
#include <stdint.h> // C standard for fixed width types we want uint8_t .. we need to included if not already
#pragma pack(push, 1)
struct psw_s {								// Named the struct for compile time checks
	union {

		/* Variant 1 structure of first 128 bits */
		struct variant1 {
			uint8_t     sysmask;			/* System mask      (0 -  7) */
			uint8_t		pkey;				/* PSW Key          (8 - 11) */
			uint8_t    states;				/* EC,M,W,P bits   (12 - 15) */

			/*  guessing you want an Anonymous struct to match bit count on byte 3 */
			struct byte3_fields {
				uint8_t asc : 2;			/* Address space control  (16 - 17) */
				uint8_t cc : 2;				/* Condition code  (18 - 19) */
				uint8_t progmask : 4;		/* Program mask    (20 - 23) */
			};

			/* best guess at variant unions needed to match bit count on byte 4 */
			union {
				uint8_t     zerobyte;		/* Zeroes          (24 - 31) ... variant 1 */
				struct byte4_fields {		/* variant 2 anonymous struct */
					uint8_t zerobyte4 : 7;	/* Zeroes          (24 - 30) */
					bool amode64 : 1;		/* 64-bit addressing    (31) */
				};
			};

			struct byte5_fields {			/* Addressing mode (32 - 33) */
				bool amode : 1;				/* 31-bit addressing    (32) */
				bool zeroilc : 1;			/* 1=Zero ILC           (33) */
				uint8_t zerobyte5 : 6;		/* Zeroes          (34 - 39) */
			} AddrMode;
			uint8_t variant1_unused[11];	/* (40-127) .. 11 byte * 8bits = 88bits */
		};

		/* Variant 2 ... 16 byte array (first 128 bits) */
		char     ia[16];					/* Instruction address array */

		/* Just me messing around maybe 32bit is faster so lets define it */
		/* Variant 3 ... 4 uint32_t array (first 128 bits) */
		uint32_t ia32[4];                   /* Instruction address array as 32 bits */

	};
	char      amask[4];						/* Address wraparound mask   */
	char      intcode[2];					/* Interruption code         */
	BYTE     ilc;							/* Instruction length count  */
	BYTE     unused;
} PSW;
/* Run compile time check on struct that it packed correctly */
static_assert(offsetof(struct psw_s, amask) == 17, "Structure pack failed amask should be byte 17 in struct");
#pragma pack(pop)

So ia and the struct totally overlap each other they are different ways to get to same data being the 16 bytes (128 bits at the top of the struct). Array amask is at byte 17 in struct and it is checked at compile time to make dam sure it is. Compile time asserts were added in C++11 spec both GCC and VS have them as should Intel.

Anyhow now you can set the pointer to what you want by name. You can also access the bool fields. PW.AddrMode.amode is the named struct one, amode64 is in an anonymous struct so its just PW.amode64 to access. They are both just bools you can set them true/false or if test them like any bool. That shows you a named and unnamed struct bitfield access.

I think all that gets rid of the need for your pointer arithmetic as there is no field you can't hit by name.

It looks a lot like a hardware register definition I would do, but they get even worse than that Smile | :)
In vino veritas


modified 14-Jul-17 3:28am.

GeneralRe: Compiler generated code Pin
jschell15-Jul-17 7:34
jschell15-Jul-17 7:34 
AnswerRe: Compiler generated code Pin
Peter_in_278013-Jul-17 16:44
professionalPeter_in_278013-Jul-17 16:44 
QuestionInterprocess communication in C without pipes or disk Pin
Chris Maunder12-Jul-17 13:14
cofounderChris Maunder12-Jul-17 13:14 
AnswerRe: Interprocess communication in C without pipes or disk Pin
Espen Harlinn12-Jul-17 14:03
professionalEspen Harlinn12-Jul-17 14:03 
GeneralRe: Interprocess communication in C without pipes or disk Pin
leon de boer12-Jul-17 18:49
leon de boer12-Jul-17 18:49 
AnswerRe: Interprocess communication in C without pipes or disk Pin
Randor 13-Jul-17 14:08
professional Randor 13-Jul-17 14:08 
GeneralRe: Interprocess communication in C without pipes or disk Pin
Chris Maunder19-Jul-17 6:01
cofounderChris Maunder19-Jul-17 6:01 
AnswerRe: Interprocess communication in C without pipes or disk Pin
Joe Woodbury17-Jul-17 10:53
professionalJoe Woodbury17-Jul-17 10:53 
Questionwhich one would be better? Pin
bestbear11-Jul-17 1:51
bestbear11-Jul-17 1:51 
AnswerRe: which one would be better? Pin
Jochen Arndt11-Jul-17 3:41
professionalJochen Arndt11-Jul-17 3:41 
AnswerRe: which one would be better? Pin
leon de boer11-Jul-17 5:50
leon de boer11-Jul-17 5:50 
AnswerRe: which one would be better? Pin
bestbear11-Jul-17 17:18
bestbear11-Jul-17 17:18 
Questionwhich one would be better? Pin
bestbear11-Jul-17 1:18
bestbear11-Jul-17 1:18 
Questionquestions plz solve throught c or c++ Pin
Member 1330375110-Jul-17 22:51
Member 1330375110-Jul-17 22:51 
AnswerRe: questions plz solve throught c or c++ Pin
CodeWraith10-Jul-17 23:21
CodeWraith10-Jul-17 23:21 
AnswerRe: questions plz solve throught c or c++ Pin
Richard MacCutchan11-Jul-17 0:21
mveRichard MacCutchan11-Jul-17 0:21 
AnswerRe: questions plz solve throught c or c++ Pin
Patrice T16-Jul-17 17:34
mvePatrice T16-Jul-17 17:34 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.