Lab46 Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
<WRAP centeralign round box>
<WRAP><color red><fs 200%>Corning Community College</fs></color></WRAP>
<WRAP><fs 150%>CSCS1320 C/C++ Programming</fs></WRAP>
</WRAP>

======Project: DATA TYPE RANGES (dtr0)======

=====Objective=====
To familiarize yourself with the available data types in C- the variations, the attributes, the ranges therein.

=====Prerequisites=====
In order to successfully accomplish/perform this project, the listed resources/experiences need to be consulted/achieved:

  * ability to log into Lab46
  * ability to change to course-specific source directory
  * ability to edit text files
  * ability to compile C source code
  * ability to read and appropriately react to compiler messages during compilation
  * ability to execute compiled code
  * knowledge of the size of a byte, how many bit combinations are possible therein
  * ability to use version control system to track created source file(s)

=====Scope=====
This project will be exploring the nature of some of the data types available to us in the C Programming Language. How much space is allocated to each type, and what are the ranges available for each type?

A program is provided that will display (to STDOUT) the size (in bytes), the lower and upper bounds of each studied type.

The data types covered for this project will include **signed** and **unsigned** variations of:

  * char
  * short int
  * int
  * long int
  * long long int

The **sizeof()** and **printf()** functions, as well as arithmetic and logical operators, will be utilized in performing much of the work.

=====Grabbing project resources=====
I have prepared a **grabit** for resources related to this project. To obtain:

<cli>
lab46:~/src/cprog$ grabit cprog dtr0
make: Entering directory '/var/public/SEMESTER/cprog/dtr0'
'/var/public/SEMESTER/cprog/dtr0/Makefile' -> '/home/wedge/src/cprog/dtr0/Makefile'
'/var/public/SEMESTER/cprog/dtr0/dtr0.c' -> '/home/wedge/src/cprog/dtr0/dtr0.c'
make: Leaving directory '/var/public/SEMESTER/cprog/dtr0'
lab46:~/src/cprog$ 
</cli>

At which point you can change into the newly created and populated **dtr0** directory.

Please study the **dtr0.c** program, and look up or ask questions on aspects that you do not understand.

Compile it.
=====Execution=====

<cli>
lab46:~/src/cprog/dtr0$ ./dtr0
</cli>

=====Reflection=====
Be sure to provide any commentary on your journal regarding realizations had and discoveries made during your pursuit of this project. You should also consider adding extra comments into your program so that it can be a more valuable reference going forward.

=====Your task=====
You are to create a text file, called "**dtr0.text**" that you will submit for this project. It will contain your well-thought-out responses to the following questions:

  * What two data types appeared "the same"?
    * Why is this the case?
  * With respect to **printf()**:
    * What is the difference between **printf()** and **fprintf()**?
    * What is **stdout**? Where is it by default?
    * What is the difference between **%s**, **%hhu**, **%hu**?
    * How about **%u** and **%d**?
    * What does the **22** in **%22s** do for us?
  * If sign was left unspecified, which state is assumed by default?
  * What are the **<nowiki>&</nowiki>** and **<nowiki>|</nowiki>** operators?
    * What are they doing to enable the display of the output?
  * Based on your program's output, what are the total **bits** allocated for:
    * signed char
    * unsigned short int
    * unsigned int
    * signed int
    * signed long long int

=====Review of Compiling/Executing=====
Just to review the compilation/execution process for working with your source code, if we had a file, **hello.c**, that we wished to compile to a binary called **hello**, we'd first want to compile the code, as follows:

<cli>
lab46:~/src/cprog/proj$ gcc -Wall --std=gnu99 -o hello hello.c
lab46:~/src/cprog/proj$ 
</cli>

Assuming there are no syntax errors or warnings, and everything compiled correctly, you should just get your prompt back. In the event of problems, the compiler will be sure to tell you about them.

Conceptually, the arrangement is as follows:

<code>
gcc -Wall --std=gnu99 -o BINARY_FILE SOURCE_FILE
</code>

The BINARY_FILE comes **immediately after** the **-o**, **NOT** the SOURCE_FILE (it must never **immediately** follow a **-o**). It can precede, and such is perfectly valid (especially if you feel that way more intuitive).

The **-Wall** (treat all warnings as errors, increase general verbosity about warnings) and **--std=gnu99** (switch compiler to use the **C99** standard of the C language with GNU compiler extensions) are options given to the compiler.

To execute your binary, we need to specify a path to it, so we use **./**, which references the current directory (the dot '.' tells the computer "my current location", and the forward slash '/' is the directory separator):

<cli>
lab46:~/src/cprog/proj$ ./hello
Hello, World!
lab46:~/src/cprog/proj$ 
</cli>

=====Submission Criteria=====
To be successful in this project, the following criteria must be met:

  * Project must be submit on time, by the posted deadline to be eligible for full credit.
    * Late submissions will lose 25% credit per day, with the submission window closing on the 4th day following the deadline.
    * Early submissions can earn 1 bonus point per day in advance of the posted due date.
  * All code must compile cleanly (no warnings or errors)
    * Use the **-Wall** and **--std=gnu99** flags when compiling.
    * all requested functions must be implemented in the related library or program
    * all requested functionality must conform to stated requirements (either on this project page or in comment banner in source code files themselves).
  * Executed programs must display in a manner similar to provided output
    * output formatted, where applicable, must match that of project requirements
  * Processing must be correct based on input given and output requested
  * Output, if applicable, must be correct based on values input
  * Code must be nicely and consistently indented (you may use the **indent** tool)
  * Code must be commented
    * Any "to be implemented" comments **MUST** be removed
      * these "to be implemented" comments, if still present at evaluation time, will result in points being deducted.
    * Sufficient comments explaining the point of provided logic **MUST** be present
  * Track/version the source code in a repository
  * Submit a copy of your source code to me using the **submit** tool by the deadline.
  * Make sure your submitted source code is in a file called **dtr0.c**
  * Make sure it outputs exactly like the sample output above.

====Submit Tool Usage====
Let's say you have completed work on the project, and are ready to submit, you would do the following:

<cli>
lab46:~/src/cprog/dtr0$ submit cprog dtr0 dtr0.text
Submitting cprog project "dtr0":
    -> dtr0.text(OK) 

SUCCESSFULLY SUBMITTED
lab46:~/src/cprog/dtr0$ 
</cli>

You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches.

I'll be evaluating the project based on the following criteria:

<code>
13:dtr0:final tally of results (13/13)
*:dtr0:submitted file called dtr0.text [4/4]
*:dtr0:committed and pushed dtr0.c and dtr0.text to repo [4/4]
*:dtr0:sufficient info in dtr0.text [5/5]
</code>

Additionally:
  * Solutions not abiding by spirit of project will be subject to a 25% overall deduction
  * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
  * Solutions not utilizing indentation to promote scope and clarity will be subject to a 25% overall deduction
  * Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction