In a language named vJass I can do this:
function Initialization takes nothing returns nothing
string array s
call read(s[1])
call read(s[2])
call print(s[1] + " " + s[2])
endfunctionIt takes two strings from user and prints them.
I am totally confused how I can do this in C...
Its simple really. First, create the memory for your c-strings and then read into them.
One method
#define ARR_SIZE 100
char cstring1[ARR_SIZE];/*100 character array*/
char cstring2[ARR_SIZE];/*100 character array*/
fgets(cstring1, ARR_SIZE, stdin);/*read into cstring1 from the stdin*/
fgets(cstring2, ARR_SIZE, stdin);/*read into cstring2 from the stdin*/Its simple really. First, create the memory for your c-strings and then read into them.
One method
#define ARR_SIZE 100 char cstring1[ARR_SIZE];/*100 character array*/ char cstring2[ARR_SIZE];/*100 character array*/ fgets(cstring1, ARR_SIZE, stdin);/*read into cstring1 from the stdin*/ fgets(cstring2, ARR_SIZE, stdin);/*read into cstring2 from the stdin*/
And clean them straight after declaration!
memset(cstring1, '\0', sizeof(cstring1));
memset(cstring2, '\0', sizeof(cstring2));
And clean them straight after declaration!
memset(cstring1, '\0', sizeof(cstring1)); memset(cstring2, '\0', sizeof(cstring2));
That's unnecessary if the very next thing you're doing is filling the string (as in gerard's example). It's also usually excessive when you can create a valid string by assigning a null character to the first element:
cstring1[0] = '\0';
cstring2[0] = '\0';And clean them straight after declaration!
memset(cstring1, '\0', sizeof(cstring1)); memset(cstring2, '\0', sizeof(cstring2));
The only reason I could see for doing this is using the c-strings in a strcat() function call but as Narue said set the first element to '\0' and your fine.
Its called defensive programming.
fgets reads upto a max size, not fill it.
What happens when fgets gets swapped or moved somewhere and you forget. Im just suggesting good habits.
Its called defensive programming.
fgets reads upto a max size, not fill it.
What happens when fgets gets swapped or moved somewhere and you forget. Im just suggesting good habits.
What Narue posted is good programming practices. The c-string's first element is set to '\0' indicating an empty c-string.
Its called defensive programming.
It's called being an idiot.
fgets reads upto a max size, not fill it.
It's very rare where you need to fill beyond the null character because the null character acts as a sentinel for algorithms that expect a C-style string. Thus there's no point writing a null character in every element when simply doing it with the first element is sufficient.
What happens when fgets gets swapped or moved somewhere and you forget.
In your "defensive programming" case, what can only be called a grievous logic error is silently hidden. If you forgot that the string is no longer being populated, you're not likely to realize that it will always be an empty string. In this case, you're making things harder on yourself as well as prematurely pessimizing the code with unnecessary operations.
Without the initialization, a good compiler (or lint) will throw a warning about uninitialized use.
I can only see one case where zeroing the c-string would matter. If you were considering a character array(not a c-string) then it might make sense to initialize the array elements to zero but that's not the case here since the original question stated C strings.
Im debating the fact that Narue claimed cleaning strings were excessive regardless of the method. Either shes just being harsh or doesn't know about defensive programming, if you're on a large project a coder might come in later and write to a string using custom methods, forgets the null and eventually something may overflow and do some damage, granted this would be taking it to the extreme but sometimes it is a good idea and besides whats 100 bytes going to slow down, if we want to get picky I wouldnt use a define for the fgets.
If later on you change the declaration to [ARRAY_SIZE+1] to accompany the terminating null, and forget about fgets (it might be someone else), fgets is reading in one short which may be undesirable...
Im debating the fact that Narue claimed cleaning strings were excessive regardless of the method. Either shes just being harsh or doesn't know about defensive programming, if you're on a large project a coder might come in later and write to a string using custom methods, forgets the null and eventually something may overflow and do some damage, granted this would be taking it to the extreme but sometimes it is a good idea and besides whats 100 bytes going to slow down, if we want to get picky I wouldnt use a define for the fgets.
If later on you change the declaration to [ARRAY_SIZE+1] to accompany the terminating null, and forget about fgets (it might be someone else), fgets is reading in one short which may be undesirable...
I don't see how setting a c-string's entire contents to zero will prevent this..If the programmer is relying on zeros to indicate the c-string length then your really being reckless.
And 100 bytes, what if the string is 10k bytes or 100k bytes?
For 100k then yes it would be better to just set the first byte to a null.
In this it does the same job, in others it may not.
I would do:
fgets(buffer, sizeof(buffer), file);Im debating the fact that Narue claimed cleaning strings were excessive regardless of the method.
Well, if you mean populating all elements with a null character then that rather limits the number of methods, doesn't it? The best way in such a case for an array, and those cases do exist, would be to let the compiler do it:
char cstring1[ARR_SIZE] = {0};
char cstring2[ARR_SIZE] = {0};But I still disagree that it's necessary, defensive or not.
Either shes just being harsh or doesn't know about defensive programming
I'm well aware of defensive programming. What you're doing is not defensive, it's offensive (the bad smell variety). See further quoted replies...
if you're on a large project a coder might come in later and write to a string using custom methods, forgets the null and eventually something may overflow and do some damage
Following that logic, it's impossible to write robust code because some idiot coder might follow you and break it. While your defensive programming technique is valid, this isn't the use case for it.
and besides whats 100 bytes going to slow down
I don't know, but neither do you. It's rather hypocritical that you're advocating defensive programming yet immediately turn around and make unwarranted assumptions.
if we want to get picky I wouldnt use a define for the fgets.
This we can agree on.
It's called being an idiot.
Idiot is an inaccurate statement and unacceptable for use.
The word idiot comes from two Greek words which mean "out of mind."
It has become a commonplace expression in our more recent culture on the planet.
Apparently, it was also considered an unacceptable practice when condemned by the Nazarene about 2 millenium previous warning of a very severe penalty for those who wish to call their fellow human beings such terms.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.