String In Char Array VS. Pointer To String Literal | C Programming Tutorial

[@PortfolioCourses]

Like the video? Check out these C programming playlists with hundreds of videos! 🙂 C Programming Examples: kzbin.info/aero/PLA1FTfKBAEX6dPcQitk_7uL3OwDdjMn90 C Programming Tutorials: kzbin.info/aero/PLA1FTfKBAEX4hblYoH6mnq0zsie2w6Wif

[@etmax1]

Is it perhaps that s1[] = "abcdef" results in the string being on the stack and s2* = "abcdef" has it defined in program memory space or as a const in heap space (depending on the compiler?) and being const in both cases is unmodifiable. Also you can do a cast of s1[] by saying (char *)s1++ and do the same as if it was declared originally as char * s1. There's also: s1[]= "hello"; foobar(void) { } where s1 isn't on the stack, instead on the heap. It would be interesting to check whether doing: char s2 * = "Hello"; would place the string in heap space or const space. I've just tried this and looked at what my compiler does with it and in the s1 case as expected I get: s1 char [6] 0x20000548 where we can see that s1 is an array pointer stored at address 0x20000548 (RAM) that has a length six and s2 char * 0x10002710 "Hello" is a char pointer pointing to a literal stored at 0x10002710 (ROM). So you can see we do know where it's stored, the only thing we don't know without checking is whether it's a const in RAM (heap space) or const in ROM both of which are non modifiable. BTW, because s2 is declared immediately after s1 the map file tells me that it is in RAM location 0x20000550

[@pratham8275]

32-bit Systems: On a 32-bit architecture, the address space is limited to 2^32 addresses, which means that the maximum addressable memory is 4 GB (2^32 bytes). To represent any memory address in this space, you need 4 bytes (32 bits). Therefore, the size of a pointer on a 32-bit system is typically 4 bytes. 64-bit Systems: On a 64-bit architecture, the address space is significantly larger, allowing for 2^64 addresses, which translates to a theoretical maximum of 16 exabytes of addressable memory (2^64 bytes). To represent any memory address in this vast space, you need 8 bytes (64 bits). Therefore, the size of a pointer on a 64-bit system is typically 8 bytes.

[@竜肝油]

char *s is precompiled in .text while char s[] is allocated in .data section so if you try to modify *s like s[0] = xxx, it will usually cause a sigseg since you're modifying .text section which is read only

[@vladimironoprienko7177]

that makes things clearer. thanks!

[@jansustar4565]

Isnt it always copied to the stack when a function is called? Unless main is sn exception. I guess i have to open up godbolt

[@KhaledKimboo4]

The Value of the pointer is stored in .text not the literal itself, .text would have a pointer value pointing to a region in memory (that region is not decided by your code rather by the os ) , his explanation is correct

[@kevinquintana3085]

Makes sense to me

[@mefrefgiweuhef4808]

Portfolio courses is without a doubt, the best c programming / computer science teacher !!

[@PortfolioCourses]

Thank you for the very kind words Mefref. 😀

[@mohammadahmedragab837]

I totally agree with you, it is the best C courses✨

[@PortfolioCourses]

Thanks Mohammad! :-)

[@SerajAlhorany]

I second that

[@bayyyi]

A little bit more in depth explanation: - In C string literals ( aka double quoted strings ) if not used as initializers for char arrays are staticilly allocated, that means they live in the .text / .rodata section and under most operating systems thats read only ( aka no self modifying code for you ;). - char s1[] and char *s2 are different types, s1 can be used in functions expecting a char* parameter because of some evil compiler backwards compatibility magic which automatically converts any function(s1) -> function(&s1[0]) - Both s1 and s2 in the example is stack allocated, but while s1 is an array of chars all values are also stored on the stack, while s2 is a char pointer and only the pointer variable is stack allocated the value it points to isnt. Its also quite interesting to look at the assembly your compiler generates and learn from that ;)

[@bayyyi]

youtube ate my * characters, but i tink you get my point ;)

[@psyience3213]

Exactly that's what i just commented above in the super popular, pedantic and yet wrong first comment

[@bayyyi]

@@psyience3213 i missed it ;)

[@FlamurMustafa-l4l]

It's not compatibility magic, it's called pointer decaying, you can't pass a whole array to you can't pass a whole array by value in c, instead you pass a pointer to the first element and the size of the array.

[@guiorgy]

I suspected it was a pointer to globally static memory, makes sense it's read-only, otherwise every call to the fuction modifying that memody would get/produce different results. Thanks for the clarification.

[@jongecsek5085]

Excellent explanation! I just went through a string section in a C course I am taking and completely misunderstood the content. Even though I was able to stumble through a couple projects, I really did not understand what a "string literal" was and how it was different from a character array defined as char[]="some string". This cleared it up perfectly. You have a rare gift in instruction for the C language and I feel lucky to have found Porfolio Courses. Judging by the other comments, I hope you will continue this great work.

[@vorpal22]

Great video. It's been a couple decades since I've done any C programming and I've forgotten some details like this since my programming focus has shifted considerably to functional programming, Python, and C++.

[@PortfolioCourses]

I'm glad you enjoyed it! :-)

[@rickzalman4136]

Good video, but I like to also add that char msg[] ="hello"; is just shorthand for char msg[] ={'h', 'e', 'l', 'l', 'o', '\0'}; There are no such things as strings in C. Only char arrays or character arrays. And the address of first character of the char array is fixed , it is a constant pointer, &msg[0] and msg mean the same thing. And msg and msg + 0 is also the same , you can't change the base address of the array, it is suck in memory. It makes sense , lets say you had this : char s[]="car"; then decided to change it to s = "abcdefghijklmnopqrstuvwxyz123456789134566778889abcdefghijklmnopqrstuvwxyz" ; The compiler would have to find a large amount of memory for this new change in size. And there might not be enough memory for this new sudden change in size. Therefore a array's starting address being fixed is a good safeguard. Therefore the base address of any array in C is fixed, it is a constant. This applys to all arrays in C , for example: int a[]={1,2,3}; int b[={4,5,6}; you can't do this a= b; ////// same as a= &b[0] ; // because you are changing the starting or base address of the integer array called a . The address of a is fixed, and will remain fixed for the entire program. But I can do this , int *p = a; ///// int *p =&a[0]; then later I can change the int pointer to point to array b p = b; ////// because p is a pointer variable that can point to any variable or any array as long as it has the same data type , as the variable or array , that it is pointing, or refering to. Pointer variables can point to any variable of the same type. Again as I said earlier , char arrays or C-strings are character arrays only , there is no such thing as a string in C , they are not String objects like Java , or String objects like C++ or C# .

[@PortfolioCourses]

Wow thanks so much for sharing all of this Rick! For anyone curious, some of this gets covered in other tutorials videos in the C programming tutorial playlist on this channel that cover strings, pointers, and arrays. And I get what you're saying regarding "C not really having strings", and I think you mostly clarified it at the end of your own comment. But just to be clear, it's inaccurate to say that "there are no such things as strings in C". In C there is no string *type* like some languages such as Java, but the language definitely has strings. In C the term "string" means a sequence of characters in memory ending with a null terminator, whether it's on the stack, the heap, or wherever the compiler being used stores a string literal. The official C standards make reference to strings and that's the term to use when referring to them: www.open-std.org/jtc1/sc22/wg14/www/projects#9899.

[@Patrik6920]

...partly incorrect... Char *text="abcdef" is a pointer to a memory adress containing a string(a sequence of ints, ending with a string end integer Char Text[]="abcdef" is a pointer to a string object, still in a speciffic memory adress ofc, with the difference it also has an table with functions that can be performed on that memory adress... eg it is a STRING_OBJECT , (a table saying this object at this adress is a string and the listed functions can be performed on it, u can add or overwrite functions that can be performed on objects, usually a bad ide overwrite them, just extend if needed ) ...u can point at any memory adress and read it as a string..but its not a string object... eg the compiler has no ide what function is allowed to run on that memory adress... ex. Char Text[]="abcdef" print Text , (will print abcdef) Char *ptr_text=&Text *ptr_text=8 print ptr_text (will output the first charater after the string as a sequence of character until it reaches a end string int (out of bounds)... it will otput som part of memory as characters.

[@atussentinel]

​@@Patrik6920 wdym by "Char Text[]="abcdef" is a pointer to a string object, ..., with the difference it also has an table with functions that can be performed on that memory adress... eg it is a STRING_OBJECT"? There is no such "string object" in ANSI C standard library. char text[] declares a char array, that's what it is. It's no way a "STRING_OBJECT" in C, neither a way to declare a "std::string" object in c++. The "table of functions" is even more ridiculous, C is not OOP native and there is no data structure having bound functions (methods). Explicitly adding function pointers to data structure is another story but it's neither something you can do with declaring only "char text[]". Everything in your original comment below the above line quote is hard to understand or difficult to follow. I'm guessing you are either mixing C with some other languages or regarding some custom/3rd-party string libraries as standard C.

[@mytech6779]

Not an accurate statement. A C string is a null terminated array of characters. A true char array is just a sequence of bytes, it is not null terminated and will not work with routines that expect the terminating null unless you just get lucky and have put a null byte in the array. Like other arrays a true char array must have the length metadata tracked separate from the contained data.

[@Patrik6920]

@@atussentinel when u create a string object thers functions that can be used on it, those functions is described (it isent some random data), when u compile a piece of code, and u try to use charachter functions on an int for example the compiler is going to realise it.. ...whats associatet with what int, char, float is described in a function table with that data type structure...

[@juuls7082]

Very good video, thanks to your calm, soothing voice and the low pace in which you explain everything step-by-step!

[@PortfolioCourses]

I'm glad you enjoyed it! :-) And thank you very much for the positive feedback.

[@rokko1337]

In case of embedded devices, and so I suppose in desktop application case also: char *s = "abcdef"; "abcdef" goes together with other constant variables to RO (Read Only) section of memory, that is a part of FLASH (CODE + RO). s pointer goes together with other non-constant global/static variables to RW (Read/Write) section of memory, that is a part of RAM (RW + ZI (Zero-Initialized)) (technically it placed in FLASH, but loads to RAM during initialization). char s[] = "abcdef"; "abcdef" goes to RW section ("s[]" goes nowhere, it kinda does not exist unlike "*s", that is specifically variable type to store address pointing to another location, because all address calls to "s[]" are stored in code commands and cannot be modified and it's the reason why you can't reassign "s[]" to another string later in the code). That's why if you want to save RAM space when using a lot of string arrays those are not gonna be modified, you must declare them "const char s[]" so their values could be placed in RO section (in this case it may look the same as "char *s", but there are still differences in compilation and how it processed by different functions like sizeof(), because array will have data type "char []" not a pointer type). This explains why you get that access error trying to modify value that is placed in RO section.

[@CaptTerrific]

Which compiler or flags are you using for this? I'm not a professional C programmer, but I figured your first example would require a const declaration? I'm very likely missing something major, hoping you can help me :)

[@JA-sv1gv]

I agree with all but the s[] part. It is a variable that refers to the starting address of the array and it should be observable in a map file with the associated size to it. Furthermore, there's a difference between initialization (compile-time) vs assignment (run-time). You can't re-initialize a variable but you can reassign a data at each element in s[] and ultimately change out the whole string even sizes during run-time.

[@komalshah1535]

Extremely useful. Please make the same video with more examples and corner cases. You are very good teacher. You deserved to be paid.

[@danielheinrich8046]

This subscription reminder is the best I have seen so far. Totally non-obtrusive and non-annoying. I love it. *Klicks subscribe*

[@lamtatyan]

I have watched many videos teaching what pointer is and how to use, but only this one can make me truly understand how to use pointer in a few minutes. This must be a good day for me, as I have learnt thing from a genius.

[@PortfolioCourses]

That’s awesome this video was helpful for you and thank you so much for the kind words! :-)

[@mikehibbett3301]

Yep, depends on your compiler. I've lived with this over the years I've been working with C on embedded systems. It's one reason why fixing your projects code development to a particular version of your compiler tool chain, AND the optimisations you use, is very important.

[@earthwormscrawl]

It also depends on the execution environment. A segmentation fault requires a memory protection unit. When working with a flat physical memory, typical in embedded systems, the two approaches will behave identically.

[@occamraiser]

One is a string, initialised with abcdef and the other is a pointer to part of the program itself, 6 bytes representing abcdef. When I was writing embedded process control software a million years ago, the first version would be 6 bytes of RAM and the second would be a pointer in RAM pointing at a string of 6 bytes in ROM.

[@Tzwcard-x]

yeah that's what I also think so, that contents of s1 allocated in program stack while s2 allocated in .text (which is read only and cannot be modified without something like VirtualProtect() in windows)

[@Hoffmatic]

I’m still learning C and taking an Embedded systems class. I wrote a char * array when transmitting over UART because google said to, while my professor said to traverse over the array instead. When I asked him to help debug my code he was blow away that I used the more efficient method, and so was I lmao

[@Kris_M]

0:38 Note: a string literal is not guaranteed to have a closing null character! If you write char s[6] = "abcdef"; there will not be a null terminator.

[@kosiak10851]

"abcdef" has null terminator, it is just not assigned in because of lack of space

[@logos_13]

Once again, a clear explanation on a tricky point. Thanks 🙏

[@PortfolioCourses]

You're welcome, I'm glad you found the explanation clear! :-)

[@CaptTerrific]

Don't you mean a tricky point...er? I'll see myself out

[@okaro6595]

The compiler allows you to modify. It is the runtime protections that prevent it. If you tried it in DOS then it likely would likely work.

[@PortfolioCourses]

The compiler may or may not allow you to modify it according to the C standard. In the C standard it's something called "undefined behaviour", there are other undefined behaviours. The compiler could produce code that allows you to modify the string literal, and that would still be a valid C program.

[@dibblethwaite]

@@PortfolioCourses The language definition says that the behaviour is undefined in order that implementations may put the string in protected memory if such a thing exists on the target platform. The compiler typically needs to do nothing to either allow you to or prevent you from accessing the memory and as @okaro6595 says it is normally the operating system/hardware that blocks the access. It is also true that DOS compilers used to allow this sort of access back in the day since no protection mechanism existed in the hardware. So you may find that these things make sense to you once you understand the reasons that the standard declares the behaviour as undefined.

[@PortfolioCourses]

@@dibblethwaite I appreciate and understand what you're saying, my only point is that because the language definition says that, compiler makers can ultimately do what they like, e.g. they could even put the data for string literals on the stack. Now of course practically, why would they? But again my only point is to state the fact that the language standard lists the behaviour as undefined, so we can't assume. Again though I do appreciate the discussion on underlying reasons "why".

[@jaggmor]

Litterally had the exact same question a week ago in my HPC-course! Many thanks 🙏🙏🙏

[@PortfolioCourses]

You’re very welcome Grabriel! :-)

[@berndeckenfels]

You should be able to define in the linker in which segment the literal is stored and what attributes it have. In GCC __attribute__ ((section „.rwdata“)) would work as well.

[@dechros]

Lets not to make the code compiler dependent.

[@serhatarslan4138]

char* s2 = "hello", attempting to change string literal is undefined behavior so you don't know what will happen in run time.

[@PortfolioCourses]

Yep! :-)

[@Hardcore_Remixer]

As far as I have experimented, it gave a segfault. The teacher explained that in assembly it is placed in the .text section (which only has read permission) and the pointer just gets assigned the begining address of that string. Though, I haven't tried it on other architectures than x86.

[@johnmcleodvii]

The definition of undefined means it is stupid to use even if it appears to work. Way back in the era of 8086 and 8088, there were compilers where this worked - sort of. This was before x86 had much in the way of process security. The gotcha is that that string literal would change for EVERY instance of the original string. I think it was an early Microsoft compiler, but it could have been some other compiler.

[@Hardcore_Remixer]

@@johnmcleodvii Well, it actually makes sense that when you modify one of the instances of a string constant all of them will modify the same way because it is usually the same string constant being referenced by all of its instances in order to save memory.

[@obinator9065]

I thought it would even give me a compiler error

[@oysteinsoreide4323]

the c++ compiler will forbid to declare char * s1 = "test"; because it is a convertion from const char * to char * which is forbidden.

[@mikehibbett3301]

When I'm building code with a new toolchain I am always looking at where that tool is putting my string literals (through the map file) just to make sure I understand what it's assumptions are. And these assumptions vary with optimisation options

[@rursus8354]

The pointer in c[] is constant, but in *c it is a variable that can change value. But everybody know that.

[@jess-inspired]

🥳Wow!! Thanks a lot sir!! This is massive for me..

[@PortfolioCourses]

You’re welcome! :-)

[@jess-inspired]

Hello sir, can I link this video on my channel to refer my viewers here for better understanding?😊

[@alexankd]

I wish i could have watched this video back in 1998. Really well-explained!

[@madyogi6164]

2nd declares a pointer and makes it point at character constant {"abcd"} (which is type of "const char *" not char* (one most likely gets compiler warning about mixing both). And segfault wile executing.

[@atarixle]

The s2 remains stored in the binary of the program while s1 is stored as a copy on "the stack". Some operating systems will allow you to change bytes between executable code, like cc65-built code for Atari 8 Bit, Apple II and C64, while other, more secure operating systems will deny access to it. The same will happen in any other programming language (look up "self modifying code"). This may be one reason why the C standard is not specially forbidding modifying s2, but operating systems do.

[@dhyey2316]

Thanks bro. It helped me to clear confusion

[@PortfolioCourses]

You’re welcome, I’m glad it helped clear confusion up for you! :-)

[@petedavis7970]

I did C and later C++ for over a decade and was pretty close to giving up programming. Writing business software, I was so frustrated by the tedium of C and C++. Keeping .h files in sync with .cpp files, managing pointers, and my biggest frustration: dealing with strings. It's just so tedious in C and C++. Fortunately, right around that time, C# showed up and strings were as easy to work with as any other data type. Memory management became a distant memory and no more header files. I don't miss that stuff at all.

[@C2H6Cd]

Try Rust too (no GC), it’s kinda cool and deals with tedious and dangerous memory management (also multithreading) issues by design. Of course it has a “dark side” (unsafe code) but at least tries to deal with such stuff in a clear way. My problem with C/C++ is that it allows shooting yourself easily in the foot (as Stroustrup said) and even proud of it… Idk why it’s OK to be openly dangerous after decades, we are not in the 1980s anymore.

[@edward3105]

Why when u printed the s2 ,it gave you an abcdef instead of the address of index 0 ,since s2 is a pointer?

[@PortfolioCourses]

Great question! Because I used %s, printf output the string, if I had used %p it would have output the address stored in the pointer instead. :-)

[@edward3105]

@@PortfolioCourses Ohh I wasn't paying attention,u are right!

[@PortfolioCourses]

Cool glad it’s sorted out for you. :-)

[@nihitos]

for example: char* ptr="Hello"; ptr="Bye"; what does happen to "Hello"? Is the memory where it was stored freed? Or do I get memory leak someway if I continue to assign different values to ptr? Thank you.

[@PortfolioCourses]

Assuming the compiler doesn't optimize it away, "Hello" will be somewhere in memory. We wouldn't really call it a leak because it's not dynamically allocated memory that we are expected to free(). But it would sort of be like a memory leak in the sense that we have data in memory we aren't using. :-)

[@JosephMwema]

Thank you for asking that Question. It has helped me to understand something in his answer.

[@justcurious1940]

great channel i'm planning to see your whole c++ course later 👍

[@PortfolioCourses]

Thank you, I’m glad to hear that you’re enjoying the channel! :-)

[@bsykesbeats]

4:29 if it gives a runtime error as opposed to being stopped by the compiler, than doesn't that mean that the compiler does allow it? It just gives a seg fault when u run it...

[@PortfolioCourses]

The compiler allows the code to compile because it conforms to the C language standard. But the compiler doesn't allow us to modify the string literal at runtime... theoretically, the compiler could support this and compile the code in such a way that we are allowed to modify the string literal, because the C language standard only says that the behaviour is "undefined".

[@bsykesbeats]

@@PortfolioCourses ahhh makes sense thank you

[@PortfolioCourses]

@@bsykesbeats You're welcome! 🙂

[@mikechappell4156]

@@PortfolioCourses It's not the compiler throwing the error, it's basically the OS. IIRC, protected mode prohibits self modifying code, and if it's in the code segment, it's code, even if it is just data. I think real mode used to allow it. I don't think modern processors even support real mode. Self modifying code was common on 8-bit machines.

[@PortfolioCourses]

@@mikechappell4156 That's true and a great point to make. Though what I said in the reply was that the compiler "doesn't allow us to modify the string literal at runtime", and that's also true. The compiler compiles the code in such a way that we can't modify the string literal. But the compiler could compile the code in such a way that we could modify the string literal, and it would still be compliant with the C standard because the behaviour is undefined.

[@amanimavu810]

Awesome stuff. Learned something new. Thank you

[@PortfolioCourses]

You're welcome Amani, I'm glad to hear you learned something new! :-D

[@rasmusmerzin]

Theoretically if this pointer to a string literal would be in a function that gets called multiple times the pointer could always be the same. In the output the string literal itself would probably be defined before the function as a "constant" and the pointer would always be to that constant.

[@DarylStark]

Very clear and good information! Thanks !!

[@TheBunzinator]

This is why I always write my pointer decls as "char* s2" rather than "char *s2". The "pointerness" is part of the type, not the variable. And writing it my way makes it more obvious.

[@PortfolioCourses]

I've usually done it as char **s2 because that's the standard code bases I've worked on have used, but I completely get what you're saying, char** s2 does make it clearer that it's "a pointer to a char" in that sense.

[@PortfolioCourses]

Using stars in KZbin comments messed up what I was saying and then when I fixed it, it still bolded it. I'll have to read up on how to actually do a star in a comment. :-)

[@remcogreve7982]

I think c declarations are supposed to mimic how they are used. That is why. I don’t like it either. Most modern language designers seem to prefer the old Pascal way of declaring. I like that much more.

[@nuferusi]

The pointer variant reminds me of a linked list. Where you don’t know where it’s allocated except for the first node.

[@energy-tunes]

you should use zu format specifier for sizeof as it returns size_t type

[@PortfolioCourses]

For the size of numbers we are dealing with in these simple examples %d will work fine. If we're going to use size_t values for larger numbers, like allocating massive blocks of memory for example, we would want to use %zu (though even with %zu, there are portability issues you can run into with some older compilers...). For anyone curious about learning more check out these tutorials: size_t type explained: kzbin.info/www/bejne/pHOtpoOVqtNlZq8 sizeof operator: kzbin.info/www/bejne/aKixlGRrbpdpjpY

[@mkd1964]

Thank you for taking the time to make these very informative videos. For someone coming from a higher-level language, you get right to the point explaining things that you don't find in, say C# or Python. I have one question about this particular topic: When you "reassign" a const char* to a new string literal (I guess, "point it to a new one" would be more accurate), what happens to the old character data in the first string? As in your example: const char *s2 = "abcdef"; //then later, you reassign s2 to: s2 = "new string"; Does the "abcdef" just lay around somewhere, or does the compiler remove it from memory? Thanks!

[@PortfolioCourses]

Great question! In this example, it must "lay around somewhere in memory". :-) If we had saved the memory address of the string (more specifically, the first character of the string) into a different pointer variable, we could then access that same string literal, when we set s2 to something else. So the compiler and C won't remove it from memory. Now, as a side note, I do wonder if a compiler would be smart enough to remove something like this from memory: const char *s2 = "abc"; s2 = "def"; Because in this case, *maybe* the compiler could tell "at compile time" that the string literal "abc" will never be used. So *maybe* a compiler could remove the string literal "abc" from memory when the program is compiled, knowing it will never be used. But I'm not sure if a compiler could do that, or if it would do that, I'm just speculating for fun. :-) Maybe I need to test this out and see what happens hahaha...

[@PortfolioCourses]

So yeah... I did a little test right now. :-) And at least with gcc on my MacOS machine, there is no optimization like that... the string literal will stay in the compiled executable even if it is never used at all.

[@mkd1964]

@@PortfolioCourses Wow, thanks for such a detailed answer! So that's interesting. I'm still very new to C so it makes me wonder why you would ever bother using strings in this manner. The only scenario I can think of would be to display something like on-screen instructions, field labels, or menu items. Stuff that will probably get used more than once, but not likely to change during the program.

[@herohera3497]

@@mkd1964 hii u there...r u still studying

[@mkd1964]

@@herohera3497 I'm not in school, if that's what you mean, but yes. I'm just learning C for no particular reason. I've always found it interesting and challenging and wanted to have a more thorough understanding of how it works.

[@protocol6]

It's more about the OS and modern security features than the compiler, I should think. Run the same code on an old enough system or even most modern microcontrollers and it might well let you change a literal. The compiler could technically put string literals somewhere else if they wanted to but that'd increase memory usage of your program in some cases. Generally, the text segment (which includes executable code and literals) get marked read only in a way that's either enforced by the OS or the CPU depending on the system. That allows those segments to be shared between processes running the same executable on systems with virtual memory and memory protection. It also prevents certain types of security exploits. Coupled with Execute Disable (XD) on the writable segments of the process's virtual memory and it becomes easier to crash a program with bad code but much harder for attackers to exploit.

[@PortfolioCourses]

Thanks for leaving this comment, it's a well put version of a point a few others have made. I agree with what you're saying overall, a string literal being placed somewhere like the stack for example would fall under the "nasal demons" category of "highly unusual.... but legal" C compiler behaviour: www.catb.org/jargon/html/N/nasal-demons.html.

[@collinl.179]

Can you expand this explanation to include memory leaks? If I declare a string with a pointer but then changebwhat the pointer points to is this a memory leaks? Is this why we use const?

[@perfectionbox]

MSVC used to allow modifying string literals but then disallowed it. The road to compiler completion can be a long one.

[@PortfolioCourses]

Thank you for sharing that. :-)

[@UchebavGermanii]

str[] is actually a char array of sizeof("abcd") allocated at the stack memory and can be modified in runtime. str* is a pointer to the constant memory area, obviously can't be modified whenever.

[@frostheavenangel]

5:55 So, char *argv1[] and char **argv2 differs, right? argv1 is a pointer that points to constant pointers. argv2 is a pointer which points to another pointer.. and i can use pointer arithmetic in this situation.( like **argv2++; ) Is that correct?

[@PortfolioCourses]

Yes, they differ. char *argv1[] would be an array of pointers to chars. char **argv2 would be a pointer to a pointer to a char, and yes you could use pointer arithmetic in this situation. :-)

[@vicsteiner]

Very nice video! It is interesting that if you use const char *s2 = "abc" for getting the compilation error when trying to do s2[0] = "X"; does not prevent you of assigning a complete new string literal to s2 like s2 = "xyz"; which does not lead neither to compilation error nor to runtime error. So it is a const that allows re-assignment. S a const char * is re-assignable while a const int is not, why?

[@glendubie]

Great tutorial! Thank you so much for taking the time to make it.

[@PortfolioCourses]

You’re welcome, I’m happy that you enjoyed it! :-)

[@aaronfleisher4694]

I have looked a lot and still cannot find the answer to my question: I know that `char[5] x;` (and other variations of the array of characters as a string) will be stored on the stack. Thus, it will be freed at the end of the function. No memory issues to deal with in the code. A pointer to a string, `char* x = "asht"` will go where? Will `"asht"` be freed along with the stack in this pointer case? I read in one place that using a pointer to a string literal makes the string literal accessible to other functions, something like a `static`. Is that the case?

[@RikMaxSpeed]

Would have been interesting to run the code through the GodBolt compiler explorer, I think you’d spot some additional changes in the code generated by the compiler(s).

[@slimeminem7402]

Why bother with char* when I can use const char ? Or maybe we can't use the latter? I'll have to check

[@joaquinschanzenbach8443]

Can u explain me this: suppose a function that returns a char*. When I declare in main a char* variable to store the result of that function, shouldn't it return a memory direction, since it returns a pointer to a char?. When I do this, it just returns a string, or is this because of how printf() shows it on screen?. Sorry if it's a stupid question, I'm new to C.

[@adamormondroyd2876]

great vid, but I think "new string" should be 11 long including the terminator?

[@ASandro.AllMat]

Great video explanation! Let me know if I understood rightly. I can't change the string attributed to a pointer. But, if I attributed the pointer to a delcared string I am able to change the "pointer"? Like: char *ptr = str (declared before).

[@ironman-l1c]

in which playlist these types of videos you have? where you discuss these types of generic problems??

[@tyrabjurman3584]

The compiler I used 25 years ago wouldn't complain about s2[0].

[@KoltPenny]

Just as a fun fact, I'm almost sure that if in C++ you pass a constant string to a char*, the compiles optimizes and allocates for you.

[@froller]

In x86 you often got string literals placed in CODE segment not in DATA. On microcontrollers you almost certainly got string literals placed in ROM. So there're pretty obvious reasons why you can't modify them.

[@c99kfm]

Thanks heavens for malloc: #include #include #include int main() { const char s1[] = "abcdef"; char *s2 = (char*)malloc(sizeof(s1) * 8); strcpy(s2, s1); s2[0] = 'X'; printf("s2: %s ", s2); free(s2); return 0; } Lesson: Only put constants on the stack, else you'll run into the brick-wall of not specified behaviour.

[@c99kfm]

More concise example, without anything except the string literal on the stack: #include #include #include int main() { char *s1 = (char*)malloc(6 * 8); strcpy(s1, "abcdef"); s1[0] = 'X'; printf("s1: %.6s ", s1); free(s1); return 0; } Remember, kids: malloc means free(dom).

[@cylam9188]

are all array-type varibles using Stack Memory?

[@chetanhabeeb9472]

Very good explanation, Thank you

[@PortfolioCourses]

You’re very welcome Chetan! :-)

[@avetikarakelov8423]

The example with char *str = "abcd"; str[0] = 'k'; compiles and changes the first index of the string in microsoft compiler, is that normal ?

[@PortfolioCourses]

Great question Avetik! :-) Modifying a string literal has “undefined behaviour” officially, this means it *could* work but it’s definitely not guaranteed to work. So it’s “normal” but it’s not something that you should count on always working.

[@Narblo]

Oh man. Where is the comparison of the assembly generated by the compiler? :(

[@mahmoudbenyoussef5239]

This is so helpful thank you honestly

[@PortfolioCourses]

You’re very welcome Mahmoud! :-)

[@sallaklamhayyen9876]

Brilliant explanation thank you so much😘

[@PortfolioCourses]

You’re very welcome, I’m glad you enjoyed it! :-)

[@guiorgy]

I'm assuming all string literals used in the source code are stored globally. When you use a pointer to a string literal, it gives you a pointer to that global memory, and since next time the current function gets called the same memory pointer will be used, the memory must remain constant, otherwise the next call to the function will produce different results. Using a character array copies that memory to the stack, so you can modify your copy as much as you want.

[@salsamancer]

It depends on the linker. Usually string literals will actually be in the read-only text segment with the assembly.

[@mb59621]

Hey appreciate the content man , what editor do you use and i would like to know how you effortlessly jump out of autocompleted brackets. Do you use arrow keys or is there a keyboard shortcut?

[@PortfolioCourses]

In this video I'm using Xcode on a Mac. I just use the arrow keys, nothing special in this video. :-)

[@vsai9693]

Thank you for making this video sir🙂

[@PortfolioCourses]

You're very welcome! :-)

[@amansagar4948]

i didn't get how s1 is passed as a pointer to printf? it's passed as a value no?

[@melonenlord2723]

It pretty new with C++, but i always get confused with pointer and adresses. Can't a pointer only point to an adress? How can it be pointed to a String? Normally i have to add a & before everything.

[@PortfolioCourses]

It can be "pointed to" the first character in the string, i.e. the pointer variable can store the memory address of the first character in a string. And at that point we can say "it points to a string".

[@soliveirajr]

When you re-assign the pointer to a new string literal, how can you be sure that the previous one was deallocated? Or it goes to some kind of pool and never gets deallocated?

[@PortfolioCourses]

String literals don’t really get deallocated. Where they are in memory ultimately depends on the compiler, but the compiled program has segments like the data segment where we may expect to see the string literals stored: en.m.wikipedia.org/wiki/Object_file

[@mgancarzjr]

You can test this yourself with g++ in Linux or in WSL. g++ -S input.cpp It will generate an assembly-language file input.s

[@saraiva407]

And can I create a string literal that uses special characters, like in char *s2="%s: %.2lf %.3lf ","something",M_PI,sqrt(2.0); ? Or is it too advanced for C compiler and I need to use some function like sprintf()?

[@mikechappell4156]

The only character you cannot embed in a traditional string is '\0' because it usually acts as a terminator. You might be able to include it, but C generally uses '\0' terminated strings in arguments. You could create a library that stores the length of a string in the first byte instead of using a terminator, but that forces a limit on the length of a your string and you'd need an entire library of functions to deal with them since stdio and stdlib both assume nul terminated strings. I think the C compiler can handle some simple math using direct constants but it can't evaluate functions. The compiler doesn't evaluate *printf arguments, the stdio library is responsible for that. You'd want to use sprintf for that if you wanted that evaluated.

[@gamethecupdog]

I want to get into C as an alternative to rust, but I've never broken through the basics yet. Do things that *read* strings implicitly deal with the differences between pointer and literal strings? Rust burned me with all that by having more string/string adjacent variants than I can count on two hands, and explicitly requiring the exact variant every time.

[@mgancarzjr]

It's going to depend on the function that deals with them. Some functions will read one char (1 byte) at a time until they reach a '0' character, and some will read a specified amount of bytes whose value you have to supply. Be very careful of both. For example, let's say you overwrite the final character of your char array. It's still a valid array, but a function expecting a '0' character will keep reading OR WRITING directly into memory until it hits a '0' if you pass it the starting address of your array.

[@StandardLoop]

Good video. White theme burning my eyes though 😁

[@cho_64rus]

How does this program call? I need this!

[@PortfolioCourses]

Sorry I'm not sure what you're asking Maksim. The code in this video is available here: github.com/portfoliocourses/c-example-code/blob/main/char_array_vs_string_literal_pointer.c. :-)

[@StephenBuergler]

Why isn't the type of the string literal const in the first place? why doesn't it make you cast away the const to assign it to a non-const pointer?

[@behzadabf]

i know this but they you describ, just perfect!👍

[@algorithminc.8850]

Good video. Subscribed. Cheers

[@mytech6779]

char *s2 ="abcd" ; // gets `warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings]` char const *s2 ="abcd" ; // does not get a warning, using g++ 13.2 -std=c++17 And there in lies the true answer.

[@exisfohdr3904]

I'm watching and following along. You declare that the following creates a character array. char s1[]="abcdef"; As per your description, it appears that you are forcing the string to break up into an array filled with individual characters. An array of 6 individual characters: ("a","b","c","d","e","f") I may be misunderstanding this, but that is how it comes across. Is this not what is happening?

[@almirf3729]

Awesome video, help me a lot... New sub!

[@PortfolioCourses]

Thank you Almir, I’m glad the video helped you out, and welcome aboard! :-)

[@neumanngregor]

what Editor or IDE do you use ? Looks neat and very simplified, i wanna give it a try too.

[@PortfolioCourses]

Xcode on MacOS

[@NikitaSafronov-y6i]

I have a question as well. Its weird question. We are not allowed to modify a string literal through a pointer. So this code will not work char *s2 = "abcdef"; s2[0] = 'X'; \\ ERROR but if we take a look at an other example char *strPlus (char *string1, char *string2) { int strlen1 = strlen(string1); int strlen2 = strlen(string2); int size = strlen1 + strlen2 + 1; char *str3 = calloc(size, sizeof(char)); // String literal has been created with 0's inside. for(int i = 0; i

[@PortfolioCourses]

That’s a great question. :-) In that case though, str3 is not pointing to a string literal, it’s pointing too dynamically allocated memory on the heap that calloc has given us. And we are allowed to modify that data. What makes it a pointer to a string literal is not that it’s a char* pointer, it’s having something like “a string” in double quotes like that, that’s what creates a string literal.

[@NikitaSafronov-y6i]

@@PortfolioCourses thank you very much for the reply. You have a such great commitment to this channel. I hope this channel will pay you back one day!

[@PortfolioCourses]

@@NikitaSafronov-y6i Thank you. 😀 I just love doing this channel so much and seeing all these people finding it helpful.

[@atussentinel]

If you got segfault when modifying a string literal, usually it's because the compiler sees the string literal and thinks it should not change, so the compiler stores the string literal's bytes in the text segment (of the output executable). Since text segment is mapped to read-only memory by OS, trying to write into it raises a segfault. If the compiler stores the string literal's bytes in the data segment (initialized static/global variable), it can potentially be modified without segfault at runtime. But anyway modifying a string literal is undefined behavior. Above is an example that results of "undefined behavior" is implementation-dependent. The memory location returned by calloc/malloc/realloc is not read-only.

[@marilynyballa809]

Ty I got my first divine because of you

[@PortfolioCourses]

You're welcome Marilyn! :-) Is a "divine" a type of grade, like getting an A? I've never heard the word used like that before. Congratulations! :-D

[@edenng8431]

Best C tutorial!!!

[@PortfolioCourses]

Thank you very much for the positive feedback Eden! :-)

[@tetsi0815]

If the code compiles, hasn't the compiler just allowed you to write the memory location? If I'm not mistaken, it's the runtime that gives you the error.

[@PortfolioCourses]

Because it’s undefined behaviour, a compiler creator can do whatever they like. They could have it produce code that allows you to write or not write to the string literal. The error is going to occur at runtime, and in practice the compiler designer is going to almost certainly just let the architecture dictate the behaviour. But because it’s undefined behaviour in the C standard, it’s ultimately up to the compiler, and we shouldn’t make an assumption about what will happen (unless we are ok with our program being less portable).

[@tetsi0815]

@@PortfolioCourses Maybe I just misunderstood what you're trying to say at 4:03. The compiler literally just compiled your code and you were allowed to run it. Then on runtime you got the error when you tried to write to memory location s2[0]. And it's not that the compiler (in that specific situation) could not see that you're trying to modify a string literal.

[@PortfolioCourses]

Yeah, the compiler did compile the code, but the C standard says it’s undefined behaviour to write to string literals, so other compilers could (more theoretically speaking) handle writing to string literals as they like, and they would still be valid standard compliant C compilers. That’s my only point really. Virtually all resources online describe undefined behaviours as things that are up the compiler because that’s a simple and accurate way to put it. There’s definitely more to the story as to why something is made undefined behaviour to begin with and how compilers will handle things in practice.

[@corprall]

So I get that they are different but why are they different? They seem like they should do exactly the same thing to me.

[@deacon9517]

How come s2 is printing the whole string instead of printing the first character since it's only pointing to the first character

[@PortfolioCourses]

Great question! :-) When we pass a pointer to a char to printf and we use %s as the placeholder, printf will just keep printing characters from that position in memory onwards until it encounters a null terminator character.

[@younessamr6802]

you could use de-assembler

[@Huapua]

What to do if you want to change the string literal on purpose? I suppose you use char * s1 then reassign s1 to your hearts content?

[@PortfolioCourses]

Great question Angelo! :-) I would copy the string pointed to by s1 into a char array using strcpy(), and then yes you can modify it to your hearts content after that.

[@wallaceCharlieMekimo]

sir can you help me with how can I read name initials from a column in an array?

[@PortfolioCourses]

I'm not sure I understand the problem exactly Wallace. There are a number of videos on this channel covering 2D arrays that might help, like this one for example: kzbin.info/www/bejne/kIazl4qwidGDmKc. :-)

[@thewasted338]

@PortfolioCourses Does this apply to c++ as well?

[@epiendless1128]

I just tried in Visual Studio c++. It literally wouldn't accept char *s="string". Flagged it as an error before I got as far as compiling. I had to make it _const_ char *s="string". Then it wouldn't accept s[3]='o', because it knew s[] was a constant. So this c++ IDE won't even let you make the error.

[@mgancarzjr]

It should compile if you use const_cast: const string *s1 = "hello"; char *s2 = const_cast(s1); s2[0] = 'a'; Will still result in a segmentation fault at runtime though.

[@mjsaedy6637]

Usung the term string in C is confusung. Maybe using char array and const char array is clearer?

[@PortfolioCourses]

I don't know... it may be a bit confusing because "string" is not a type in C, so much as a concept. But like it or not we have "strings" in C and need to refer to them as strings at some point. I think the key thing is to understand that a string is a sequence of characters with a null terminator as the last character, and that we have different ways of storing strings in C.

[@juniorrokudevelopertutoria3734]

Good clarification

[@chinglemba9136]

while taking char str1[]="abcde" and char* str2="abcde", why does sizeof(str1) outputs 6 and sizeof(str2) outputs 8, shouldn't the size of both strings be same?

[@PortfolioCourses]

Great question! :-) The strlen() function will give us the length of a string, but the sizeof() operator will give us the size in bytes. So if str1 is a char array that stores 6 chars (abcde + null terminator \0) and each char is one byte, that is 6 bytes total. If str2 is *really* storing a pointer to a char (the first char in the string), then it's really storing a memory address, which is 8 bytes on my system/compiler. sizeof(char *) should give us the same result back because it's giving us the size in bytes to store a pointer to a char. The video explains sizeof() more, you might find it interesting: kzbin.info/www/bejne/aKixlGRrbpdpjpY. :-)

[@atussentinel]

When you call sizeof() the content doesn't matter, only the type matters. so "sizeof(str1)" is equal to "sizeof(char[6])", which is 6. The size 6 is figured out by the compiler at compile-time. then "sizeof(str2)" is equal to "sizeof(char*)", which is 8 on a 64-bit system.

[@prabhu_0377]

"Gojo satoru" The string will end with '\o' after u? And, are white space and '\o' treated same while scanning?

[@PortfolioCourses]

The string will end with the null terminator \0, after u, yes. I'm not sure what you mean by "scanning", do you mean using scanf and similar functions? :-)

[@prabhu_0377]

@@PortfolioCourses yes,using scanf function to read the input.

[@prabhu_0377]

@@PortfolioCourses Thanks for answering.

[@einfacherkerl3279]

did you know you can use s2 like char array also?

[@akatsuki947]

if we use string literal to initialize char array like , char s1[] = "abcd"; Does it mean we use both stack memory and memory that stores string literal ?

[@PortfolioCourses]

Great question! :-) We shouldn't really do this because 'char s1' will declare a char-type variable on the stack called s1. It can store a char. But "abcd" is a string literal. We can't assign a string literal to a char variable (successfully). We would want to have: char *s1 = "abcd"; instead. In this case, s1 is now a type "pointer to a char" variable, and it exists on the stack. It will store the memory address of the first char in the string literal "abcd". Where exactly string literals are stored in-memory is up to the compiler, we don't know whether they are on the stack or somewhere else (e.g. there is a portion of memory set aside for the program source code itself).

[@akatsuki947]

@@PortfolioCourses ooh it was my typo i wanted to type s1 [] = "abcd" instead and thank you you still answered what you already clearly explained in the video 😂 my fault .

[@PortfolioCourses]

@@akatsuki947 Oh haha no worries, I thought maybe that was a typo. 🙂

[@flogger25]

What is editor that you use? Thanks in advance!

[@JefreySobreira]

Looks like Xcode

[@sumspiew]

Hi, what keyboard do you have? the sound is very satisfying.

[@PortfolioCourses]

I have an Apple keyboard, I think it's called a "magic" keyboard officially. 🙂

[@amosdotl6892]

what about *s1='X'; I don't understand why s2="string"; works.

[@PortfolioCourses]

‘X’ with single quotes is a character, but “string” with double quotes is a string (technically it’s what is called a string literal). :-)