Imagine the input being \t

1. c = ' '
2. last_char = ' ' and c = '\t' here c != last_char evaluates to true and a newline would be printed to stdout although no new word started

e.g.

This \tTest

I think having additional checks would fix this. I just recently started learning C so I am potentially missing something here..

#include <stdio.h>

int main() {
  int c, prev;
  prev = EOF;

  while ((c = getchar()) != EOF) {
    if (c == ' ' || c == '\t' || c == '\n') {
      if (prev != ' ' && prev != '\t' && prev != '\n') {
        putchar('\n');
      }
    } else {
      putchar(c);
    }

    prev = c;
  }

  return 0;
}

1. Index out of bounds:

// Initialize the histogram array with 0
  int i;
  for (i = 0; i <= BUFFER; ++i) 
  {
    histogram[i] = 0;
  }

2. Index out of bounds: -1, when input starts with spaces. Need add check like this:

        if (word_count_index > 0 && word_count_index <= BUFFER) // <-- add check
        {
          ++histogram[word_count_index - 1];

          if (histogram[word_count_index - 1] > max_word_count)
          {
            max_word_count = histogram[word_count_index - 1];
          }

          if (histogram_length < word_count_index - 1)
          {
            histogram_length = word_count_index - 1;
          }

          word_count_index = 0;
        }

Describe the bug
There are way too many warnings at the moment. The majority are caused by the unsequenced usage of some variables.

To Reproduce
Steps to reproduce the behavior:

1. Build the project with make
2. See warnings

Expected behavior
It should compile without unintended warnings.

Screenshots

Additional context
Add any other context about the problem here.

Is your feature request related to a problem? Please describe.
The exercise folder names doesn't use the same pattern.

Describe the solution you'd like
Make all exercise folders consistent.

Describe alternatives you've considered
Keep the current folder names.

Additional context
Solving this issue will improve the repo consistency.

Is your feature request related to a problem? Please describe.
The malloc function was introduced only in chapter 6. Before that, a custom alloc function was proposed.

Describe the solution you'd like
Replace malloc with custom alloc usage before chapter 6.

Describe alternatives you've considered
It is also possible to keep the current malloc approach, but the suggested solution is more appropriate.

Additional context
Also, it is important to note that it might be a good idea to not use the getline function provided by std. A custom approach would be better before chapter 6.

The exercise states that the program should replace input tabs with the proper number of spaces to reach the next tab stop. The tab stops are at fixed intervals (like every 4 columns or every 8) and the spaces should only fill up until the next stop, mimicking the behavior of actual tabs.

For example, given the input 'as[\t]df' where [\t] is a tab character, it should return 'as  df' with a tab stop of 4 (inserting two spaces, as there are already two characters) or 'as      df' with a tab stop of 8 (inserting six spaces), etc.

As currently implemented, this is not the case and the tab is simply substituted for 8 spaces.

Your solution for 1-12 seems to be redundant. Why not just do it this way?

#include <stdio.h>

#define OUT 0
#define IN 1

main() {
    int state = OUT;

    int c;
    while ((c = getchar()) != EOF) {
        if (c != ' ' && c != '\n' && c != '\t') {
            state = IN;
            putchar(c);
        } else if (state == IN) {
            state = OUT;
            putchar('\n');
        }
    }
}

Please correct me if I am wrong.

Describe the bug
The page numbering of each exercise doesn't match the actual book.

To Reproduce
Steps to reproduce the behavior:

1. Go to chapter_01/exercise_1_1/hello_world.c
2. See the last comment label as Exercise Page

Expected behavior
The exercise page should 8 , according to the book.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Maybe a better idea will be to just remove all the comments related with the exercise page.

Describe the bug
I changed the definition of char t[] = "first" to char t[] = "this", this should make the return value to 0, which is the first element of char s[].
However the return value is -1, since the while statement and the first if statement are not consistent.
After while (*s++ != '\0'), the first if statement must skip the first element of s[], which is the character t of "this".
Meanwhile, the increment of variable pos is premature. It cannot show the index 0 correctly also if the t[] appears at the first position of s[] as the same reason above.

To Reproduce
Steps to reproduce the behavior:

1. Modify char t[] = "first" to char t[] = "this".
2. Recompile this program.
3. Result on terminal should be -1.

Expected behavior
t[] = "this" should be matched char s[] = "this is first string" and the return value is 0.

Additional context
Workaround is provided below.

while (*s != '\0')                   /* removed ++ for consistency with the next if */
  {                                 /* ++pos deleted and moved to new position in which after the completion of if
                                                                      (*s == *t) */
    if (*s == *t)
    {
      first = s;
      second = t;

      while (*first++ == *second++)
      {
        if (*second == '\0')
          return pos;
      }
    }
    pos++;                                 /* new position of pos increment */
    s++;                                      /* increment of s for next loop */
  }

Describe the bug
A case like ")))(((" should not be considered balanced parenthesis.

To Reproduce
Steps to reproduce the behavior:

1. Run the program with input ")))((("
2. Program finishes with no reported errors

Expected behavior
Program should output "Error: unbalanced parentheses." or a more specific error.

Possible Solution
Stop iteration and return from checksyntax() once any of the bracket counts falls to negative.

In checksyntax(), replace

while (str[i] != '\0')

with

while (str[i] != '\0' && parentheses >= 0 && brackets >= 0 && braces >= 0)

When compiling each exercise with Make many warnings and errors appear. To make the CI workflow work properly these warnings and errors need to be fixed.

NOTE: Most likely the problem is caused by platform-specific dependencies.

The current solution for exercise 1.12 seems to not handle the case, where a couple of spaces and tabs goes one by one. It will currently print a new line for each space or tab.
Something like that would work in such case:

#include <stdio.h>

#define OUT 0
#define IN 1

int main(void)
{
  char c;
  int state;

  state = OUT;
  while ((c = getchar()) != EOF)
  {
    if (c != ' ' && c != '\t' && c != '\n')
    {
      putchar(c);
      state = IN;
    }
    else if (state)
    {
      putchar('\n');
      state = OUT;
    }
  }
  
  return 0;
}

Describe the bug
Expressions like "2 / 3" get treated as inline comments, so "/ 3" is removed from the final string leaving only "2".

To Reproduce
Steps to reproduce the behaviour:

1. Run the program with any input featuring a single forward slash e.g. a simple expression like the one above.
2. The output generated is not the desired one, having any division operation removed.

Expected behaviour
Everything after a single forward slash should not be considered a comment.

Possible fix
The conditional on line 77 is only really checking for one thing as the second part of the AND expression is exactly the same as the first.

      if (str[i] == '/' && str[i] == '/')

The second part should be str[i + 1] == '/' instead.

Describe the bug
The line array can either ends with \n\0 or \c\0 where \c is an arbitrary character; depending on whether or not the length of input characters exceed the MAXLINE limit or not.

With that, there are 2 bugs that were overlooked.

(1) In reverse function, setting int i_back = length(line) - 2 is incorrect since it's incorrectly assuming that the line ends with \n\0 in every scenario.

(2) In the case where the length of input characters exceed MAXLINE, the while loop inside get_line will terminate early by i < max_line_len - 1 check. However, there are input characters still remain in the iostream that did not get flush out, which causes output to be incorrect.

To Reproduce
Set MAXLINE to 10 temporally so that it's easier to test.

Here is a copy of my terminal:

clalexni :: ~ » cc 1-19.c && ./a.out
0123456789 // input
7654321089 // incorrect output, expecting 876543210

• Notice that the output starts at 7 instead of 8. In this case the input is 012345678\0; there is no \n as described in (1).
• Notice that the output ends with 89. This is due to iostream not getting flushed as described in (2).

Another example:

clalexni :: ~ » cc 1-19.c&& ./a.out
012345678 // input
765432108 // incorrect output, expecting 876543210

Expected behavior

clalexni :: ~ » cc 1-19.c && ./a.out
0123456789 // input
876543210 // Expected output

clalexni :: ~ » cc 1-19.c&& ./a.out
012345678 // input
876543210 // Expected output

If one of the expressions in an if-else are true, it will execute the associated statement(s) and skip the rest of the if-else.

If c is a newline character, Line 22 is true and Line 24 is executed. It then skips the rest of the if-else statment, including Lines 26-29. This means a newline does not set STATE to OUT.

In the book, Lines 22-25 are a separate if statement. Admittedly, they could have made it clearer by separating them with a line.

The buffer at the end of runtime doesn't contain the right values. For example if I input "-;" the buffer will contain ";;" instead of ";-".