Why Do We Need the C language in Programming Courses?
Katsuhiko Gondow and Yoshitaka Arahori
Department of Computing Science, Tokyo Institute of Technology, Tokyo, Japan
C Language, Programming Courses, Embedded/System Programming, Operating Systems, Language Pitfalls.
The C language is still one of the important programming languages both in development and in education,
since C has several positive characteristics like good abstraction for low-level programming, and fast execution
speed with less footprint, although C has several drawbacks and pitfalls like buffer overruns. So there are
several research studies to support C programming educations to compensate the C’s drawbacks and pitfalls,
but there is a skeptical view about these research direction: “C is a bad language, so it is better to stop
teaching C, instead of supporting C education”. In this position paper, we argue against this skeptical view,
mainly because C is very important in upper-level courses like embedded/system programming and operating
systems, so worth teaching.
The C language is still one of the important program-
ming languages both in development and in educa-
tion, since C has several positive characteristics like
good abstraction for low-level programming, and fast
execution speed with less footprint, although C has
several drawbacks and pitfalls like buffer overruns.
So there are several research studies to sup-
port C programming educations to compensate the
C’s drawbacks and pitfalls (Uchida and Gondow,
2016)(Freund and Roberts, 1996)(Song et al., 1997)
(Osuka et al., 2012)(Kummerfeld and Kay, 2003),
but there is a skeptical view about these research di-
rection: “C is a bad language, so it is better to stop te-
aching C, instead of supporting C education”. In this
position paper, we argue against this skeptical view,
mainly because C is very important in upper-level
courses like embedded/system programming and ope-
rating systems, so worth teaching, although we admit
that the C language may not be suitable for a first lan-
This paper is organized as follows. Section 2 pre-
sents the background of this position paper: the re-
ason why C is still used (Sec. 2.1), previous work
to support C programming education (Sec. 2.2), pre-
vious work to choose first programming languages
(Sec. 2.3). Section 3 provides four C code examples
to show good abstraction in low-level programming.
In Section 4, our position “the C language is worth
teaching” is given. Section 5 provides the conclusion.
2.1 C Language and Its Uses in
C is a general-purpose procedural programming lan-
guage, developed by D. Richie in 1973 (Ritchie,
1993). Over the 40 years, C has been widely used
as a system implementation language, being revised
through the three standards (C90/C99/C11). For ex-
ample, operating systems like Linux, language pro-
cessors like GCC and JVM, embedded systems, de-
vice drivers, Web servers like Apache are written in C.
In the TIOBE index (TIOBE, 2017) (a measure of po-
pularity of programming language), C has been ran-
ked first or second from 2002 to 2017. Thus C is not
a legacy, but still an active programming language.
As is well known, C has a serious drawback;
C programmers are very likely to write insecure
code like buffer overruns since the compile/run-time
checking of C is very weak. Despite this drawback,
why so many developers use the C language instead
of a more modern, safer language like Java? The ans-
wer is that C has several advantages as below:
C provides better abstraction than assembly lan-
guages. For example, in C, it is easy to pro-
gram low-level access to system or memory using
inline-assembler or pointer arithmetic. This is
the reason why operating systems, device dri-
vers, embedded systems are written in C. The
Gondow, K. and Arahori, Y.
Why Do We Need the C language in Programming Courses?.
DOI: 10.5220/0006837205490556
In Proceedings of the 13th International Conference on Software Technologies (ICSOFT 2018), pages 549-556
ISBN: 978-989-758-320-9
Copyright © 2018 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
compile/run-time checking of C is weak on pur-
pose to allow this kind of low-level description in
Most C programs run fast in less memory foot-
print. This is closely related to C’s weak run-time
checking. This is the reason why Web servers like
Apache or language processors like GCC are writ-
ten in C.
Thus the C language is indispensable to write ef-
ficient and portable code, where assembly languages
are required or execution speed and less footprint are
2.2 Previous Work to Support C
Programming Education
There are several previous works to support C pro-
gramming education as follows, to compensate C’s
weak compile-time/runt-time checking. One impor-
tant issue is that there is a skeptical view about this
research direction; “C is a bad language, so it is bet-
ter to stop teaching C, instead of supporting C educa-
We argue against this skeptical view in Sec. 4.
C-Helper (Uchida and Gondow, 2016) is a C sta-
tic checker of our previous work, that aims to
emit more direct error messages understandable
for novices to correct wrong programs, and also
aims to handle latent errors. As our another pre-
vious work (Kojima et al., 2015) indicated, war-
ning messages in commercial-level compilers like
GCC are often difficult and misleading for novice
programmers. Our C-Helper tries to (partially)
solve this problem.
Listing 1: Example of assigning string to char array
1 char arr[20];
2 arr[20] = "This is illegal";
For example, for Listing 1, GCC-4.7.2 emits the
message warning: assignment makes integer
from pointer without a cast”, which is very confu-
sing for novices. Instead, our C-Helper provides
a more direct message String cannot be stored
in an element of char array variable. Consider to
use strcpy”.
Thetis (Freund and Roberts, 1996) is an integrated
development environment for C with C interpre-
ter, understandable error reporting, run-time error
Actually there was this question in our presentation in
(Uchida and Gondow, 2016).
detection, debugging/visualization tools. A spe-
cial feature of Thetis is strengthened syntactic re-
strictions, where common code fragments often
mistakenly used by novices are regarded as er-
rors by Thetis, even though they are perfectly le-
gal in the C standard. The most common exam-
ple is if(i=0)···, where the assignment operator
= is often misused instead of the relational opera-
tor = = by novices.
C-Tutor (Song et al., 1997) is a C program ana-
lysis tool, which provides novices with under-
standable messages to correct their wrong pro-
grams. C-Tutor combines static and dynamic ana-
lysis techniques, and extracts novice’s intentions
using sample programs.
CX-checker (Osuka et al., 2012) is a C coding
style checker. While the current C-Helper only
checks unbalanced indentation as a common co-
ding style, CX-checker copes with various sty-
les, which are highly customizable using XPath,
DOM and wrapper API.
Kummerfeld’s method (Kummerfeld and Kay,
2003) catalogs some common C/C++ compiler er-
ror messages, typical code examples for them, and
their possible corrections as a Web-based refe-
rence guide. This method might be effective, but
its maintenance cost is very high since the catalog
needs to be updated whenever compiler messages
are changed.
2.3 Previous Work to Choose First
Programming Languages
There are so many discussions about what language
to teach as a first programming language (Kaplan,
2010) as below. There are many factors to decide
this: e.g., student’s ability, interest, background, pro-
spective career, the levels of courses, and so on, thus
making this discussion harder. Although this discus-
sion is very common in our community, as far as we
know, not restricted to the first language, what pro-
gramming languages should be taught in the entire
computer science courses has not been studied suf-
Early work suggested the C language was well
introduced in introductory programming courses.
For example, (Gilberg and Forouzan, 1996) repor-
ted the number of students in C courses dramati-
cally increased compared to Pascal courses. Also,
(Hosch, 1996) reported the combination of C and
UNIX was well taught. Of course, these may not
apply to today’s situation since new programming
ICSOFT 2018 - 13th International Conference on Software Technologies
languages have emerged like Java, Python, C# and
Java is one of the most popular first language no-
wadays; for example, Java is ranked first in (Gas-
par et al., 2007), and ranked second in (Guo,
2014). As positive characteristics, Java is (relati-
vely) small, robust, portable (Hosch, 1996)(King,
1997). Furthermore, Java is attractive to students
since Java is a programming language used to de-
velop Android applications. Of course, Java has
several minor problems; e.g., uncaught exceptions
must be declared explicitly, which is troublesome
for introductory students (Hosch, 1996)(King,
C# is another candidate of today’s first program-
ming language. As (Bates, 2004) mentioned, C#
is easier to learn the fundamental concepts in the
programming, since C# is a very sophisticated
object-oriented language.
Python is yet another most popular first language
nowadays; for example, Python is ranked first in
(Guo, 2014). As positive characteristics, Python
is simple, dynamic, readable and Python has fe-
wer syntactic exceptions. (Sanders and Langford,
2008) pointed out another interesting issue; Py-
thon is a language that attracts both experienced
and inexperienced students. Like Scheme, Python
is easily accessible to inexperienced students. At
the same time, Python is a real-world popular lan-
guage, so Python is positively accepted to expe-
rienced students, too.
JavaScript is a today’s very popular language, but
JavaScript seems not to be considered as a good
candidate of first programming languages. For
example, (Mombrea, 2014) pointed out that Ja-
vaScript is a poor example of Object-Oriented
programming. Another issue is that JavaScript’s
callback hells make it difficult for novices to le-
arn JavaScript programming. The characteris-
tic of “run-to-completion” in JavaScript prohi-
bits programmers from blocking like simply cal-
ling sleep(10) in C. Instead, JavaScript always
forces programmers to use callbacks (e.g., using
It is often said that one big advantage of the C
language is good abstraction for low-level program-
Figure 1: sbrk allocates memory by moving down the
break position.
Listing 2: Outline of custome memory allocator.
1 struct memory buckets f r e e l i s t ;
2 void my malloc ( s ize t si ze ) {
3 void p , s ;
4 / / f i r s t search f r e e l i s t for an unused
5 / / bucket with s iz e bytes
6 p = s ea r ch f r eel ist ( size );
7 if (p != NULL) return p ;
9 / / then c al l sbrk , and divide the obtained
10 / / memory into p and f r e e l i s t
11 s = sbrk (BULK MEMORY SIZE) ;
12 divide mem ( s , &p , &f r e e l i s t ) ;
13 return p;
14 }
ming, e.g., in (TechLiebe, 2014)(Noordergraaf et al.,
2015)(Viswa, 2014). But few of them present con-
crete code examples, which makes it difficult to dis-
cuss the reason why the C language is required in em-
bedded/system programming courses, and thus how
the C language is useful for students to understand
how the system works inside the computer. In this
section, we present several concrete code examples to
show that the C language is good abstraction for low-
level programming, but Java is not.
3.1 Custom Memory Allocator
To learn the mechanism of memory management in a
hands-on way, it is a good way to implement a sim-
ple custom memory allocator, garbage collector, buf-
fer overrun detector, and so on. In C, it is fairly easy
to implement a custom memory allocator (e.g., reim-
plementation of malloc in Unix) using sbrk and/or
mmap. As shown in Fig. 1, sbrk is a system call in
Unix to allocate memory by moving down the bottom
of heap (called the break position). malloc is imple-
mented, considering the following requirements:
To avoid system call’s overhead, the number of
sbrk calls should be reduced. malloc achieves
this by allocating a large memory block with one
sbrk call, and dividing it into several memory
Why Do We Need the C language in Programming Courses?
Figure 2: Inaccessible memory area detects buffer overrun.
Listing 3: Outline of buffer overrun detector.
1 void *ef_malloc (size_t size) {
2 void *p, *p2;
3 size_t size2 = ROUNDUP_PAGE (size);
4 p = mmap (size2, PROT_WRITE|PROT_READ);
5 p2 = p + size2 - PAGE_SIZE;
6 mprotect (p2, PAGE_SIZE, PROT_NONE);
7 return p + size2 - PAGE_SIZE - size;
8 }
To achieve high-speed memory management,
malloc manages the memory buckets using the
data structure like hash or balanced tree.
So the outline of a custom memory allocator be-
comes like Listing 2. Thus, students see how two ab-
straction layers (malloc and sbrk) are bridged with
actual running code in C. On the other hand, it is dif-
ficult in Java, since the API corresponds to sbrk is
not provided in Java, and if provided, it is difficult to
replace Java’s new with the custom memory allocator.
By extending this custom memory allocator in C,
it is also fairly easy to implement a garbage collec-
tor, and buffer overrun detector. For example, Fig. 2
shows the idea of Electric Fence, which is one of the
buffer overrun detectors, where two pages are used
at least; the last page is used to protect invalid read/-
write (inaccessible area), and the other pages are used
for the user (used area). In actual implementation,
mmap is used to allocate memory on continuous pa-
ges, and mprotect is used to prohibit read/write on
the last page (Listing 3). If a read/write is attemp-
ted to the inaccessible area as a result of buffer over-
run, it is notified as a signal delivery like SIGSEGV.
Thus the students understand how the memory mana-
gement works using actual running code in C, while it
is difficult in Java, since mmap and mprotect are not
available in Java.
3.2 System Calls v.s. Function Calls
In system programming, it is essential for the stu-
dents to understand the difference between a library
function call and a system call (Fig. 3). Both of li-
brary functions (e.g., printf) and system calls (e.g.,
int main ()
{ printf (...);}
int printf ()
{ write (...); }
int write ()
{ .... }
Figure 3: a library function is called with call, while a
system call is called with int in x86-32.
Listing 4: The difference between library function and sy-
stem call can be seen in the compiled assembly code.
1 % cat foo.c
2 int main (void)
3 {
4 printf ("1\n");
5 write (1, "2\n", 2);
6 }
7 % gcc -S foo.c; cat foo.s
8 ...
9 call printf
10 ...
11 int 0x80 // write
write) have the same interface to programmers in the
sense that programmers can call both of them as a
function call in C (e.g., printf(); and write();).
The reason why the difference is essential is because
a library function is executed in the user space, while
a system call is executed in the kernel space. All sy-
stem calls are implemented inside the kernel, since
they requires the CPU privilege, or some arbitration
in the kernel (e.g., to avoid data races in the shared
data among all processes).
The easiest way for the students to see the diffe-
rence is to see the assembly code compiled from C
(Listing 4)
. This method using C is easy and straig-
htforward for students, but not in Java, since we can-
not see the difference in the Java bytecode compiled
from Java.
3.3 Setting a Breakpoint in Debuggers
Suppose a system programming course where stu-
dents implement a simple debugger which natively
runs on their PCs. A key feature of debuggers is a
breakpoint, and a typical way to implement (software)
breakpoints is to overwrite the instruction at the bre-
In the recent Unix(-like) OSes, a system call is wrap-
ped as a library function. In this case, we need to use, for
example, process monitor tools like ltrace and strace in
ICSOFT 2018 - 13th International Conference on Software Technologies
55 pushl %ebp
89 e5 movl %esp, %ebp
83 ec 08 subl $8, %esp
55 pushl %ebp
cc e5 int3
83 ec 08 subl $8, %esp
Sets a breakpoint by overwriting
the top byte of "movl" instruction
Figure 4: Setting a breakpoint on x86-32.
Listing 5: int3 transfers the control to the debugger.
1 % lldb ./a.out
2 (lldb) run
3 Process 7445 stopped
4 2 int main ()
5 3 {
6 4 printf ("1\n");
7 -> 5 asm ("int3");
8 6 printf ("2\n");
9 7 }
akpoint address with a software interrupt instruction
In x86-32, for example, we can set a breakpoint to
overwrite the top byte of instruction (movl in Fig. 4)
with the software interrupt instruction int3 (0xCC in
hex). The students easily see int3 transfers the con-
trol to the debugger using inline assembly code like
Listing 5.
Most Unix(-like) OSes (e.g., Linux) provide an
process file system API (procfs) to allow program-
mers to access the debuggee’s memory address space
as file I/O. So the C code to set a breakpoint beco-
mes like Listing 6, where first the byte at the break-
point address (addr) is saved to orig, and then int3
instruction (0xCC) is overwritten. Thus, the students
easily understand how the breakpoint works in C.
On the other hand, it is not easy for students to un-
derstand it in Java, since the notion of software inter-
ruption (int3 in x86-32) is completely hidden under
the Java API. The Java Virtual Machine Tool Interface
(JVM TI) provides a debugger interface including the
following method to set a breakpoint.
jvmtiError SetBreakpoint (jvmtiEnv* env,
jmethodID method, jlocation location);
But the students cannot see the inside of the Java
method SetBreakpoint as Java code, since it is im-
plemented in C using Java Native Interface (JNI).
Listing 6: Setting a breakpoint in C.
1 void
2 set breakpoint ( int fd , void addr , char orig )
3 {
4 char int3 = 0xCC;
5 ll seek (fd , addr , SEEK SET) ;
6 read ( fd , orig , siz eof ( orig ) ) ;
7 ll seek (fd , addr , SEEK SET) ;
8 write ( fd , &int3 , sizeo f ( i nt3 ) ) ;
9 }
3.4 Direct Memory Access (DMA) in
In the above discussion through Sec. 3.1 to Sec. 3.3,
all example code runs in the user space. The same
discussion holds for the code that runs in the kernel
space. For example, Listing 7 is actual C code that
sets up the DMA controller (Intel 8237) to transfer
data between an I/O device (typically HDD) and me-
mory without CPU. The textbooks of operating sys-
tems just explain how to do DMA transfer like the
following simple description.
1. The kernel sets up the I/O device in DMA mode.
2. The kernel instructs the DMA controller to trans-
fer data in DMA mode with the specified address,
size and the transfer direction (i.e., read or write).
The code example in Listing 7 does this step in
PC/AT compatibles.
3. The DMA controller transfers the data.
4. When the transfer is finished, the DMA controller
interrupts CPU to signal transfer completion.
But the students cannot understand concretely
how DMA works with the above simple description,
since the API of the DMA controller and the code
using the API are not offered. Using the actual run-
ning code example like Listing 7, the students can un-
derstand DMA more concretely:
The whole actual running code is not long as
shown in Listing 7, although each byte of address,
for example, needs to be transferred separately.
Five I/O registers
(DMAC clear byte point flipflop,
DMAC base addr reg 2, DMAC page reg 2,
DMAC base count reg 2, DMAC mode reg) are
used in this setup, which are the APIs of the
DMA controller.
During this setup, the DMA must be disabled.
For lack of space, the detailed mechanism is omitted
Why Do We Need the C language in Programming Courses?
Listing 7: Setting up the DMA controller.
1 void
2 outb (uint8_t value, uint16_t port) {
3 asm volatile ("outb %0,%1"::"a"(value),"Nd"(port));
4 }
6 static void
7 setup_DMAC (uint32_t physical_addr, int count, int is_read) {
8 // disable DMA2 (mask set for DMA2)
9 outb (0x06, DMAC_channel_mask_reg); // STCL=1, SEL1:SEL0=2
11 /
set address and counter
12 outb (0xFF, DMAC_clear_byte_point_flipflop);
13 outb (physical_addr & 0xFF, DMAC_base_addr_reg_2);
14 outb (physical_addr >> 8 & 0xFF, DMAC_base_addr_reg_2);
15 outb (physical_addr >> 16 & 0xFF, DMAC_page_reg_2);
16 count--;
17 outb (count & 0xFF, DMAC_base_count_reg_2);
18 outb (count >> 8 & 0xFF, DMAC_base_count_reg_2);
20 /
set mode
21 if (is_read) {
22 outb (0x46, DMAC_mode_reg); // single, inc, noauto, write (I/O device -> memory), DMA2
23 } else {
24 outb (0x4A, DMAC_mode_reg); // single, inc, noauto, read (memory -> I/O device), DMA2
25 }
27 // enable DMA2 (mask clear for DMA2)
28 outb (0x02, DMAC_channel_mask_reg); // STCL=0, SEL1:SEL0=2
29 }
4.1 The C Language is Worth Teaching
Our main position is that the C language is worth tea-
ching since C is required to teach upper-class cour-
ses like embedded/system programming and opera-
ting systems. The C language does not have to be a
first programming language, but it still be needed for
the upper-class courses.
The C language may not be the best first lan-
guage in introductory courses themselves, espe-
cially just for teaching algorithms, or the funda-
mental concepts of programming languages like
conditional branches, loops, variable assignments,
(recursive) procedure calls, and so on. This is
mainly due to C’s weakness of compile-time/runt-
time checking, and the ambiguity of the C stan-
dards (e.g., the evaluation order of the subex-
pressions within an expression is unspecified in
Nevertheless, the C language is worth teaching in
programming courses, since C is very required to
teach upper-class courses like embedded/system
programming and operating systems, as shown in
Sec. 3. Furthermore, not only real operating sys-
tems, but also educational operating systems boot-
able in PC/AT compatibles like Xv6 (Cox et al.,
2006) and udos (Gondow and Ohba, 2007) are
written in C (and little assembly code). This is
also supported by the survey analysis in (Gaspar
et al., 2007).
Native educational compilers (i.e., compilers that
generate native assembly code like x86-32) have
many practical and pedagogical advantages (Gon-
dow, et al., 2010), since;
Generating native (i.e., real) assembly code
motivates students to learn.
Students are getting better to read assembly
code emitted by commercial-level compilers
(e.g., GCC).
There are many high quality documents like
(Intel, 2017) and tools (eg., GCC and GNU Bi-
nutils) for real machines.
Library functions (eg., printf in the C stan-
dard library) can be directly called from the
source program to be compiled, which widens
the expressiveness of the source program.
The C language or its moderate subset is a good
candidate of the source program to be compiled in
such native educational compilers, since the map-
ping between C and assembly code is quite simple
and straightforward.
C is worth teaching in other reasons:
C is needed to learn low-level security issues
ICSOFT 2018 - 13th International Conference on Software Technologies
like buffer overruns and the techniques to solve
C is also needed to read open source code like
Linux, Apache, TCP/IP protocol stacks, to le-
arn a wide variety of programming techniques.
4.2 Every Language Has Its Drawbacks
and Pitfalls
Another position of ours is as follows. As mentio-
ned in Sec. 2.1 and in (Koenig, 1989), C has some
drawbacks and pitfalls, but this cannot be a reason
to stop teaching C, since they are tightly coupled to
C’s advantages, and C is very required in upper-level
courses like embedded/system programming and ope-
rating systems.
Similarly, other languages have their draw-
backs and pitfalls, e.g., Java (Biddle and Tempero,
1998)(Daconta et al., 2003), Python (Miller and
Settle, 2016), JavaScript (Alimadadi, et al., 2016).
The C language is still one of the important program-
ming languages both in development and in educa-
tion, so there are several research studies to support C
programming educations to compensate the C’s draw-
backs and pitfalls. This position paper argued that the
C language is worth teaching even though C has the
drawbacks like buffer overruns and mysterious com-
piler error messages.
Our future work is to create a better C language
while preserving the C’s advantages. The languages
like C++, Java, Objective-C, C#, Go failed to be a
better C in our observation.
Ritchie, D. (1993). The development of the C language.
2nd ACM SIGPLAN conf. on History of programming
languages (HOPL-II) pp.201-208.
Programming languages–C: ISO/IEC 9899:1990,
9899:1999, 9899:2011 (C90/C99/C11).
TIOBE programming community index. (2017).
http://www.tiobe.com/tiobe-index/, [Online; accessed
Gaspar, A., Boyer, N. and Ejnioui, A. (2007). Role of the C
language in current computing curricula part 1: survey
analysis. J. Comput. Sci. Coll. 23, 2, 120-127.
Gilberg, R. and Forouzan, B. (1996). Comparison of stu-
dent success in Pascal and C-language curriculums.
Proc. 27th SIGCSE tech. sympo. on Computer science
education (SIGCSE ’96) pp.252-255.
Hosch, F. (1996). Java as a first language: an evaluation.
SIGCSE Bull. 28, 3. pp.45-50.
King, K. (1997). The case for Java as a first language. Proc.
35th Annual Southeast Regional Conf. (ACM-SE 35).
Sanders, I. and Langford, S. (2008). Students’ percepti-
ons of python as a first programming language at wits.
SIGCSE Bull. 40, 3. pp.365-365.
Bates, B. (2004). C# as a first language: a comparison with
C++. J. Comput. Sci. Coll. 19, 3. pp.89-95.
Kaplan, R. (2010). Choosing a first programming language.
Proc. conf. on Information technology education (SI-
GITE ’10). pp.163-164.
Mannila, L. and Raadt, M. (2006). An objective comparison
of languages for teaching introductory programming.
Proc. 6th Baltic Sea conf. on Computing education re-
search: Koli Calling 2006. pp.32-37.
Bosse, Y. and Gerosa, M. (2017). Why is programming so
difficult to learn?: Patterns of Difficulties Related to
Programming Learning Mid-Stage. SIGSOFT Softw.
Eng. Notes 41, 6. pp.1-6.
Biddle, R. and Tempero, E. (1998). Java pitfalls for begin-
ners. SIGCSE Bull. 30, 2. pp.48-52.
Miller, C. and Settle, A. (2016). Some Trouble with Trans-
parency: An Analysis of Student Errors with Object-
oriented Python. Proc. ACM Conf. Int. Computing
Education Research (ICER ’16). pp.133-141.
Alimadadi, S. Mesbah, A. and Pattabiraman, K. (2016).
Understanding asynchronous interactions in full-stack
JavaScript. Proc. Int. Conf. on Software Engineering
(ICSE’16). pp.1169-1180.
Freund, S. N. and Roberts, E. S. (1996). Thetis: An ansi c
programming environment designed for introductory
use. In Proceedings of the Twenty-seventh SIGCSE
Technical Symposium on Computer Science Educa-
tion, SIGCSE ’96, pages 300–304, New York, NY,
Song, J. S., Hahn, S. H., Tak, K. Y., and Kim, J. H. (1997).
An intelligent tutoring system for introductory c lan-
guage course. Comput. Educ., 28(2):93–102.
Osuka, T., Kobayashi, T., Atsumi, N., Mase, J., Yama-
moto, S., Suzumura, N., and Agusa, K. (2012). CX-
checker: A flexibly customizable coding checker for
C. Journal of Information Processing Society of Ja-
pan, 53(2):590–600.
Kummerfeld, S. K. and Kay, J. (2003). The neglected battle
fields of syntax errors. In Proceedings of the Fifth Au-
stralasian Conference on Computing Education - Vo-
lume 20, ACE ’03, pages 105–111, Darlinghurst, Au-
stralia, Australia. Australian Computer Society, Inc.
Kojima, Y. Arahori, Y., Gondow, K. (2015). Investigating
the Difficulty of Commercial-level Compiler Warning
Messages for Novice Programmers. 7th Int. Conf.
on Computer Supported Education (CSEDU 2015).
Uchida, K. and Gondow, K. (2016). C-Helper: C Latent-
error Static/Heuristic Checker for Novice Program-
mers. 8th Int. Conf. on Computer Supported Educa-
tion (CSEDU 2016). pp.321–329.
Why Do We Need the C language in Programming Courses?
Gondow, K. Fukuyasu, N. and Arahori, Y. (2010). Mie-
ruCompiler: Integrated Visualization Tool with “Ho-
rizontal Slicing” for Educational Compilers. 41st
ACM Technical Sympo. on Computer Science Educa-
tion (SIGCSE 2010). pp.7–11.
Gondow, K. and Ohba, M. (2007). Design and imple-
mentation of compact educational operating system
udos by practice of middle-level abstraction, hhin
middle layers and traceability. The Transactions of
the Institute of Electronics, Information and Commu-
nication Engineers. J90-D[5], pp.1194-1208. (In Ja-
panese) http://www.sde.cs.titech.ac.jp/gondow/udos
[Online; accessed 31-Jan-2017].
Cox, R. Kaashoek, F. and Morris, R. (2006). Xv6,
a simple Unix-like teaching operating system.
https://pdos.csail.mit.edu/6.828/2012/xv6.html, [On-
line; accessed 31-Jan-2017].
Koenig, A. (1989). C Traps and Pitfalls. Addison-
Wesley Professional. ISBN-10: 0201179288. 160 pa-
ges. https://www.amazon.co.jp/dp/0201179288/, [On-
line; accessed 31-Jan-2017].
Daconta, M. Smith, K. Avondolio, D. and Richardson,
W. (2003). More Java Pitfalls: 50 New Time-
Saving Solutions and Workarounds. Wiley. ISBN-
10: 0471237515. 480 pages. https://www.amazon.
co.jp/dp/0471237515/, [Online; accessed 31-Jan-
Monbrea, M. (2014). Why I don’t suggest JavaScript
as a first programming language. ITworld, Jan. 9,
2014. http://www.itworld.com/article/2693386/why-
language.html, [Online; accessed 31-Jan-2017].
Guo, P. (2014). Python is now the most popular intro-
ductory teaching language at top U.S. universities.
BLOG@ACM, July 7, 2014. http://cacm.acm.org/
universities/fulltext [Online; accessed 31-Jan-2017].
Intel. (2017). Intel 64 and IA-32 Architectures Software
Developer Manuals http://www.intel.com/products/
processor/manuals/, [Online; accessed 31-Jan-2017].
TechLiebe (2014) Why to Learn C? https://techliebe.com/
why-to-learn-c/ [Accessed: 24-Nov-2017]
Noordergraaf, L. Boldyshev, K. and Rideau, F. (2015)
Assembly HOWTO, version 0.7 http://asm.
[Accessed: 24-Nov-2017]
Viswa (2014) Advantages and Disadvantages of C
Language https://tekslate.com/advantages-and-
disadvantages-of-c-language/ [Accessed: 24-Nov-
ICSOFT 2018 - 13th International Conference on Software Technologies