Lab46 Wiki

User Tools

Site Tools

You are here: start » haas » spring2015 » cprog » projects » eocehints
haas:spring2015:cprog:projects:eocehints

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
haas:spring2015:cprog:projects:eocehints [2015/04/19 13:23] – [0x1: more octal] wedgehaas:spring2015:cprog:projects:eocehints [2015/04/19 20:44] (current) – [0x1: more octal] wedge
Line 13: Line 13:
 If you were to convert "640" to an integer value 640, that would be 640 in base 10; 640(10) to base 8 would be: 1200 If you were to convert "640" to an integer value 640, that would be 640 in base 10; 640(10) to base 8 would be: 1200
  
-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're all being sourced from an integer variable called result... a regular old int... so it ultimately is up to how we instruct the computer to interpret it... after all, EVERYTHING is in binary, even if we are thinking through the problem exclusively in decimal.+And also, do you see that regardless of displaying it in octal, decimal, or hex, it is the same value? They're all being sourced from an integer variable called result... a regular old int... so it ultimately is up to how we instruct the computer to interpret it... after all, EVERYTHING is in binary, even if we are thinking through the problem exclusively in a different base.
  
 > Why doesn't adding the leading zero make it octal? > Why doesn't adding the leading zero make it octal?
Line 81: Line 81:
  
 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). 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't make a difference, because they're all the same (in that 0640 == 0x1A0 == 000110100000 == 416). That's just how numbers work (on or off the computer).
 +
 +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, just as the chmod command does.
 +
 +> Converting argv[1]'s "640" to 0640 seems confusing because they are two completely different values. 
 +
 +The command-line "640" (the string) isn't a decimal; it isn't one number (and as such shouldn't be considered an automatically intelligible number, that's where our program comes in, to make sense of it)... it is an ASCII representation of a 3-digit number (or, a sequence of three two-digit decimal numbers that represent the ASCII character being displayed). Due to the context of how we're interpreting it, we desire that number to be ultimately represented as a single octal quantity (of 3-digits), because that is what the chmod(2) function requires.
 +
 +So, if the first digit of argv[1] is a '6' (that's what, a decimal 54?), we know for the three bits that correspond with that field (the user field), we want to apply read (4, or 100 binary) and write (2, or 010 binary) for a total of 6 (110 binary). For the user field, read is 0400 (XXX 000 000 in binary (marked with the X's)). For the group field, read is 0040. Look at where they end up lining up in binary.
 +
haas/spring2015/cprog/projects/eocehints.1429449788.txt.gz · Last modified: 2015/04/19 13:23 by wedge

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki