Application of containerization for unification of the development environment in teaching the C language
DOI:
https://doi.org/10.65237/2336-3630-2026-5(2)-1Keywords:
C language, memory management, memory leaks, Docker, containerization, Valgrind, AddressSanitizer, Dev Containers, environment reproducibility, WSL2Abstract
The article addresses the problem of development environment instability when teaching information technology students to detect memory management errors in the C programming language, where heterogeneous operating systems, divergent library versions and platform-specific tooling collectively erode the practical training time available to instructors and students. The main classes of memory management defects encountered in introductory and advanced systems programming courses are characterised – memory leaks, use-after-free, buffer overflow, double-free and use of uninitialised memory – together with modern detection instruments: Valgrind/ Memcheck and AddressSanitizer for dynamic analysis, Cppcheck for static analysis, and the GDB debugger for interactive investigation of failures. It is shown that in real student groups working on a mixed Linux/Windows/macOS fleet, a significant share of study time is spent on resolving technical environment issues rather than on forming target competencies – a phenomenon known as the “works on my machine” problem. A Docker-based containerisation approach is proposed in which the entire tool environment is described declaratively in a Dockerfile stored alongside the course source code under version control, thus realising the “Infrastructure as Code” principle in the educational context. The three-tier architecture of the solution is described: the host operating system, a Docker image based on debian:bookworm-slim, and integration with Visual Studio Code via the Dev Containers mechanism, with attention to the security parameters required for GDB inside the container. Specifics of deployment on Linux, on Windows via WSL2 and on macOS via OrbStack are discussed separately, including filesystem performance considerations. A comparative analysis of native and Docker approaches across nine educational criteria – including reproducibility, project isolation, environment versioning and assignment verification complexity – is performed. Practical approbation in a Programming course confirms a fivefold reduction in environment-related instructor consultations and an increase from 47% to 72% in the share of students who successfully configure the complete toolchain at the first session. The approach is recommended as a standard for organising practical work in systems programming courses and creates the basis for automated assignment assessment.
References
1. Kernighan, B. W., & Ritchie, D. M. (1988). The C programming language (2nd ed.). Prentice Hall.
2. Seacord, R. C. (2013). Secure coding in C and C++ (2nd ed.). Addison-Wesley Professional.
3. Nethercote, N., & Seward, J. (2007). Valgrind: A framework for heavyweight dynamic binary instrumentation. In Proceedings of the 28th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI '07) (pp. 89–100). ACM. https://doi.org/10.1145/1250734.1250746
4. Serebryany, K., Bruening, D., Potapenko, A., & Vyukov, D. (2012). AddressSanitizer: A fast address sanity checker. In Proceedings of the 2012 USENIX Annual Technical Conference (ATC '12) (pp. 309–318). USENIX Association. https://www.usenix.org/conference/atc12/technical-sessions/presentation/serebryany
5. ISO/IEC 25010:2023. (2023). Systems and software engineering – Systems and software quality requirements and evaluation (SQuaRE) – Product quality model. ISO. https://www.iso.org/standard/78176.html
6. Boehm, B. W. (1981). Software engineering economics. Prentice-Hall.
7. Wilson, G., Aruliah, D. A., Brown, C. T., Chue Hong, N. P., Davis, M., Guy, R. T., Haddock, S. H. D., Huff, K. D., Mitchell, I. M., Plumbley, M. D., Waugh, B., White, E. P., & Wilson, P. (2014). Best practices for scientific computing. PLOS Biology, 12(1), Article e1001745. https://doi.org/10.1371/journal.pbio.1001745
8. Boettiger, C. (2015). An introduction to Docker for reproducible research, with examples from the R environment. ACM SIGOPS Operating Systems Review, 49(1), 71–79. https://doi.org/10.1145/2723872.2723882
9. Cito, J., & Gall, H. C. (2016). Using Docker containers to improve reproducibility in software engineering research. In Proceedings of the 38th International Conference on Software Engineering Companion (ICSE '16) (pp. 906–907). ACM. https://doi.org/10.1145/2889160.2891057
10. Merkel, D. (2014). Docker: Lightweight Linux containers for consistent development and deployment. Linux Journal, 2014(239), Article 2. https://doi.org/10.5555/2600239.2600241
11. Open Container Initiative. (2023). OCI image format specification, v1.1.0. https://github.com/opencontainers/image-spec
12. Microsoft Corporation. (2023). Development containers specification. https://containers.dev/
13. CC2020 Task Force. (2020). Computing curricula 2020: Paradigms for global computing education. Association for Computing Machinery. https://doi.org/10.1145/3467967
14. MISRA. (2012). MISRA C: 2012 – Guidelines for the use of the C language in critical systems. Motor Industry Software Reliability Association.
15. IEEE. (2021). IEEE standard for DevOps: Building reliable and secure systems including application build, package, and deployment (IEEE Std 2675-2021). IEEE. https://doi.org/10.1109/IEEESTD.2021.9415476
16. Danyliuk, I. (2026). VS Code configuration for C development on Linux: Native and Docker approaches [Online resource]. https://github.com/uixcoder/c_utils
/blob/main/memory_leaks/linux/vscode_config_linux_c_dev.md
17. Danyliuk, I. (2026). C development environment setup via Docker [Online resource]. https://github.com/uixcoder/c_utils/blob/main/memory_leaks/crossplatform/
vscode_config_docker_crossplatform.md
Downloads
Published
Issue
Section
License
Copyright (c) 2026 CENTRAL EUROPEAN JOURNAL OF SCIENCE AND RESEARCH

This work is licensed under a Creative Commons Attribution 4.0 International License.