Duda cr_read

[acrojas2]

Hola: Respecto a cr_read:

No entiendo la parte donde dice que la lectura debe continuar a partir desde donde quedó en el último llamado a un read. Según yo, esto implicaría guardar la "instancia" crFILE en alguna parte ¿entiendo bien esto?. Además, luego de un read ¿se deja el archivo sin cerrar? Saludos!

[Geeermy]

¡Hola Ale!

1) Que "parta desde donde quedó" significa que puedo leer un archivo de a partes y no necesariamente todo en un solo llamado a read. Por ejemplo, puedo ir llamando a cr_read para leer de a 2KB mi archivo -lo que implicará que vaya guardando de alguna forma en la estructura el punto en el que quedé o los bytes que he leído-, o bien podría directamente poner el tamaño del archivo para hacer una única llamada a cr_read que me llene el buffer con todo el contenido. Ese es el espíritu de esa parte de la definición.

2) Sí, implica guardar el crFILE* de los archivos abiertos en alguna parte, pero eso no tiene que ser realizado en las funciones de la API. Recuerda que al abrir un archivo el método cr_open te retorna la estructura, puedes asumir que queda como una instancia en main.c y después se la vas pasando a cr_read.

3) Sí, se deja el archivo sin cerrar. Por eso existe el método cr_close, ya que este último es el único que tiene esa función.

¡Espero que se entienda!

[jvlara]

Ahh ya, ahi si entendi, muchas gracias!. Pero me surgió otra duda más de C y de lo que significa big endian, ¿Como almaceno en buffer los datos, en el orden que vienen en el espacio de 2000 bytes del bloque indice o en el orden contrario? ¿Como los concateno?

[Geeermy]

@jvlara Lo mejor es verlo con un ejemplo. Asumamos que mi archivo tiene tres bloques de datos. Esto se vería de la siguiente forma:

p_0 -> bloque_1
p_1 -> bloque_2
p_2 -> bloque_3

buffer -> [bloque 1][bloque 2][bloque 3]

Básicamente, los vas pegando de izquierda a derecha según el orden de los punteros (primer puntero -de arriba hacia abajo- al primer bloque de datos, segundo puntero al segundo bloque de datos, etc.).

¿Se entiende? Para "concatenar", puedes asumir (aunque dependerá de tu implementación probablemente) que el buffer ya tiene el tamaño que necesitas, entonces siguiendo el mismo ejemplo de tres bloques completos puedes hacer algo así como:

unsigned char* buffer = malloc(sizeof(unsigned char) * 2048 * 3);
cr_read(file, buffer, 2048);
cr_read(file, &buffer[2048], 2048);
cr_read(file, &buffer[4096],2048);

Nota que cuando hago buffer[2048] y buffer[4096] obtengo el unsigned char de esa posición, por lo que uso el símbolo & para que retorne el puntero, que es lo que pide el método.

¡Espero que quede claro!

[jvlara]

Buena, ¡muchas gracias nuevamente!, se entendió perfecto. :tada:

[Geeermy]

IMPORTANTE: Lo hice de a tres bloques para ejemplificar cómo se llevaba a cabo el llenado, lo que respondí por primera vez en esta issue sigue aplicando, es decir:

unsigned char* buffer = malloc(sizeof(unsigned char) * 2048 * 3);
cr_read(file, buffer, 2048 * 3);

Debería resultar en el mismo buffer.

[FelipeApablaza]

Se debe permitir abrir más de un archivo a la vez con cr_open ?

[Geeermy]

@FelipeApablaza Pregunta en una issue nueva si no es relativa a esta, por favor. 😇

[FelipeApablaza]

aah perdón, es que mi duda sale por que en tu respuesta a @acrojas2 pones: *Sí, implica guardar el crFILE de los archivos abiertos en alguna parte** Entonces por eso :S me entró la duda

[Geeermy]

Ah bueno, entonces está bien. Sí, puedes tener más de uno:

// Estamos en main.c

f1 = cr_open(path_1,'r');
f2 = cr_open(path_2,'r');
...
cr_close(f1);
cr_close(f2);

Eso es algo completamente válido que puede darse en el flujo del programa. No debiese suponer un trabajo adicional en la librería.

[FelipeApablaza]

aah ok gracias!