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%>ENGR1050 C for Engineers</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, how many numbers can exist within each type, and what are the ranges available for each type?

A program will be written that will display (to STDOUT) the size (in bytes), the lower and upper bounds of each studied type, and (as accurately as possible) display the total quantity of values possible with each 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.

=====Code=====

====Skeleton Program====
Here is the skeleton of a program you'll want to use for this project:

<code c>
/*
 * dtr0.c - A program to derive and display information
 *          for the signed and unsigned data types in C
 *
 *
 * A program by NAME for COURSENUMBER COURSENAME (SEMESTER)
 *
 * Compile with: gcc -o dtr0 dtr0.c
 * Execute with: ./dtr0
 */
 
#include <stdio.h>
 
int main()
{
    // Variables
    unsigned char uchr = 0;
    
    // Code for unsigned char
    
    // Code for signed char
    
    // Code for unsigned short int
    
    // Code for signed short int
    
    // Code for unsigned int
    
    // Code for signed int
    
    // Code for unsigned long int
    
    // Code for signed long int
    
    // Code for unsigned long long int
    
    // Code for signed long long int
 
    return(0);
}
</code>

====unsigned char code block====
Following is provided code giving you the requested information for an **unsigned char**. Study it, implement it, and adapt it as needed to the other data types:

<code c>
    // Code for unsigned char
    fprintf(stdout, "TYPE: %13s, ", "unsigned char"); // What is happening here?
    fprintf(stdout, "bytes: %lu, ", sizeof(uchr));    // Why does sizeof() need %lu?
    fprintf(stdout, "low: %hhu, ",  (uchr & 0x00));   // Why 2 zeros?
    fprintf(stdout, "high: %hhu, ", (uchr | 0xFF));   // Why 2 F's?
    uchr = uchr - 1;                                   // What does this line do?
    fprintf(stdout, "qty: %hu\n",   (uchr+1));        // What is going on here?
</code>

Note that by adapting, you'll need to declare and initialize additional variables, and you may "unroll" some of the logic here to do it in more discrete steps (in fact, it may enable you to solve a couple problems that crop up).
=====Execution=====

<cli>
lab46:~/src/c4eng/dtr0$ ./dtr0
TYPE: unsigned char, bytes: 1, low: 0, high: 255, qty: 256
TYPE:   signed char, bytes: X, low: X, high: X, qty: X
TYPE: unsigned short int, bytes: X, low: X, high: X, qty: X
TYPE:   signed short int, bytes: X, low: X, high: X, qty: X
...
lab46:~/src/c4eng/dtr0$ 
</cli>

This output includes some mock additional entries, actual values abstracted. Instead of displaying 'X', your program should display the actual values, and display a total of 10 lines, for the signed and unsigned variations of the five data types we are studying in this project.

=====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.

Also, answer the following questions:

  * What two data types appeared "the same"?
    * Why may this may be?
    * Is this universal for all systems, or just a certain subset?
  * 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 **13** in **%13s** do for us?
  * If sign was left unspecified, which state is assumed by default?
  * What are the **<nowiki>&</nowiki>** and **<nowiki>|</nowiki>** operators?
    * How did they help you achieve the solution?
  * If you experienced trouble displaying the total quantity for a certain type, why was this?
  * 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/c4eng/proj$ gcc -Wall --std=gnu99 -o hello hello.c
lab46:~/src/c4eng/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/c4eng/proj$ ./hello
Hello, World!
lab46:~/src/c4eng/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/c4eng/dtr0$ submit c4eng dtr0 dtr0.c
Submitting c4eng project "dtr0":
    -> dtr0.c(OK) 

SUCCESSFULLY SUBMITTED
lab46:~/src/c4eng/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>
52:dtr0:final tally of results (52/52)
*:dtr0:submitted file called dtr0.c [4/4]
*:dtr0:committed and pushed dtr0.c to repository [4/4]
*:dtr0:adequate and consistent indentation in dtr0.c [4/4]
*:dtr0:sufficient comments in dtr0.c [4/4]
*:dtr0:utilizes correct and best fit printf format specifiers [8/8]
*:dtr0:executable runs without issue [4/4]
*:dtr0:output is correct [8/8]
*:dtr0:output conforms to project specifications [8/8]
*:dtr0:adequate modifications in dtr0.c [4/4]
*:dtr0:no compiler warnings nor errors for dtr0.c [4/4]
</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
Lab46 Wiki

User Tools

Site Tools

Page Tools
