Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
Generally speaking, pointer arithmetic is undefined behavior unless carried out on arrays. This is how the additive operators behave, C17 6.5.6: For the purposes of these operators, a pointer to...
Answer
#3: Post edited
by
Lundin
·
2021-12-14T12:26:43Z (about 3 years ago)
- Generally speaking, pointer arithmetic is undefined behavior unless carried out on arrays. This is how the additive operators behave, C17 6.5.6:
- > For the purposes of these operators, a pointer to an object that is not an element of an array behaves
- the same as a pointer to the first element of an array of length one with the type of the object as its
- element type.
- > /--/
- > If both the pointer operand and the result point
- to elements of the same array object, or one past the last element of the array object, the evaluation
- shall not produce an overflow; otherwise, the behavior is undefined. If the result points one past
- the last element of the array object, it shall not be used as the operand of a unary * operator that is
- evaluated.
- So your code has undefined behavior - during pointer arithmetic `b` is to be regarded as an array `int[1]` and you access it out of bounds.
Furthermore, the C standard doesn't know or mentioning anything about stacks and stack frames - there's no guarantees of the underlying memory layout at all. For example a compiler for a 64 bit CPU with 32 bit int might decide to insert padding between the two integers and that's perfectly fine as far as C goes - there's no guarantee about adjacent allocation unless you use structs or arrays.Also, while down-counting stacks are most common, some CPUs like for example Microchip PIC have up-counting stacks. Other CPUs don't even have stacks! For example I've worked with writing C for a very low end MCU (Freescale RS08) which didn't have a stack. I was painful but perfectly possible. There are similar stackless, extremely low end 4 bit MCUs used in some consumer electronics.
- Generally speaking, pointer arithmetic is undefined behavior unless carried out on arrays. This is how the additive operators behave, C17 6.5.6:
- > For the purposes of these operators, a pointer to an object that is not an element of an array behaves
- the same as a pointer to the first element of an array of length one with the type of the object as its
- element type.
- > /--/
- > If both the pointer operand and the result point
- to elements of the same array object, or one past the last element of the array object, the evaluation
- shall not produce an overflow; otherwise, the behavior is undefined. If the result points one past
- the last element of the array object, it shall not be used as the operand of a unary * operator that is
- evaluated.
- So your code has undefined behavior - during pointer arithmetic `b` is to be regarded as an array `int[1]` and you access it out of bounds.
- Furthermore, the C standard doesn't know or mention anything about stacks and stack frames - there's no guarantees from the standard of the underlying memory layout at all. For example a compiler for a 64 bit CPU with 32 bit `int` might decide to insert padding between the two integers and that's perfectly fine as far as C goes - there's no guarantee about adjacent allocation unless you use structs or arrays.
- Also, while down-counting stacks are most common, some CPUs like for example Microchip PIC have up-counting stacks. Other CPUs don't even have stacks! For example I've worked with writing C for a very low end MCU (Freescale RS08) which didn't have a stack. I was painful but perfectly possible. There are similar stackless, extremely low-end 4 bit MCUs used in some consumer electronics.
#2: Post edited
by
Lundin
·
2021-12-14T08:35:51Z (about 3 years ago)
- Generally speaking, pointer arithmetic is undefined behavior unless carried out on arrays. This is how the additive operators behave, C17 6.5.6:
- > For the purposes of these operators, a pointer to an object that is not an element of an array behaves
- the same as a pointer to the first element of an array of length one with the type of the object as its
- element type.
- > /--/
- > If both the pointer operand and the result point
- to elements of the same array object, or one past the last element of the array object, the evaluation
- shall not produce an overflow; otherwise, the behavior is undefined. If the result points one past
- the last element of the array object, it shall not be used as the operand of a unary * operator that is
- evaluated.
- So your code has undefined behavior - during pointer arithmetic `b` is to be regarded as an array `int[1]` and you access it out of bounds.
Furthermore, the C standard doesn't know or mentioning anything about stacks and stack frames - there's no guarantees of the underlying memory layout at all.- Also, while down-counting stacks are most common, some CPUs like for example Microchip PIC have up-counting stacks. Other CPUs don't even have stacks! For example I've worked with writing C for a very low end MCU (Freescale RS08) which didn't have a stack. I was painful but perfectly possible. There are similar stackless, extremely low end 4 bit MCUs used in some consumer electronics.
- Generally speaking, pointer arithmetic is undefined behavior unless carried out on arrays. This is how the additive operators behave, C17 6.5.6:
- > For the purposes of these operators, a pointer to an object that is not an element of an array behaves
- the same as a pointer to the first element of an array of length one with the type of the object as its
- element type.
- > /--/
- > If both the pointer operand and the result point
- to elements of the same array object, or one past the last element of the array object, the evaluation
- shall not produce an overflow; otherwise, the behavior is undefined. If the result points one past
- the last element of the array object, it shall not be used as the operand of a unary * operator that is
- evaluated.
- So your code has undefined behavior - during pointer arithmetic `b` is to be regarded as an array `int[1]` and you access it out of bounds.
- Furthermore, the C standard doesn't know or mentioning anything about stacks and stack frames - there's no guarantees of the underlying memory layout at all. For example a compiler for a 64 bit CPU with 32 bit int might decide to insert padding between the two integers and that's perfectly fine as far as C goes - there's no guarantee about adjacent allocation unless you use structs or arrays.
- Also, while down-counting stacks are most common, some CPUs like for example Microchip PIC have up-counting stacks. Other CPUs don't even have stacks! For example I've worked with writing C for a very low end MCU (Freescale RS08) which didn't have a stack. I was painful but perfectly possible. There are similar stackless, extremely low end 4 bit MCUs used in some consumer electronics.
#1: Initial revision
by
Lundin
·
2021-12-14T07:59:50Z (about 3 years ago)
Generally speaking, pointer arithmetic is undefined behavior unless carried out on arrays. This is how the additive operators behave, C17 6.5.6: > For the purposes of these operators, a pointer to an object that is not an element of an array behaves the same as a pointer to the first element of an array of length one with the type of the object as its element type. > /--/ > If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined. If the result points one past the last element of the array object, it shall not be used as the operand of a unary * operator that is evaluated. So your code has undefined behavior - during pointer arithmetic `b` is to be regarded as an array `int[1]` and you access it out of bounds. Furthermore, the C standard doesn't know or mentioning anything about stacks and stack frames - there's no guarantees of the underlying memory layout at all. Also, while down-counting stacks are most common, some CPUs like for example Microchip PIC have up-counting stacks. Other CPUs don't even have stacks! For example I've worked with writing C for a very low end MCU (Freescale RS08) which didn't have a stack. I was painful but perfectly possible. There are similar stackless, extremely low end 4 bit MCUs used in some consumer electronics.