C array creates a mysterious value

lucmove · 09-08-2022, 01:41 PM

Quote:

Originally Posted by astrogeek

You need to be very clear about that then. Your previous thread was all about finding an interpreter which understood C syntax in order to avoid using a compiler. Others here may be excused for thinking that you are using an interpreter.

Ah yes. It is a totally fair assumption.

But as it turns out, I ran into Code::Blocks and it's what I'm using now. Pressing F9 to build and run in 0.001s is good enough for me, and the IDE organizes everything in some kind of "project" arrangement that seems to be a thing in C. Macros and auto completion don't hurt either. You see, we can change attitudes as we learn more.

Anyway, I have it configured to use the Tiny C Compiler, but I also used GNU GCC and the results seem to be the same.

So I think I am compiling now, correct me if I'm wrong.

astrogeek · 09-08-2022, 02:07 PM

Quote:

Originally Posted by lucmove

But as it turns out, I ran into Code::Blocks and it's what I'm using now.
...
So I think I am compiling now, correct me if I'm wrong.

Good move! Now you are on an unobstructed path to C enlightenment!

I am not a user of CodeBlocks so cannot comment on the IDE specific aspects. I would encourage you to at least explore compiling your examples from a shell, to expose yourself directly to the process and simplicity of it all, but at your discretion.

Good luck!

rtmistler · 09-08-2022, 02:23 PM

You're learning that, "code can compile but still have bugs"

If this code blocks app provides you with a debugging capability, I suggest you explore it, or find some other suitable way (suitable for you) to debug code.

By the way you sort of have already found a first way to debug: printf(), where you learned that there was a surprise.

A debugger which allows you to break (halt) execution and examine variables, plus single step and continue to examine variables, will be a good thing to show you the depth of this type of problem.

Suggestions:
- use a debugger to output the initial array
- use a debugger to examine the address locations in memory for the array, and beyond - notice that you've modified undefined memory
- now add to that code and put another array definition right after the first one, then write into the supposed location [6] and see if it actually stomps on the next array, or not (all depending how smart the compiler may be)

Stuff like that. Explore. Or not. Your choice.

astrogeek · 09-08-2022, 02:53 PM

Quote:

Originally Posted by lucmove

the IDE organizes everything in some kind of "project" arrangement that seems to be a thing in C. Macros and auto completion don't hurt either. You see, we can change attitudes as we learn more.

The organization of files in C projects is "a thing in C" with aspects beyond the filesystem, or how convenient they are. You probably don't need to dive into the details at this point, but just something to put on your to-learn list, you will encounter it along the way (to borrow loosely from K&R):

In C any identifier (what you are thinking of as variable and function names) has two kinds of scope that you must consider - lexical scope and linkage.

Lexical scope is the region of source text within which the meaning of an identifier is understood.

Linkage determines the connections between objects and functions which may appear in separately compiled translation units (i.e. loosley files for now).

Scope and linkage, and therefore organization of source text, is used to expose or conceal information, among other things, and is an important aspect of the C language.

So, while your IDE of choice may provide a default or basic organization based on common C practices, it is not the only way to organize your code - you can do more with it if needed!

But that is a lesson for another day!

lucmove · 09-08-2022, 03:18 PM

Interesting. I don't understand it, but I almost do. I know I will.

dugan · 09-08-2022, 03:46 PM

In fairness to C, it does "warn" you:

Code:

❯ cat boundschecking.c 
#include <stdio.h>

int main() {
    int myNumbers[] = {25, 50, 75, 100};
    myNumbers[5] = 500;
    printf("%d\n", myNumbers[0]);
    printf("%d\n", myNumbers[1]);
    printf("%d\n", myNumbers[2]);
    printf("%d\n", myNumbers[3]);
    printf("%d\n", myNumbers[4]);
    printf("%d\n", myNumbers[5]);
}

❯ gcc boundschecking.c 
boundschecking.c:5:5: warning: array index 5 is past the end of the array (which contains 4 elements) [-Warray-bounds]
    myNumbers[5] = 500;
    ^         ~
boundschecking.c:4:5: note: array 'myNumbers' declared here
    int myNumbers[] = {25, 50, 75, 100};
    ^
boundschecking.c:10:20: warning: array index 4 is past the end of the array (which contains 4 elements) [-Warray-bounds]
    printf("%d\n", myNumbers[4]);
                   ^         ~
boundschecking.c:4:5: note: array 'myNumbers' declared here
    int myNumbers[] = {25, 50, 75, 100};
    ^
boundschecking.c:11:20: warning: array index 5 is past the end of the array (which contains 4 elements) [-Warray-bounds]
    printf("%d\n", myNumbers[5]);
                   ^         ~
boundschecking.c:4:5: note: array 'myNumbers' declared here
    int myNumbers[] = {25, 50, 75, 100};
    ^
3 warnings generated.

pan64 · 09-09-2022, 12:21 AM

Quote:

Originally Posted by lucmove

Thank you for the replies.

But I am very disappointed. I mean, how is that even allowed to happen? I've been using script languages for 20 years, languages that are often scoffed at while C is always regard in very high respect. But none of the scripting languages I have used would allow that nonsense. They would return NULL or the empty string, or maybe even throw an error. But the highfallutin C just makes up a random value out of thin air? That is mickey mouse.

That is again bad approach. It's better to say you're surprised because you didn't expect that. But it's actually C, and that's how it works. Don't assume anything and you won't be disappointed again.
C is a free language, you can do whatever you want (obviously only what is doable), you are not restricted in any way. Only the OS (kernel) and the available resources will restrain you.
From the other hand this freedom will lead to the problem you described, anybody can write useless code easily (obviously you can do it in any language). That's why we have additional tools to help identify those issues. The first one is the compiler itself, which will drop warnings or error messages if it can't process your code or if it finds something suspicious. The next one is probably the editor you use. And also we have static code analyzers and dynamic code analyzers to pinpoint those cases.

chrism01 · 09-09-2022, 01:09 AM

With C, always turn up the compile/link warnings to max and fix them all - you'll thank me later.

C is a very powerful language. Concomitantly, it expects the programmer to know what he/she is doing.

Remember it was originally invented to build Unix, so it's a sys programmer's lang

Michael Uplawski · 09-09-2022, 07:21 AM

Quote:

Originally Posted by chrism01

Remember it was originally invented to build Unix, so it's a sys programmer's lang

It is also a language which was built on the experience with older languages to meet the precise exigence of a couple of precise persons. That it came handy for an impressive bunch of developers worldwide proves some point or other, but not the pertinence of intentions. What alternative to this type of language would have existed at that time, as capable and flexible as 'C'? Seriously, I do not know. The modula type languages? Why would they (then) not have been sys programmers' languages?

I would even have guessed (probably wrongly) that an even stricter type-checking than in 'C' would be preferable for system programming. So why not Ada?

My guess is, that 'C' was small and quick to learn. That it is difficult to master is always for later in a developer's career.

I am off-topic. Feel free to say so.

EdGr · 09-09-2022, 07:48 AM

Quote:

Originally Posted by Michael Uplawski

What alternative to this type of language would have existed at that time, as capable and flexible as 'C'?

There was another language that offered similar capabilities as C - Mainsail. Its syntax was ugly; it remained proprietary; and its use died out after the 1980s.
Ed

dugan · 09-09-2022, 08:41 AM

AFAIK, this is the language C was based on:

https://en.m.wikipedia.org/wiki/B_(p...ming_language))

Of course, the language it was actually competing with was assembler. That would have been the other choice for writing the Unix kernel.

lucmove · 09-09-2022, 09:47 AM

Quote:

Originally Posted by Michael Uplawski

I am off-topic. Feel free to say so.

No, I don't think you're off-topic at all.