Pointers in C

Hey guys I'm having a little trouble with the following example

#include <stdio.h>
int main(void)
{
char s[] = "Melbourne City";
printf("%s\n", &s[2]);
return 0;
}

which prints "lbourne City" instead of the address of letter 'l'.
I do understand that the %s in the printf continues until a null terminator is hit, but not why &s[2] returns a character in the first place.
Thanks.

>>40
What makes you so wise, calculus? Other than reading the fucking standard of course.

>>41
I WATCHED DEANIS RICKY DEVELOP C. I WATCHED HIM WRITE IN C. I WATCHED A BUNCH OF MEDDLING HYENAS DESTROY C. AND I SURE AS FUCK WATCHED DEANIS RICKY KILL HIMSELF BECAUSE OF DOSE VERY SAME FUCKING HYENAS.

DATS WAT MAKES ME WISE, YA FUCKIN RETOID. I SAW C GROW. I SAW IT WHEN IT WAS PURE AND IN ITS PRIME. AND I SAW IT BECOME DA TAINTED MESS DAT IT IS TODAY. JUST LIKE FUCKING RICKY, EXCEPT I DIDN'T GO AND KILL MYSELF OVER IT.

AND I NOT ONLY RED DA FUCKING STANDARD. HERE, TAKE DIS, MIGHT FUCKIN TEACH YA SOMETHING: http://dis.4chan.org/read/prog/1369512114

>>39
Take your all caps ebonics back to Twitter, you fucking nigger.

>>43
*POINTS TO DA DOOR*
OUTTA MY THRED, RETOID.

>>39
>ITS POINTERS AIN'T EVEN NUMERS.

010010010110111001110100011001010111001001101110011000010110110001101100011110010010000001101001011101000010011101110011001000000110000101101100011011000010000001101110011101010110110101100010011001010111001001110011001000000010110100100000011000010110110001101100001000000110010101101100011100110110010100100000011010010111001100100000011100110111010101100010011010100110010101100011011101000110100101110110011001010010000001100001011011100110010000100000011000010010000001101101011000010111010001110100011001010111001000100000011011110110011000100000011010010110111001110100011001010111001001110000011100100110010101110100011000010111010001101001011011110110111000101110

>>44
https://twitter.com

>>45,46
SHOVE IT UP UR ASSES BEFORE I DO.

>>47
Do what? Shove it up your ass? Feel free, nigger faggot.

>>48
HAHA, SURE, SINCE UR ASS IS MINE. *TAKES A SHIT ON DA STANDARD THEN SHOVES IT UP UR ASS* HOW DO U LIKE DAT, YA QUEER DEESH BAG? NOW REED IT, YA FUCKING STACK BOY.

>>42
I thought such manner of articulation didn't exist 40 years ago, especially not at high-grade establishments such as Bell Labs.

As far as "meddling" and "destroying" C is concerned, I understand you're referring to post-ANSI C standards, such as C90, C99, C11 etc. Not that they gained that much popularity anyway, ANSI C is still considered the "solid" standard by most. Unless you are a die-hard fan of oldschool vanilla K&R C.

Unix/C/C++ is the new eternal Jew. Unix/C/C++ is kike-ugly and yet, like virus, it gets everywhere, it perverts everything and everyone starts adoring and respect this ugly parasite. I can't imagine more filthy and Jewish software than Unix/C/C++.

>>50
I understand you're referring to post-ANSI C standards, such as C90, C99, C11 etc.
UR DED RONG ABOUT DAT. FIRSTLY, ALL DOSE STANDARDS HAVE BEEN ADOPTED BY ANSI. DA ONLY DIFFERENCE IS DAT ANSI DIDNT FUCKIN PUBLISH 'EM. AND C89'S SHIT IN ITS OWN WAYS. MY FAVOURITE C'S A C DAT HAS NO FUCKIN NAME.

>A C DAT HAS NO FUCKIN NAME

DAT STANDARD ;)

>>38
Soooo... if we assume an ILP32 system, what is inherently wrong about
printf("%u", &a);
It's undefined behavior. For an example, consider a CPU with separate data and address registers (e.g. M68k). Your printf call would receive the pointer in register A1 (assuming the pointer to the format string is in A0), but the %u specifier tells printf to read from the data registers, in this case D0. That's only one of the ways it could fail even when int and void * are the same size. Even if it ``works on my machine'' there's no guarantee that different optimization settings or compiler versions won't break it.
$ tcc -run -
#include <stdio.h>
int main(void){printf("%d %f\n", 3.0, 10);}
10 3.000000
That's also presumably why this prints what it does on my machine.

>>52

so, you seem to have worked with dennis. would you mind if i use c++ just for its classes, using ansi c beyond ?

>>53
le back to /g/ meme spouting emote kid

Good ole /prog/. Can't even do understand basic pointers.

>>55
I DON'T GIVE A FUCK ABOUT WAT I USE, SO LONG AS YAINT TALKIN LIKE A FUCKIN STACK BOY.

>>58
WAT U USE*

>>58
"stack boys" are... stackoverflow frequenters...?

>>60
``Stack Boy'' is actually a euphemism for a sex-crazed male, because they feel a need to push and then pop.  Needless to say, upon achieving Satori, a former stack boy realizes that direct memory address is far superior.

>>60
Stack boy: Some retoid who believes that the C language has a call stack. This belief is a result of confusing the language with the implementation of the language.

>>62
Wow... L.A. Calculus spoke in non-caps.

>>63
koz he iz not him

now tell me L.A, Is it bad to define many extern, global variables ?

>>55
Use LISP for all your object/class/whatever the fuck else kind of fuckery.

>>65
But it's an unusable old hack. It's not even a language.

>>64
C DONT HAVE GLOBAL VARIABLES YA RETOID.

>>67
EXTERNALLY LINKED OBJECT

>>67

it sure has. look :

#include <stdio.h>

extern int lel = 5; // global

void main() {
   printf("%d",lel);
}

>>69
OOH, U FUCKED UP BIG TIME YA RETOID.

extern int lel = 5; // global
DIS IS STRICTLY A FUCKIN DECLARATION. IT DOESN'T DEFINE AN OBJECT AT ALL, YA RETOID. YAINT RED DA FUCKIN STANDARD, AND YAINT KNO HOW TO USE extern.

void main()
NON-STANDARD RETURN TYPE.

printf("%d",lel);
NO TERMINATING NEWLINE LINE EMITTED TO stdout.

>>70

well, retoid. just tell me :

extern lel_t lel = new lel_t;

where is your DA STANDARD now ?

>>71
I wrote this poem for you:
If you think sepples is C, you should go back to /g/.
How do you like it?

Wipe my ass with hundred-dollar bills and laugh at the /g/.
-- Slaine, "Creed of the greedier".

http://www.youtube.com/watch?v=W9a0alGXAQI
Anime loli inside.

Just let the retards who think sepples is C continue, it makes them easier to recognize as being retarded.

Global variables do exist in C, they're simply declared/defined (and optionally initialized) outside of any function and are accessible via their identifier to any function called in that source file. The 'extern' keyword, as hinted at above, does not define such a variable, it merely declares it (kind of like withe a function prototype versus a function definition); that variable must be defined in another source file which is to be linked.


#include <stdio.h>

void func1(void);    //func1 function prototype (i.e. declaration)
void func2(void);    //func2 function prototype (i.e. declaration)

int var = 5;        //global int variable decl., def. & init.
char arr[] = "foobar";    //global array of char decl., def. & init.

int main(void)         //main function (no prototype necessary)
{
    printf("\nvar and arr invoked by id from main():\n");
    printf("\tvar: %u\n", var);
    printf("\tarr: %s\n", arr);
    printf("\tsizeof(arr): %u\n", (int)sizeof(arr));
   
    func1();              //call to another function invoking global objects
    func2();              //call to yet another function invoking global objects
   
    return(0);           //program exit
}
   
void func1(void)       //func1 function definition 
{
    printf("\nvar and arr invoked by id from func1():\n");
    printf("\tvar: %u\n", var);
    printf("\tarr: %s\n", arr);
    printf("\tsizeof(arr): %u\n", (int)sizeof(arr));
}

void func2(void)       //func2 function definition
{
    printf("\nvar and arr invoked by id from func2():\n");
    printf("\tvar: %u\n", var);
    printf("\tarr: %s\n", arr);
    printf("\tsizeof(arr): %u\n", (int)sizeof(arr));
}

In the above program, var is a global variable called by id from main() as well as from two other functions; arr is an array seen as such (i.e. not decaying to a mere pointer, as evidenced by its sizeof evaluations) from any of the functions.

Global objects are about as "harmful" as the goto statement - generally not recommended to use on a regular basis, though can be useful in particular situations if used wisely.

>>76
Somewhat informative for a beginner... you must be new here! Are you Cudder?

printf("\tvar: %u\n", var);
printf("\tsizeof(arr): %u\n", (int)sizeof(arr));
Why %u instead of %d when the argument is of int type?

>>77
>Why %u instead of %d when the argument is of int type?

>printf("\tvar: %u\n", var);
Stricly speaking, it should be %i (or %d, %x or %o to force a specific number base for the output). Still, it makes no difference here really, as var is assigned a positive value anyway (the storage format is the same for int and unsigned int, it merely depends on the interpretation whether the contents are considered unsigned or two's complement signed).

>printf("\tsizeof(arr): %u\n", (int)sizeof(arr));
Here, you definitely want an unsigned value, as a negative sizeof return value would not make much sense. Again, as the size of the array is merely 7, it does not make an actual difference. If on a 16-bit-integer system you had an array larger than 32k (or on a 32-bit-integer system an array larger than 2G), the expression (int)sizeof(arr) would return a negative value - however, the %u specifier in the string literal would recast it to unsigned int anyway. To be totally proper, the return value of sizeof should be cast from size_t to unsigned int in the first place:
 
printf("\tsizeof(arr): %u\n", (unsigned int)sizeof(arr));

>Are you Cudder?
I don't think so. Though, I already did happen to make some contributions to this rather amusing thread.

>>78
Here, you definitely want an unsigned value, as a negative sizeof return value would not make much sense. Again, as the size of the array is merely 7, it does not make an actual difference. If on a 16-bit-integer system you had an array larger than 32k (or on a 32-bit-integer system an array larger than 2G), the expression (int)sizeof(arr) would return a negative value - however, the %u specifier in the string literal would recast it to unsigned int anyway. To be totally proper, the return value of sizeof should be cast from size_t to unsigned int in the first place:

printf("\tsizeof(arr): %u\n", (unsigned int)sizeof(arr));
Then printf("\tsizeof(arr): %zu\n", sizeof(arr));

>>79
Ah yes, the ever-so-obscure %z specifier. There you go, no need to recast to a generic arithmetic type then.