This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
haas:spring2015:cprog:projects:eocehints [2015/04/19 13:13] – [0x1: Octal] wedge | haas:spring2015:cprog:projects:eocehints [2015/04/19 20:44] (current) – [0x1: more octal] wedge | ||
---|---|---|---|
Line 13: | Line 13: | ||
If you were to convert " | If you were to convert " | ||
- | If you pass that decimal 640 to the chmod() function, you'd end up with the sticky bit being set (T in other) along with user write, and NOTHING else. Not 640 as we desire. | + | If you pass that decimal 640 to the chmod() function, you'd end up with the sticky bit being set (T in other) along with user write, and NOTHING else. Not 0640 as we desire, but instead 01200. |
So, entering 640 on the command-line would not result in a direct conversion to octal 0640... some converting will be in order. | So, entering 640 on the command-line would not result in a direct conversion to octal 0640... some converting will be in order. | ||
Line 53: | Line 53: | ||
As you can see, even if you had a 0640, the leading zero would be dropped in the conversion, because **atoi(3)** is apparently only cognizant of decimal values (and good, because that would have taken the fun out of this particular problem... you stand to learn some important things by working through this process). | As you can see, even if you had a 0640, the leading zero would be dropped in the conversion, because **atoi(3)** is apparently only cognizant of decimal values (and good, because that would have taken the fun out of this particular problem... you stand to learn some important things by working through this process). | ||
- | And also, do you see that regardless of displaying it in octal, decimal, or hex, it is the same value? They' | + | And also, do you see that regardless of displaying it in octal, decimal, or hex, it is the same value? They' |
> Why doesn' | > Why doesn' | ||
Line 63: | Line 63: | ||
You would understand because I identified it as such... note the lack of the leading zero. If I wanted to be more brief, instead of saying "the following value is in base 8" I could just prefix a 0 on, because that shortcut is generally understood (within the context of assignable values in C syntax). But it is by no means the only way to do it. | You would understand because I identified it as such... note the lack of the leading zero. If I wanted to be more brief, instead of saying "the following value is in base 8" I could just prefix a 0 on, because that shortcut is generally understood (within the context of assignable values in C syntax). But it is by no means the only way to do it. | ||
+ | |||
+ | ====atoi==== | ||
+ | And note, there is nothing magical about **atoi(3)**... it is just a function. It takes an array currently filled with ASCII-equivalents of single digit decimal numbers and coalesces those separate digits into one. We've played with things like this in our early labs this semester (there are advantages to having a number broken up into separate digits, there are also advantages to having a number combined as a single value). | ||
+ | |||
+ | The overall scope of this problem presents you with a desired-octal value currently represented as a string-- each ' | ||
+ | |||
+ | And as we know: 031 is not 31. 031 is 25. | ||
+ | |||
+ | So, if we read in 031 as a decimal 31 yet desire to then represent it as octal, we'd instead have 037. | ||
+ | |||
+ | ====the neatness of binary and octal (and hex)==== | ||
+ | There are certain advantages when working in similar bases that are all powers of two. Quite advantageous things. | ||
+ | |||
+ | That base 8 is one of those bases means this problem can take advantage of some very simple and very effective logic operations that would not be as simple or direct in decimal (10 is not a power of 2). | ||
+ | |||
+ | That each octal digit represents three binary bits should be kept in mind. This problem entirely plays off how well binary values and octal values just sync up (because, well, they do). | ||
+ | |||
+ | We would experience similar neatness with decimal if we started playing with base 10, base 100, and base 1000 values (in such a case, decimal would be to base 100 and 1000 what binary is to bases 8 and 16). | ||
+ | |||
+ | =====0x1: when a number isn't a number but a representation of a number we'd like it to be===== | ||
+ | > Does **chmod(2)** have to be in octal or are there other ways that it can work. | ||
+ | |||
+ | No, you can think of it as being in binary, octal, decimal, or hex... or any base, really, so long as that value, when converted to octal, matches the desired permissions. | ||
+ | |||
+ | After all: | ||
+ | * 0640 in binary is: 000110100000 | ||
+ | * 0640 in hex is: 1A0 | ||
+ | * 0640 in decimal is: 416 | ||
+ | |||
+ | Once the number is in the variable, it can instantly and effortlessly be represented in base 8, 10, or 16. It can be thought of as any one of those, and it really doesn' | ||
+ | |||
+ | The only difference is when we choose to visualize them... when you SEE a number, it has to take a form (and abide by a base)... when you input a number, we apply the same notions. But once stored in a single variable on the computer, its original form is unimportant. | ||
+ | |||
+ | The value provided on the command line has to conform with the octal permissions, | ||
+ | |||
+ | > Converting argv[1]' | ||
+ | |||
+ | The command-line " | ||
+ | |||
+ | So, if the first digit of argv[1] is a ' | ||
+ |