Thread: Trying to create a simple array program

I just wanted to add my two cents in here and say that although you are clearly proud of your code in post #4, you did say that you wanted corrections:

Originally Posted by cyberjupiter

It works but there's one problem. The buffer should not accept more than 10 chars. For example, if I input "123456789ab", 'b' should be omitted because it exceeds 10 chars(I might be wrong here, please correct me). But it does not work like that.

And the information that you needed to know is that while the code may appear to be doing the right thing, it is only doing so incidentally. If you enter a particularly long string, the characters beyond the 9th one are written into the 10th, which is one element off the end of the array. While you have gotten lucky writing there, (and refused to listen when this was pointed out to you) all it took me was some particularly careless pasting of input and your program crashed.

Code:

C:\Users\jk\Desktop\sandbox>gcc -std=c99 -ggdb -o sandbox.exe sandbox.c

C:\Users\jk\Desktop\sandbox>gdb sandbox
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from sandbox...done.
(gdb) run
Starting program: C:\Users\jk\Desktop\sandbox\sandbox.exe
[New Thread 12116.0x1130]
[New Thread 12116.0x5e4]
This is a very long string let's see how we do. Does the program still work if I do not care about theoretical limits? fjmafj;ioawfjka'ifjakwmfFAO;JKFK M;JfwemfE;JKMFKOefk,EFKF,AMFAF';POKLFAMFkfawjfnawrfjaw49irt94ujfrkfwaokf

Program received signal SIGSEGV, Segmentation fault.
0x000000000040165a in main () at sandbox.c:27
27                          storage[i + newidx] = buffer[i]; //this code will always store buffer[] into the last newidx value of storage[]
(gdb) q
A debugging session is active.

        Inferior 1 [process 12116] will be killed.

Quit anyway? (y or n) y

Like everyone says, this does segfault somewhere.

So in short, I think you tested your attempt a little too lightly and got happy when the results were what you wanted. Generally, this is a poor approach to debugging -- you should trust code that you write the least of all.

If you really want to truncate lines that the user enters, then there is no reason to write anything in excess of what you want to keep anywhere. It is worth doing that correctly instead of risking a segmentation fault.

Further, in regard to writing a program to copy smaller arrays into bigger arrays, I have to agree with stahta01 and Asymptotic that the attempts so far are a bit wonky. At the very least, what would be the most helpful, especially for studying, I think, is an approach that is similar to what fgets() and strcpy() might do. This is because you would see it a lot in other places, mostly. The basic implementation for fgets() and strcpy() is both simple and tested. Plus, the sooner you get comfortable with what the standard C library can do and how it works, the better of a programmer you will be. So here is something you can study from. Some people would be happier with code that isn't broken up into functions, but let me tell you based on personal experience, this was way easier to debug.

Code:

C:\Users\jk\Desktop\sandbox>more sandbox.c
#include <stdio.h>
char * getBuffer(char *buffer, int n) {
   int i = 0;
   int ch;
   while (i < n - 2 && (ch = getchar()) != '\n' && ch != EOF) {
      buffer[i++] = ch;
   }

   /* detect longer lines and truncate them */
   if (ch != '\n' && ch != EOF) {
      while ((ch = getchar()) != '\n' && ch != EOF)
         /* intentionally blank */;
   }

   /* add back the \n we would have discarded */
   if (ch == '\n')
      buffer[i++] = ch;

   if (ch != EOF) {
      buffer[i] = '\0';
      return buffer;
   }
   else {
      return NULL;
   }
}

int copy(char *storage, char *buffer) {
   int i;
   for (i = 0; (storage[i] = buffer[i]) != '\0'; i++)
      /* intentionally blank */ ;

   storage[i] = '\0';
   return i;
}

int main(void)
{
   char buffer[BUFF_SIZE] = "";
   char storage[STORAGE_SIZE] = "";
   int cursor = 0;
   int m;

   for (m = 0; m < STORAGE_SIZE / BUFF_SIZE; m++) {
      if (getBuffer(buffer, BUFF_SIZE) != NULL) {
         cursor += copy(&storage[cursor], buffer);
      }
      else {
         break;
      }
   }

   puts(storage);
   return 0;
}


C:\Users\jk\Desktop\sandbox>gcc sandbox.c -ansi -DBUFF_SIZE=10 -DSTORAGE_SIZE=1000 -o sandbox.exe

C:\Users\jk\Desktop\sandbox>sandbox
test1
test2
test3
0123456789ab
This is a much larger string, let's see how we do.
^Z
test1
test2
test3
01234567
This is

I hope this helps, and in the future, try to extend a little more patience (belief?) when someone tries to tell you that something is wrong.

Further, in regard to writing a program to copy smaller arrays into bigger arrays, I have to agree with stahta01 and Asymptotic that the attempts so far are a bit wonky. At the very least, what would be the most helpful, especially for studying, I think, is an approach that is similar to what fgets() and strcpy() might do. This is because you would see it a lot in other places, mostly. The basic implementation for fgets() and strcpy() is both simple and tested. Plus, the sooner you get comfortable with what the standard C library can do and how it works, the better of a programmer you will be.

I said I wanted to avoid using any str functions because I wanted to implement some code without using those functions. The problem is that you assume I will always write code without using the standard library, which is wrong. I do realize how they work, I just did not want to use them because I wanted to learn something else.

Some people would be happier with code that isn't broken up into functions, but let me tell you based on personal experience, this was way easier to debug.

I choose not to for that certain code. You can go with as much function you want, your choice is not mine.

and in the future, try to extend a little more patience (belief?)

Maybe you could stop assuming what someone else is trying to do?

Well, the saddest thing here is that people thought that certain code is going to be used in production whatsoever. When I insisted on using mine, some people made this thread looks like a competitive programming contest. I clearly stated "a simple array program" because I wanted help to store certain text into a certain storage. I never said it was some code for some software development. I came up a solution(not a good one, I know), which at least satisfied me. I realize the shortcomings of my code, the improvement that can be done, and how buggy the program is. I also realized I should put error checking, bla bla bla bla, "insert your feature which I don't even want here".

#1 explained everything I need in my code. No more, no less.

Honestly, yeah you guys are excellent in fixing buggy code. However you guys failed to understand what I was trying to do. I do appreciate that some people here spent time writing a more "perfect version" of the original code(which I don't even need because those things are not within the requirement of my code)

Code:

C:\Users\User\Desktop>gcc codeThatDoesntSatisfyThem.c -o test

C:\Users\User\Desktop>test
code
that
they
dont
like
because
it
does
not
suit
them
^Z
code
that
they
dont
like
because
it
does
not
suit
them

@cyberjupiter, we can't force you to do things in ways you don't want to, we are just offering advice. Programming alongside other people isn't easy, so we sometimes step on our own feet while trying to teach newcomers how to code. And remember, this is a message board, not programming assistance site. Read the responses you care about, ignore those you don't and don't get worked up about such things.

Originally Posted by userxbw

Code:

userx@~/bin <> ./a.out And the information that you needed to know is that while the code may appear to be doing the right thing, it is only doing so incidentally. If you enter a particularly long string, the characters beyond the 9th one are written into the 10th, which is one element off the end of the array. While you have gotten lucky writing there, and refused to listen when this was pointed out to you all it took me was some particularly careless pasting of input and your program crashed. 
And the information that you needed to know is that while the code may appear to be doing the right thing, it is only doing so incidentally. If you enter a particularly long string, the characters beyond the 9th one are written into the 10th, which is one element off the end of the array. While you have gotten lucky writing there, (and refused to listen when this was pointed out to you) all it took me was some particularly careless pasting of input and your program crashed. 
Segmentation fault

Who said I was going to put more than 10 chars at a time?

@cyberjupiter, we can't force you to do things in ways you don't want to, we are just offering advice. Programming alongside other people isn't easy, so we sometimes step on our own feet while trying to teach newcomers how to code. And remember, this is a message board, not programming assistance site. Read the responses you care about, ignore those you don't and don't get worked up about such things.

Seriously, I was appreciating the reply, I tested their code, and I found their code is way better. The problem arose when I said "mine is good enough". They presumably think I will stay with that kind of code forever.

Wow I figured I would get a response like that. Why would you want to learn something from a program that has a such an obvious mistake in it? You'll just do it again when the code is more important.

True. Your code in #16 was the most perfect. And I will definitely look it up when I need it.