Maximum size of a character array

Question

Has some maximum quantity, that a variable of type char character support?

For example, I could use char texto[1000];?

#include <stdio.h>
#include <stdlib.h>
#include <locale.h>

int main(){

    setlocale(LC_ALL, "Portuguese");

    FILE *file;
    file = fopen("copyright.txt", "r");

    char pagina1[928];

    while(fgets(pagina1, 928, file) != NULL){
        printf("%s", &pagina1);
    }
    fclose(file);
return 0;
}

Answer 1

The answer to this question is not so obvious, and understanding what happens implies understanding what you are doing.

First: a variable of type "char" behaves a single byte, that for the Latin alphabet and Arabic digits, usually equates to a single character - (but this depends on the coding used.)

The variable you are using is a char[] - That’s a character pointer. What goes "inside" of the variable itself is a memory address, which in normal Pcs is usually an address of 8 bytes (64bit); The number that goes between the brackets, as in char minhavariavel[1000], is a number of bytes that the compiler leaves in memory for its variable. The maximum value depends on the CPU architecture (on the first 16bit x86 PC as well as on the 8-bit machines, this number was 2 16 = 65536, for example). The maximum size for this depends on the structure of the program as defined by the compiler, and with the limit given by the operating system - on Pcs with modern systems, one can think of around 1MB for this. I just tested here, 5MB works, 10MB, the program fails, on a 64bit Linux)

On a PC running a 64-bit S.O. this number is limited by the compiler, because of the structure it uses to organize the program in memory, but if the memory is requested from the Operating System, at exercution time, the size of a vector of char can be as big as you want with the computer memory limit. (Nm PC with 4GB, you separate a 300-400MB for the operating system and programs it uses, and could have a process using 3.6GB without sweating too much. If you are manipulating text files, as it is, roughly corresponds to the text equivalent to 1000 bibles) -

But if you have a program that will work with that amount of data in memory in general it is worth using a dynamic memory allocation mechanism.

In short - no, there is no limit to the amount of bytes you can allocate to a type vector char , except the memory of your computer.

And the error you are experiencing of "unable to read file", is probably related to the error in calling printf as I pointed out in the comment is just take the & the most.

Answer 2

The guy char always has 1 byte size, and therefore a character, as long as it is an encoding single byte (the char do not support characters multibyte).

A sequence of char may have the maximum amount of bytes available in the address allowed by the operating system and that is free at that time, but depending on where this sequence is allocated may be a problem.

In your example you are allocating to stack, that under normal conditions, depending on the operating system, has 1 MB available only, for every application. She is a very dynamic memory (to my sadness many consider her static) and her management is automatic, then the part used effectively grows and decreases frequently, but it is not convenient to abuse, if it is to allocate very large vectors it is better to opt for the heap, unless you know well what you are doing or understand the tricks to grow the stack beyond standard size, understanding the consequences of this. 1KB or less is not to be a problem in such a simple example, could if you had a recursive call, or had other large components on the call stack.

In the heap you can allocate several megabytes or even gibabytes without major problems, but if you pass the amount available in RAM there will be the swap memory and the application will be extremely slow, so contain the use, but this is a sense until obvious. On 32-bit architectures the maximum addressable is usually 2GB. In 64 bits it is virtually impossible to get to pop the addressing, but it can pop the RAM (traditional, soon we will have the persistent non-volatile memories of great capacity, there is another story, much of what we have learned to date will not be worth more :) ).

Apart from this "the program not wanting to read the file" is too vague to help. But the code presents some problems, and this is what should be preventing normal execution.