Cross Codes Blog

Blog home

Programming key terms set 2

30 December 2018 | Concepts

Agile scrum - iterative approach in project management consisting of interval sprints followed by milestones to be demoed; flexible when requirements change
Adapter pattern - a software pattern that allows the interface of one class to be used as another interface
Assembler - a program that translates assembly code to machine code
Auto - reserved word in C++ that implies type during compilation; implicit with local variable declarations and initializations
Automation - using scripts or programs to make simple tasks in software projects automatic and standard
Behavior driven development - follows test driven development rules but addresses behavior over implementation
Compiled language - programming language required to be translated into executable file to run program
Compiler - converts source file to corresponding assembly instructions and taxonomizes program into object files
CRUD - used in backend and database management applications; stands for create, remove, update, delete
Decorator pattern - allows for the modifications of the behaviors in a derived class without affecting those of the parent class
Design pattern - types of software architecture styles and paradigms to adhere to corresponding to the type of application being programmed
DNS - hierarchical naming system for places within a network
Extern - lets compiler know that a variable in one file will be used in another in C++
Facade pattern - consisting of an interface that acts in the frontend of communicating between a client and a complicated cascade of functions in the backend
Factory pattern - an object that produces other varying objects
Firewall - network security monitor that either grants or denies access for requests in networked communications
FTP - protocol used over a network to transfer files remotely known as file transfer protocol
Generic - the Java equivalent of C++ templates allowing varying types and objects to be contained
Interpreted language - a language where its source is runnable by an interpreter executing instructions that corresponds to a line of code; executed explicitly line by line
IPv4 - 32-bit IP address displayed in decimals where each byte is separated by '.'
IPv6 - 128-bit IP address used to address limited number of addresses in IPv4; displayed in hexadecimal
LAN - local area network used within a limited space
Linker - a program that takes the object files resulting from the compiler and translates them into a single binary runnable file
Port - numerical node of communication within a networked system
Proxy - a mediator that handles operations between a client and a server
RAIL - principle used in making responsive and user-deemed fast web/ mobile applications; what to make responsive includes response, animation, idle, load
REST - an API used in web development to support functions in the HTTP protocol
Router - a networking device that forwards packets in a predetermined network route
Samba - secure protocol that offers file and print services
Script - source file typically interpreted to automate simple tasks
Singleton class - a class where only one instance can exist in an execution; typically implemented with a private constructor and static datafield
SSH - secure shell protocol used to login to UNIX/ Linux servers
Test driven development - process of writing test code concurrently or before the application is written
Tunneling - protocol in a networked system that allows movement of data providing the purpose of the network
Version control - software that taxonomizes versions of software projects including builds and releases
Volatile - reserved word in C++ that prevents compiler optimization on a variable declaration or initialization
Waterfall model - linear approach to projects from start to finish involving requirements, design, implementation, verification, maintenance
Unit test - test code used to test a block of code in a software project
UX/DX seesaw - in web development, the user and developer experiences are inversely proportional and described by a seesaw

Introduction to smart pointers

18 December 2018 | Engineering

"Dynamic allocation is frowned upon!" This was an interesting statement I was told at work. I spent four years in UCSD learning strictly about dynamic allocation as if it's a vital skill to harness in the work force. This actually is the case but more importantly, for the purpose of understanding memory management behind the scenes in C++ without taking it for granted. Given the possible array of errors that can arise from dynamic allocation such as memory leaks, dangling pointers, and page faults, there is a way to avoid this given the level and size of programming in the industry. Shortening one's subset of contingent errors will prove to be useful anywhere. I am talking specifically about smart pointers, an abstraction in C++ that contains all the black boxes for traditional pointers easing the programmer from having to explicitly manage them in order to prevent errors. The following are some problematic examples of using traditional pointers:
/* If the call to function results in an exception, a double delete would lead to a heap corruption error. */
ptr * foo1 = new ptr();
delete foo1;

/* Assigning the value of i results into a page fault since a pointee wasn't assigned. */
int * i;
*i = 1;

/* If the call to my_error is true, foo would become a dangling pointer causing the call to function to result into a page fault. Otherwise, foo2 would not be deleted causing a memory leak. */
ptr * foo2 = new ptr();

if(my_error()) {
   delete foo2;


In industry level programs, the possibility of the above errors become such a nuisance when debugging. Smart pointers remove the need for explicitly managing pointers thereby, preventing any of the above scenarios and others. The two types of basic smart pointers are unique_ptr and shared_ptr. As the names suggests, the former is used to limit the number of pointers to one whereas the latter will allow multiple copies to exists. Which pointer you decide to use depends on whether you want to limit or extend the scope or implement a singleton instance of an object. To use these pointers, simply declare one using a smart pointer type along with a template to specify what type or object to point to. To initialize, explicitly call the appropriate constructor on the declaration. Example below:
#include <memory> /* Include this header file to use smart pointers */

int main() {
   /* A smart pointer to an int with value 1 is created. */
   std :: unique_ptr<int> i(new int(1));
   return 0;
/* Note: A shared_ptr (same syntax) is ideal for a field; the errors mentioned above are implicitly taken care of. */

Here is the documentation for C++ smart pointers.

Programming key terms set 1

13 December 2018 | Concepts

Abstract Class - a class that cannot be instantiated; class can optionally contain implementations but must be derived in order to use its fields and functions
Array - a container of predetermined size that cannot change once instantiated; elements of container are indexed
Arraylist - indexed like an array but can grow or shrink once initialized
CI Pipeline - a defined sequence of steps in continuous integration for software development aided with scripts to automate the process
Class - typically contains functions and data fields; private access by default; allocated on the heap; supports inheritance and polymorphism
Condition Variable - variables used in monitors to serve as conditions for determining which thread to give priority to
Constructor - class method used to allocate memory for an instance of the class; default constructor with no parameters is implicit in all classes
Deadlock - a state in concurrent programming where no thread or process can be given access to the CPU due to any of the 4 conditions
   Mutual Exclusion - at least one thread or process is locked out from using the
   CPU due to not meeting priority
   Hold and Wait - at least one process or thread is waiting for CPU access but is
   being blocked because the CPU has been requested by another thread or process
   Circular Wait - there exists a process P1 attempting to access the CPU waiting
   for process P2 whom is also waiting for P1
   No Preemption - CPU access cannot be preempted so tasks must finish completely
   before another thread or process accesses the CPU
Destructor - method in class that deallocates memory if an instance of the class is allocated in the heap and needs to go out of scope; no parameters and default destructors are implicit in all classes; must be implemented if constructor allocates memory on the heap to avoid memory leak
Dynamic - memory allocated in the heap that can grow or shrink indefinitely
Hash Map - unique values are mapped by unique keys; indexing used
Hash Set - sets are mapped by unique keys; indexing used to access first element in a set within the hash set
Hash Table - a hashcode algorithm is performed to store values in indeces; supports collisions caused by common hash value and duplicate insert
Interface - cannot be instantiated; contains only method signatures; must be implemented for use; multiple interfaces can be implemented
Linked List - dynamically allocated linear structure not relying on indexing
Memory - there are four sections of memory
   Text - contains text of instructions for the executable such as if statements, loops,
   classes, etc.
   Data - contains virtual addresses corresponding to the program as well as global
   variables and static fields
   Heap - contains dynamically allocated variables and instances of objects
   Stack - contains functions, arguments, and local variables in a LIFO container
   where a stack frame is popped off and out of scope when a function returns;
   each frame corresponds to a function
Monitor - concurrent synchronization construct for concurrent programming relying on condition variable to allow a producer and consumer to modify a buffer
Mutex - a mutual exclusion object that serves to lock and unlock concurrent processes and threads to and from the CPU to prevent data race in what is determined to be the critical section in the program
MVC - model view controller design pattern; separates visual components(view), logic to initiate interaction(model), and what events to listen for to execute an interactive process(controller); typically used in but not limited to web applications
Object - an instance of a class containing variables as data fields and access to the functions to either modify or access a field in the class; found in the heap
Object Oriented Programming - programming paradigm involving the idea of separating modules into objects based on related functionality; objects contain data fields and functions to access or modify their fields; object reference creates instance of class when instantiating; there are "four pillars to object oriented programming"
   Encapsulation - hiding details of data fields from other classes
   Abstraction - showing essential features of an application but preventing direct
   access to its data fields (includes encapsulation)
   Inheritance - extending the parent or base class to a child or derived class used
   that has access to the base class's functions and fields;
   for recycling code
   Polymorphism - allows the ability to overload and override functions
Pass by Reference - the argument passed to the caller is the same (referred) variable as the parameter of the callee
Pass by Value - the argument passed to the caller is a copy of the parameter of the callee; the parameter goes out of scope when the function returns
Process - an instance of execution of concurrent executions that do not share addresses nor registers
Round Robin - a preemptive scheduling algorithm that assigns sections of a thread or process priority to use the CPU
SDLC - stands for software development life cycle, a set of stages in the software development process for a particular project starting from requirements and ending to release
Semaphore - a concurrency mechanism that relies on a counter to either signal a process, or let it wait; changes between wait to signal depend on whether the counter has fully decremented to 0
Static - fixed size allocation of memory in the data section of memory; global in scope; function or field that is static must be called without instance of an object
Template - a container that assigns an arbitrary primitive and/or object for a class or struct to implement
Thread - a unit of a process that shares addresses and registers of another thread within the same process
Virtual Function - a function defined in a base class to be redefined in a derived class; explicitly referring to a virtual function executes the derived class's function
Virtual Memory - abstracted memory mapped to limited physical memory to give user the illusion of a large amount of memory; quantified by number of addresses; less physical addresses, more virtual addresses
Void Pointer - a pointer to anything; cannot be dereferenced; can be used in place of templates to implement polymorphic generic containers

Compiling C++ templates

26 November 2018 | Engineering

Styling conventions in C/C++ generally separate function definitions/ class templates and their implementations. Although clean in nature, this convention poses a problem with templates. Interestingly, I was told by my data structures professor that templated classes require implementations to be defined in the header files, a contradiction of the convention I previously mentioned. It is also interesting to note that this professor would agree with the said convention. Why was this a problem with templated classes? Do templated classes necessarily have to go against this styling convention in order to compile? The simple answer is no. Templated classes can still follow best practices in code organization remaining consistent with non-templated classes. My professor's claim that implementing templated classes in the header file is therefore inaccurate. The problem has to do with the compiler not knowing how to interpret what to pass into the template. At compile time, the type(s) that are expected to be passed into the template need to be defined. For objects, operators would need to be overloaded and their classes would need to be implemented in order for the template to know how to use them.

/* A generic templated class */
template<typename type>
class some_class
      type some_variable;

      some_class(type some_variable)
         this->some_variable = some_variable;

some_class<int> foo = new some_class<int>(1);

/* At compile time, the above line causes the compiler to create an untemplated instance of the templated class based on what was passed in as a template argument as shown below. */
class some_class
      int some_variable;

      some_class(int some_variable)
         this->some_variable = some_variable;

When the code compiles, the compiler would need access to the implementation at the time the function definition is read. If this is not defined in the header file, the compiler would not have access in knowing the types of classes that would need to be created thus, lead to a "function undefined" compiler error. However, it is possible to isolate the implementation from the header files of templated classes in order to maintain code cleanliness. There are two solutions.

/* Include the .cpp file at the END of the header file */
#include "some_class.cpp"

/* Or explicitly define the expected types for the template at the end of the .cpp file */
template class some_class<int>;
/* Explicitly define the rest of the types and/or objects below */

Computer Science major classes

12 November 2018 | Experience

In general, there's a set of common classes to take among any university for a bachelor's degree in computer science. One should definitely expect the following set of math classes:

Calculus I: fundamental theory of calculus involving limit definitions of differentiation and integration
Calculus II: advanced integration techniques; sequences and series to solve mathematical expressions; polar graphing
Calculus III: application of Calculus I in 3-dimensional space, equation systems, and vectors
Differential Equations: advanced differentiation techniques involving slope fields and equation systems
Statistics: data set analysis involving function modeling
Linear Algebra: analysis of variable dimensional space with equation systems, vectors, and matrices
Discrete Mathematics: analysis of advanced algebraic techniques and introduction to number theory and mathematics for systems

Since computer science involves a highly systematic way of thinking, these math classes are chosen for to curriculum to train one's mindset into the proper conventional thought process for systems as well as the possibility of applying mathematical theory to solving any problems that can be encountered in the field of computation. The next set of following classes involve the typical order and content to expect when studying for a computer science degree:

Introduction to UNIX-like Systems: basic UNIX command semantics and use of a CLI
Introduction to Programming and OOD: basic programming features and applications of object oriented design practice for code readability
Data Structures: applied object oriented design in implementing data storage and retrieval algorithms and common computational problems
Mathematical Theory for Systems: logical mathematics for use in computer systems and introduction proof design and analysis of mathematical problems
Algorithm Design and Analysis: paradigms for algorithm design to solve computational problems and time complexity analysis with correctness proofs
Computer Organization: low level assembly programming, hardware analysis, C programming and pointer use
Computer Architecture: VDHL implementation of CPU's and analysis; memory management; instruction set architecture
Software Engineering: industry practices in software engineering involving customer communication, design patterns, development models, automation, and development tools
Operating Systems: concurrent programming with synchronization mechanisms and OS constructs involving kernels, file systems, BIOS, memory management, and low level system analysis
Programming Paradigms: varying programming styles involving functional, logical, scripting, and specific programming languages and analysis

By the time this major is finished, one should know how to use a UNIX or UNIX-like system for business and development. One will be able to write code with best practices as well as implement common industry protocols for project development and team collaboration. One understands how code is translated to low level execution with respect to CPU architecture and digital design. One has a good understanding of algorithms to solve problems including but not limited to concurrent programming. One will also know multiple programming styles in addition to the traditional procedural and object oriented design paradigms. These are all the basics one must know in order to work in the industry utilizing their computer science degree. These basics should also preferably be applied to multiple specific disciplines within computer science. The following set of classes are some electives one can consider but are not limited to:

Compiler Construction: implementation of compilers (converting source code given a language semantic construct to assembly)
Relational Databases: management of data for systems and relational algebra
Web Development: development of websites, web applications, and mobile applications
GPU Architecture: physical architecture and VDHL implementations of graphics cards
Machine Learning: algorithms to train systems for accurate data outputs
Data Mining: obtaining information from unorganized data and organizing it
Cyber Security: cryptography schemes; securing systems from adversaries; known cyber attacks; security analysis; malware; hacking
Computer Networks: implementing multiple computer system communication
Embedded Systems: designing specified computerized systems
Computer Vision: computerized animation, graphics, motion pictures
Game Design: video game implementation
Computational Theory: theoretical analysis of solvable and unsolvable computational problems with theoretical models of computing

Career fair tips

6 October 2018 | Experience

Looking for a job? Trying to get your career started? Looking to expand your network, learn about new opportunities, or to get to know more companies that are looking for you? Attending a career fair is a great way to address any of the above desires. To get the most out of your career fair experience, here are 9 tips that have been explained by those who run the quarterly Triton Career Fair at UCSD:

1. Have healthy expectations
Don't expect that you will be successful with whatever top tech company is your top choice. Also understand that the more competitive companies will have longer lines that can have you waiting for over an hour. You should ask yourself if it's worth it to invest all that time waiting in line for one company rather than exploring around. In general, don't put all your eggs in one basket. You want to expand your options. The point of attending a career fair is to expand your employment opportunities in addition to meeting with employers face to face and expanding your network. Also, understand that attending career fairs does not necessarily give you a higher probability of landing a job over mass applying online. The advantage is mainly networking and educating yourself about open opportunities.

2. Bring several copies of your updated resume
It is better to have too much than too little copies of your physical resume. The last thing you want is to run out of copies with the presence of potential employers you have yet to talk to. I normally bring at least 20 copies.

3. Do your research on the companies attending
Want to know about companies you are aiming to work for? Do your research on the given list of companies attending. This also lets employers know that you are interested in them by taking the time to learn about their companies as well as give you something to talk about. When researching, it is best to start at their website. Look for the essentials; their mission statement, what they do, and who they serve. Read up on some articles to expand your research and/ or find a Wiki page or blog about them to expand your knowledge. Try to find out their technical background and process if you can as well as any soft skills and principles they value. After you learned a thing or two, figure out how you can positively impact their company with the skill set you have to offer by looking for ties in your resume and their expectations. It also helps to apply online beforehand.

4. Rank employers you want to meet
It is good practice to keep a spreadsheet ranking the companies you want to meet. Do your research and prioritize what you are personally looking for. This can include culture, type of work, company perks, benefits, salary, location, etc. Ask yourself where you would want to work and why. Obviously don't actually talk about benefits. You are not yet in the position to be negotiating your compensation when talking to the employers. Also be sure to factor in the expected amount of time you will be in line for a company.

5. Practice your elevator pitch
Usually, employers will ask you to tell them a little about yourself. Being confident shows good character and helps the employers remember you later. This confidence comes with practice. Come up with an outline of your technical background, what you are looking for, and how you can contribute, and rehearse it. Learn to communicate it effectively and confidently but be humble. Practice your flow. It doesn't take that much time to practice a 30-45 second elevator pitch.

6. Manage your time wisely
Make sure you can meet as much of your higher prioritized companies. Show up as early as possible to get as much time as you need. Some lines take over an hour of waiting. Ask yourself whether it's worth it to wait that long. A long wait can be time wasted that could've been spent talking to other companies. Also, don't spend too much time talking to one company. Be brief in explaining your highlights. Remember that employers are trying to give everyone an equal chance to talk to them. Also, taking too long with a employer can have negative consequences. They may not appreciate you taking a significant chunk of their time in addition to wasting your own time.

7. Dress for success
The dress doesn't make the person but if you can, do it. I gives the employer a sense of respectability of your character knowing that you took the time to dress well to talk to them.

8. Ask for contact information and follow up along with a "thank you"
Increase your chances of getting an interview and the employers remembering you by asking for business cards and contact information with intention to follow up a week later. Be sure to mention anything significant from the past conversation that can help you land an interview. Also, thank them for their time. It shows that you are respectable.

9. Be prepared
Have a folder handy to hold your resumes, a pen to write with (having a pen ready makes a good impression), and some paper to take important notes. Having a tablet at hand is a plus if you can use it to show the employers relevant work, perhaps your online portfolio if you have one.

Overall, be courteous, be professional, be prepared, and be humble. Make sure you are there for the right reasons.

Resume tips from an expert

3 October 2018 | Experience

This blog post is an extension of Resume tips if you have not read up on that post yet. I attended a career fair prep event where I got my resume critiqued thanks to Melissa Hoon, a UCSD Career Center staff member. In addition to my previous post on Resumes, here are some more tips from her:

- include objective with buzz words (specific type of job you're looking for + location; be brief (1 - 2 phrases), enthusiastic, and state the skills you have to offer)
    This contradicts my previous post.
    Objectives make it clear what job
    you're looking for and serve as a
    small elevator pitch to sell yourself.
    However, there's no need to go
    overboard. Conserve space for the rest
    of your content.
- make room for the content that sells you (expand margins; limit spaces and font sizes; use columns, footers, headers; etc. make it work on one page)
- communicate effectively (make your content state the impact you made rather than it being task based)
- descriptions typically start with verbs (actions) and are structured as (action making impact -> using these technical and or soft skills)
- include buzz words for soft skills; important to compliment your tech skills (leadership, communication, collaboration, etc.)
- include HOW the skills in your skill set section developed with projects
- data/ metrics are a plus; try to include concrete numerical data where applicable
- include relevant project subsection in employment section if directly relevant
- any outside work, label as "relevant experience"
- .pdf is an ideal format when including your resume to a job application (use ATS to see if it parses all your resume's text)
- format hyperlinks to make it obvious they are links
- organize sections of your resume in a way that is easy to differentiate each of them
- be consistent in how you label/ indent sections and subsections of your resume based on its structure
- prioritize top to bottom the following order (objective -> skills -> education -> work -> relevant experience etc.)

Here is the before and after of my current resume given my previous tips, and Melissa's tips respectively:



The most obvious one is that I found a way to move my skill set to the top with the use of columns. Also, listing them vertically makes it easier for a recruiter to see what all my skills are versus listing them horizontally. For the margins, they are now expanded. Hyperlinks are now noticeable. For the content, I moved some of my projects to the experience section since they are directly related to the organization. "Projects" is now labeled with "Relevant" to emphasize the urgency for a recruiter consider them. I also focused on adding more metrics and communicating the impacts I made rather than the task I did in addition to my skill applications. The added content made me have to limit spaces and font sizes. The expanded margins also helped make space. Lastly, I added a brief objective stating the line of work I am looking for with what I have to offer.

Including seperate HTML files

29 September 2018 | Web Development

It is usually good practice to create a single HTML file for a specific component that will be used by multiple HTML files. This way, HTML source can be reused and the component will only need to be edited once for reliable consistency when other HTML files refer to it. There are two ways to do this:

Your main file must include jQuery from the exact following url: A div class or id should be placed where the content of the included file will be loaded. Include a script that uses the load function from jQuery. It takes the name of the included file as an argument. The calling reference will be the div tag's id or class attribute value. Notice that in this example, the '#' character is used for the "id" attribute. Be sure to use '.' for "class".

The included file's body will be loaded to the main file's div tag attribute that called the load function.

Sometimes, jQuery doesn't work given certain frameworks as sources. W3S is an alternative choice of framework to accomplish this task. Similarly to jQuery, the body of the included file will be loaded to the main file. First off, W3S will need to be included into your source.

In order to specify where to place the components of the included file, use the "w3-include-html" attribute with the name of the included file as the value.

To get the contents to load, you need the JavaScript source to load it as well as a script to call the JavaScript.

Fianl result

Roadblocks and solutions for Solar Interact

26 September 2018 | Engineering

After a wonderful two years of balancing school, work, and side commitments, Solar Interact comes to a close; at least for its first release. With all members of the team graduated with the exception of one programmer, the final build is released and available for use at the UCSD Sustainability Resource Center. Currently, one programming student is planning to extend the product's current capabilities and continue the project for the future generation of Engineers for a Sustainable World.

During the process of coming up with our first MVP, the software team has encountered several roadblocks. The way I like to think of this experience is by the motto, "You either win, or you learn". Given these roadblocks, the team definately learned a lot about Android development until we succeeded. Below, I document the software team's roadblocks and their solutions:

1. Build failures
This problem happened everytime Google released an update for Android Studio. Typically, the solution was to update the top level gradle that the build relies on. Updates come with release notes that typically document how to update the gradle file to work with the new dev environment. This would involve updating repositories, and the class path:
buildscript {
   repositories {
      // keep these dependencies updated
   dependencies {
      // make sure the path is correct (typically the version #)
      classpath ''

allprojects {
   repositories {
      // keep these dependencies updated

2. Circular dependency
We had problems building the APK due to a circular dependency. The graphview API was responsible for this as well as myself learning how to incorporate the API into our project. There are two ways to include the API and ONLY one of them should be done:
Add the following to the dependencies block in the build.gradle file from the "app" directory:
implementation 'com.jjoe64:graphview:4.2.2'
-- or --
Clone "", select File > Import Module followed by the folder that contains the repository, and add implementation project(':GraphView') into the dependencies block.

3. Incorrect values for power outputs
Bluetooth sockets accomplish communication of data in byte buffers which are framed and parsed by character making it problematic for values with multiple digits. Logic would need to be added to ensure that every digit of an individual value is considered before being read.

4. Slow graph
The problem was from calling the AppendData(DataPoint, scrollToEnd, maxPoints, silent) function. The maxPoints parameter is the maximum number of data points a line can have. The garbage collector deletes old data points. This value was set too high causing memory bloat. There has to be a limit to how many data points can be seen on the graph. Luckily, the graph automatically scales and moves along axes for the data.

5. Bad USB cable/ port
This has always been a problem for me as an Android developer. Emulators were the solution. However, emulators do not support Bluetooth connection. We had to repeatedly build an APK and email it to the device. However, debugging was unavailable rendering us required to put print statements within the app and going through several trial an error.

6. Map crashing
The .jpg file for the map was high-res. It turned out that the device did not have enough memory to load it. To make it work for our final build, we had to lower the resolution of the image despite an HD image being a nice feature.

What's the plan now?
As I stated earlier, there are plans to extend the product's current features that the future generation of ESW members can take care of. One of our programmers is planning on adding land marks to the map as well as the ability to store business hours and let users know whether something is closed or about to close. There is also room to make the app itself more aesthetically pleasing. For the Solar Interact game, it would be nice to be able to save the top scores. I originally wanted to work on this feature but class work and graduation beat me to it.

Overall, I have learned a lot of Android development skills as well as knowledge of several API's from this project. I also learned soft skills involving leading the development cycle of software projects to ensure quality builds. Some of these soft skills involve unit testing, automation, code review, documentation, communication, and agile scrum. I plan to take note of everything I learned on the next chapter of my career as a software engineer.

View project

Ambiguous 0 value in Socket buffers

9 September 2018 | Engineering

I was tasked with working on a Socket based cloud storage application when I encountered a file I/O error. I noticed a few ASCII files being unread after certain areas in the text and binary files not being read at all. I also noticed several reading errors on Unicode text files. Knowing that the char data type in C only supports 8-bit ASCII, I believed the lack of bit space was causing the error. This was definitely the case for parsing Unicode files. However, this was irrelevant to the misread issue on ASCII encoded files. Taking care of 16-bit characters would just be a later task for me but it didn't add up to me why some files encoded with 8-bit character schemes were not being read. The issue was pointed out by a fellow senior software engineer at work. The '0' character is ambiguous. When inputting characters into my message buffers, there was no way to for a char array to tell the difference between the numerical value 0 and the null character. This explained why binary files were not being read at all and why certain characters were not being read from ASCII files. They were null characters. I learned the following lessons from this error:

1. DO NOT use char buffers when parsing files. Use the stat struct defined in the C library.
2. Use the sendfile system call to efficiently and reliably parse all file contents instead of using fgetc and fputc to parse characters at a time.

This video taught me how to use the sendfile system call.

<< < 1 2 3 4 > >>

© Copyright 2018 Jeremy Cruz