Pointer arithmetic demo accesses out-of-bounds memory without warning (Ch 30 / 00.pointers.ipynb)
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- cpp, jupyter-notebook
- Domain
- documentation
Research direction
Open 30.pointers-and-memory-management/00.pointers.ipynb and inspect cell 16's int_ptr.cpp example. Replace the single-int setup with the valid array-based example described in the issue, then verify the displayed pointer-arithmetic output no longer dereferences out-of-bounds memory.
Written by the indexing model from the issue text.
Description
In 30.pointers-and-memory-management/00.pointers.ipynb, the int_ptr.cpp example (cell 16) declares a single int i = 0; and then performs pointer arithmetic that dereferences memory past i:
int i = 0;
int *p = &i;
// ...
cout << "*(p + 1) = " << ... << *(p + 1) << '\n'; // dereferencing OOB
cout << "*(p + 2) = " << ... << *(p + 2) << '\n'; // dereferencing OOB
This is undefined behavior. The C++ standard permits p+1 (one-past-the-end pointer arithmetic) but explicitly forbids dereferencing it when p doesn't point into an array. The demo "works" because the runtime happens to allow reading adjacent stack memory, but the output is shown to students as if it were a normal pattern to learn from — which risks teaching the wrong mental model.
Suggested fix (preferred: option 1)
Option 1 — make the example valid by using an actual array:
int arr[3] = {0, 1, 2};
int *p = arr;
// (p+1) and (p+2) are now valid dereferences into arr[1] and arr[2]
Option 2 — keep the example but add a markdown cell explicitly noting this is UB, and that the output happens to read adjacent stack memory (sometimes &p and parts of the stack frame).
Option 1 is cleaner for a teaching context: students see correct pointer arithmetic without needing the UB sidebar.
Context
Surfaced during Ch 30 evaluation. Small isolated change; pairs well with the delete[] bug fix as another "first commit" candidate.
- Dominant language
- Jupyter Notebook
- Stars
- 3
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from kangwonlee/2018pycpp
-
enhancement freshman-audience
Difficulty 3/5 1-3 hours Newbie friendliness 68/100
kangwonlee/2018pycpp#76 ·
-
Intel assembly Open
Difficulty 3/5 1-2 days Newbie friendliness 25/100
kangwonlee/2018pycpp#65 ·
-
CI in tutorial git Openenhancement
Difficulty 3/5 1-2 days Newbie friendliness 35/100
kangwonlee/2018pycpp#61 ·
-
Rust study Open
Difficulty 5/5 Over a week Newbie friendliness 15/100
kangwonlee/2018pycpp#56 · 1 comment ·
-
question
Difficulty 3/5 1-2 days Newbie friendliness 25/100
kangwonlee/2018pycpp#52 ·
All issues in kangwonlee/2018pycpp
Similar issues
-
Area: Excel support
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
orbeon/orbeon-forms#7893 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
docToolchain/docToolchain#1705 ·
-
kb-infra-drift
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
OCHA-DAP/ds-knowledge-base#653 · 1 comment ·
-
area/dev-productivity area/disaster-recovery area/ipcei kind/enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
namespace operations
Difficulty 1/5 Under an hour Newbie friendliness 90/100
EclipseFdn/open-vsx.org#13419 ·