Lost amongst the geeks

Everybody uses commands such as chomd +x "some file" , chomd u+x "some file" (for the user only) or chmod 775 "some file"   The available options are read (r, or number 6), write (w or number 2) and Execute (x or number1). Each of these can be applied to user, group or others making sense of 777 type permission commands. A good explanation can be found here . With the basic understanding of the Classes and Permissions, let’s delve into it further and see how the “777” or “775” come about. Every file and folder contain a 8-bit data that control the permissions. At its basi c binary form, it will be “000”, which means no permissions of any form is granted. When you set a “Read” permission, it will add 4-bit to the data, making it “100” (in binary format) or a “4” in the usual decimal format. Setting a “Write” permission will add 2-bit to the data, making it “010” and “2” in decimal form. Lastly, setting an “Execute” permission adds 1-bit ...

sYou are given a integer in string format; String sNum = "25"; int iNum = StrToInt(sNum); How does StrToInt() work? Crudely it's as follows. You go digit by digit. Each digit has a hex value. 0   0x30   48 1   0x31   49 2   0x32   50 3   0x33   51 4   0x34   52 .... 9   0x39   57 The algorithm pseduo-code is as follows. 1. result = 0; 2. for each character i in sNum 3.   result = result*10; 4.   result = result + ASCIIVal(sNum[i]) - ASCIIVal('0'); Let's take 25 for example. For the first iteration; sNum[0] = 2; result = 0*10=0; result = 0 + (50-48) = 2; For the second iteration; sNum[1] = 5; result=2*10=20; result=20+(53-48)=25

A good question on stack overflow can be found here It discusses about the size of the array being different to the sum of the size of each member. e.g. struct Item{     int i; // 4     char buf1[10]; // 10     char buf2[20]; // 20 }; sizeof(test) is actually 36!!! This is because of padding the members... Memory is usually organized into 8 byte chunks, so sometime the compiler will add 4 additional padding bytes for the int... Anyways memcpy is on the spotlight and it's a generic function that can be used to copy the values of num bytes from the location pointed by source directly to the memory block pointed by destination ., void * memcpy ( void * destination, const void * source, size_t num );   You can use it to copy char buffers, arrays, structs or any other memory. This is a fast operation and should be used in performance oriented programs instead of assignment. The following example illustrates it's usage poi...

char *Type = new char[10]; Say you have a char array in heap. You want to fill this array with something; say "Access". If you do; Type = "Access" This would be a memory leak!!!! What happens? You'll get a warning/error; error : deprecated conversion from string constant to 'char*'   but this is not regarding the memory leak. What actually happens is that the statically allocated string literal will be assigned to the pointer Type, i.e. Type will now point to a different memory and you have no handle to the new'ed memory you actually allocated by new char[10] !!! Ouch! The proper way to do this is; strcpy( Type, "Access" ); But the actual error/warning is because the actual type created by saying Type="Access" is a const char*. The string literal "Access" is usually not inteded to be modifed by something like Type[0] = "a". Fix would be to do; const char *Type = "Access";

"C library functions such as strcpy (), strcat (), sprintf () and vsprintf () operate on null terminated strings and perform no bounds checking." "snprintf is safer than sprintf" What do these statements really mean? int sprintf ( char * str , const char * format , ... )  int snprintf ( char * s, size_t n, const char * format, ... );  char * strcpy ( char * destination, const char * source ); char * strncpy ( char * destination, const char * source, size_t num );   The usage is something like; char* msg1 = new char[10]; strcpy(msg1, "test"); // 1 char buffer[128]; sprintf(buffer, "%s", msg); //2 strcpy : Copies bytes until it finds a 0-byte in the source code. The string literal "test" has 4 characters and a terminating null character at end, therefore needs 5 characters at least on msg1.  Is this dangerous? Yes, because if the source message is not null terminated it will read until a null character ...