Have you tried reasoning about the program without thinking of C in particular, but with 'basic computer nature' (albeit with some standards, like 'bytes'), instead?

As in, merely thinking about bytes and memory and how this data is understood by the computer?

Instead of things like "strcpy", sit down and think about the arrays, the 'boxes', the values in the boxes, what they mean, what to do with them to achieve your goal, in pseudocode?

Thinking like that (although I'm not sure if I make much sense trying to get the point across) can unlock things you might not have thought about.

An example would be anagram solving.
The whole process of anagram solving, at least naively, gets a lot easier if one is aware of that letters are actually numbers, and numbers are sequential, so one could reason:

"Spaces are surplus to requirement. They need to go"
"Now that spaces are gone, are the strings of the same length? If not, then they cannot be an anagram, exit"
"Upper and lowercase characters have different numerical values, but mean the same thing, so, lower or uppercase everything"
"Now that both strings are in the same 'numeric space' since either lower or uppercase characters have been 'normalized', we can sort the strings as numbers in some order (ascending/descending)."
"Now that the strings are ordered, and we have made sure that both are the same length by an earlier check, we can loop over both strings on their individual character level"
"If the values of the characters (aka numbers) are different at any location, it is not an anagram, exit"
"If, after a complete loop, aka the length of both strings, which, again, are the same length, we didn't exit, then we must have an anagram"

Et cetera.
It's more difficult to arrive at such a solution if strings, data a computer uses is abstracted into something more difficult by the brain through the lense of some specific language.

Doing it 'generally' like this, makes the implementation via a programming language easier, when you have the agnostic principle, the process down, then all you need to do for the language implementation is look up the documentation to see what part of the language you need to use to achieve the effect you need.

You're probably already done this, in part, but it seems that you're putting "C" before the agnostic/pseudocode reasoning.

In this case, think about all the bits and pieces of functionality first and in what order they would make the most sense.

Things like a tokenizer. Things like how to deal with either a fixed buffer (which you might have to cycle out through if the input data is larger than the buffer), or something dynamic.
Steps that make following steps easier, etc.

If you can write the entire thing out for youself without a programming language, but still keeping "computer behavior/nature" in mind, then afterwards you can use pretty much any specific language.

P.S.:
Rubber ducky debugging IS a thing that works.
The web dev/agile folks can be a little loopy (and I'd get loopy too if I had to deal with the BS they need to deal with), and Rubber Ducky debugging seems to be associated with them, but yeah, it can be really useful.

Basically you talk to a rubber ducky, and you explain it your code, step by step, out loud.
The process of doing that can (and often does) catch subtle (or not so subtle) logical errors.
You know, the kind that makes one go "Wait a minute......DOOOOOHHH OF COOUUURSE, DUHHHHH!" when they're spoken out loud an thought about a bit.
It's a silly method, but it works, and can reduce frustration.

P.P.S.:
When you do write code, write it in a way that you coworker won't have the urge to disembowel you with a rusty spoon.

What? You have no coworker?
But, oh, you very much do. His name is "You,one or two weeks later."
He's a fragile guy, but wants to be your friend, so don't bully him with awful variable names and cryptic procedures.

Not entirely sure what you mean, but I suspect that was before you added the missing NUL byte, so you were getting undefined behaviour (see below).

All C string functions expect a NUL (aka 0) byte at the end of the array, so they can know when it ends (remember, you don't pass an array as such to strcpy, you pass a pointer to the first element). If you use

Then you're missing the NUL byte, and strcpy will keep going past the end of the array (this results in undefined behaviour, i.e., just about anything can happen. The thing which does happen may be influenced by seemingly unrelated things, like where you defined the array). In addition to declaring the size to add in the extra NUL element, you can use
Or

1 members found this post helpful.

Not disagreeing with accuracy. With a new learner I prefer to keep things fundamental, and have experienced this so very many times in my past that I feel it is a correct choice.

When one gives instruction to a class, they introduce one concept in basic form, ensure that the students grasp how to use that concept fully, and then introduce more advanced topics.

Apologies for the post which caused these points, it was too critical, and should have suggested that to keep things fundamental and simple, to use plain old printf().

I do feel that with any new learner, I would not introduce that topic until the person, or persons have learned more about: format modifiers, reading library function manual pages, understanding return values and errno, understanding file descriptors as well as file operations. After that point, I feel they would better understand what the definitions of stdout, stdin, and stderr are. Also, while there are reasons why that form of output is better due to system behavior related to stderr vs stdout, it is not a critical point at this juncture. How many times have you learned at a future point that there is a subtle distinction between one form over another, however you've actually appreciated it at that point, because you had sufficient background to understand the meaning of the topic?

@Geist, I have little to no idea what you are even on about - can you please not respond unless answering the questions asked directly, thanks.

I meant (and should have said instead) if I declare the array to be global rather than local. I just tried to reproduce what I was talking about and discovered that it was because I didn't specify the size of the array. So I think it's related to what you were saying above.

Anyway and for example, if I have the following;

I get;

But if I have;

I get;

Notice there's no extra string for "s1". Thanks ntubski.

vs
As far as I know the compiler will automatically add a null character when the 2nd initialization is used but not the first.

Basically the two strings are initialized sequentially in memory and printf terminates on a NULL character. Since s1 does not have a null character actually outputs both s1 and s2.

The compiler will automatically add a null character if you use the following.
As ntubski posted anything can happen if strings are not terminated correctly...

2 members found this post helpful.

I actually agree with exactly what Geist has written.

Not to answer in their part, however my interpretation is that they are telling you to not write the code first, but instead to perform design first.

If so, I feel this is an excellent suggestion. While the verbiage may have confused you, I suggest you try to re-read what they wrote, and especially the post script parts.

edit: ahh, I see the others beat me to it.

It's purely about the size not being specified. local/global has no bearing on this.

You specify size 6 but only list 5 values. The missing 6th and final element of the array will be set to 0, which just happens to be the same value as the character string terminator '\0' NUL.

When you don't specify a size, you only get the characters you explicitly list and no terminating '\0' character is placed at the end of your character array.

While char s1[6] = { 'T', 'e', 's', 't', ' ' }; and char s1[6] = { 'T', 'e', 's', 't', ' ', '\0' }; result in the same array contents in memory, the first one is IMO sloppy coding practice.

1 members found this post helpful.

While I obviously didn't phrase my point properly; I wasn't saying they were incorrect. I already had written some pseudocode for my program, to try and figure out the individual steps I need it to do, to get the desired result. I think those comments I wrote for that should be in the code in my OP. So their question about that is moot anyway. I also already understand what an array is as well, so adding extra verbiage just confuses things for me - unless there is no way around doing that to explain something (in which case, it is what it is, bad luck for me).

My point was that; it's harder to follow what's being said when confusing responses are made like the post we're talking about. It's much easier for me if replies are directly responding to my questions - which pretty much most, if not all posts, bar the post we're talking about have been.

Thanks for your help once again michaelk & GazL!

I still think you'd find strings easier to understand if you didn't put them into arrays. An array is quite a complex entity. They were developed to handle groups of numbers, where you essentially need random access. That's what your array index does: it allows you to access any element in the array as easily as any other. But text is always accessed sequentially, so you don't need an index at all, just a buffer of an appropriate size and a pointer. These are the pointers that all the C string functions use. It can be a pointer to the beginning of the buffer or to any character within it. So, for example, if you do a strcpy beginning at character 20 of your source buffer (i.e. buffer_pointer+20), your destination buffer will contain a left-truncated version of the original string (minus the first 19 chars). Similarly, if your destination buffer already contains text and the destination pointer does not point to the beginning of the buffer, you will be keeping everything before that pointer intact and adding the copied text to it. I find that much easier to visualise than using array indexes.

1 members found this post helpful.

Fair enough.

Regarding current queries: Do you understand the answers about strings sufficiently to move forward?

Can I ask what are the next intentions with the original problem?

Can I inquire if this visitation to strcpy and etc related to copying elements of the argv[] array into string variables? Yes, asking for a specific reason.

Ah, my apologies, I should have done that, yes.
My motivation was two fold, though. You seemed a bit frustrated, and my intent was to partly draw away from C to not deal with its quirks, and to focus on the actual underlying, language agnostic principles behind programming, which unlock much more than just C.

I was too obtuse, though (I often forget that people can't read my mind, makes me a bad provider of tutorials...), I see that now.

Still, even if it didn't answer your problem directly, it still could have acted as a springboard to a solution in a different timeline, perhaps.
Why? Because as the others have explained, your compiler happened to put the characters of both strings back to back in memory, and the first one lacked a termination character.

This is connected to the "values and numbers" thing I was writing about, not seeing the string as some programming language construct, but as numbers, the only thing a computer can deal with.
A computer has no concept of text. It was humans who decided that certain numbers mean a certain thing in a specific context, describing text.
Since this usage of numbers is kind of alien to the computer (which would probably prefer to just calculate with them, if it could) it needs to know when a string is over.
This was decided to be a null, zero.

However, this is not intuitive when one reasons from something like C as the starting point (documentation helps though). Starting from the language that was meant to abstract away the computers inner workings into something more humanlike makes it easy to never really think about the inner workings.

In this case, it all being numbers.
Programming, in its essence, is pretty much that.
"Everything is a number, at some location in memory, and we run operations on these numbers and put the result somewhere"

Everything a computer does is manipulating numbers. It cannot do anything else, no matter how we dress up this fact via fancy programming languages and syntactic sugars and whatnot.

Thing is, C happens to be still kind of "close" to how computers "think", so having this realization has better returns for C (and assembler) than, let's say, python.

So, yeah, I was trying to give you a 'direct solution seed' to problems in an indirect way, I guess.
I didn't mean to imply that you're not commenting, or that you use bad variable and function names, or that you don't plan, etc.
But to approach the problem in a way that makes using C easier, since C is so married to futzing with the memory 'manually'.

Theoretically, you would possibly end up reinventing C, or something similar if you were to write a programming language based on the way of thinking I suggested.
But yeah, I didn't put your wish to just have this particular problem solved on the proper priority.
You'll learn more slowly doing it backwards like this, from the 'high level' point of C, to the way the computer actually works, which, C, inconveniently for you at this point, is still very close to.
I wanted to turn you around the right way.

I said my piece now, though, and next time I'll just deliver the solution, if I do know it.

Well, okay, one more thing.
If you're interested, there's a pretty good book that does a much better job than I at trying to get this across, its called:
Code: The Hidden Language of Computer Hardware and Software, by Charles Petzold.

1 members found this post helpful.

Thanks again for your help Hazel. It's not really arrays, or the individual concepts themselves that are particularly difficult to understand. It's trying to put it all together (as I said before) that's proving not to be easy - particularly where pointers, arrays and loops are involved. As well as trying to understand code that uses functions I haven't got much experience using yet. I actually find pointers more difficult to understand than arrays - I do get what they are, but trying to understand how pointers actually work and using them is a different story. I also find arrays to be easier to visualise than pointers.

(I am responding to your whole post - I only omitted some of it to make this post shorter)

I think at least for the most part I do.

I haven't yet decided exactly what I going to do in regards to that (I haven't changed or added any code to my program yet either). I'd say I'll probably do something along the lines of what michaelk has suggested with his code, but I still what to practice strcat() and strtok() - although I'm not yet sure how to go about practising strtok() tho. I also therefore what to hopefully be able to write some pseudocode for michaelk's code, so I can step through it and understand each line of it. Then hopefully I can develop a coherent plan of exactly what code to write myself to get my program to upload the relevant string from it's config file in to an array to pass to ffmpeg.

Yes, in the sense that it was to try and understand what exactly strcpy() was doing in michaelk's code. And therefore how it could be useful in any code I write to get the same result as michaelk's code does (I haven't tested michaelk's code myself, but I trust that, and from what I can make of it, it does seem to get the desired result).

You're welcome to add anything about strcpy() or anything else, as I said; I haven't made any concrete "plan of attack" yet.

Not at this time unless you have further questions.

While I've had a little play around with strcat() and that seems to make more sense now; I cannot figure out strtok(), and I've tried to understand michaelk's code in post #32, but while I can see what it says, I really don't understand it. It's the same problem as before; the concepts make sense by themselves, but trying to put it all together is just proving impossible. So I really don't understand the code, and whatever I tried myself, just doesn't get even close to what I'm trying to do. I honestly couldn't even write something even remotely similar to michaelk's code.

So I don't know what to do now. Perhaps it's time to just forget about trying to finish the program.

I think you probably have got this program in too much of a mess to fix it now. But programming is addictive and you will get the yen to do this again when you see a problem that could easily be solved with a little program. Next time around, you will know much better what to avoid. In particular you should have learned not to cut and paste other people's code into a different context. Study their code by all means but then write your own.

I learned a lot by just reading sections of the GNU glibc manual.

strtok is a very clever little function for breaking a string up into substrings. The first time you call it, you give it a pointer to the beginning of the string, and the character(s) that acts as the delimiter. For example, to break a sentence up into words, use " " as the delimiter. On every subsequent call, you use NULL for the string pointer, so that strtok() knows it's the same string as before. And it will return the next word. But I wouldn't use this general-purpose parser function to parse command line arguments because there's a specialised function to do that: getopt().