pasqualerossi / 42-school-exam-rank-03

2nd 42 School Exam

🧝 42 Piscine Student

Piscine Modules
Piscine Guide C00 C01 C02 C03 C04 C05 C06 C07

Piscine Exams
Piscine Exam Guide Level 0 Level 1 Level 2 Level 3

🧛 42 Common Core Student

Common Core Projects
Guide Circle 0 Circle 1 Circle 2 Circle 3 Circle 4 Circle 5 Circle 6 Common Core Guide Libft Born2BeRoot MiniTalk Philosophers NetPractice Inception Transcendence Printf So_Long Minishell Cub3D IRC Get_Next_Line Push_Swap C++ Modules

Common Core Exams
Common Core Exam Guide Exam Rank 02 Exam Rank 03 Exam Rank 04 Exam Rank 05 Exam Rank 06

42-school-exam-rank-03's Issues

Memory leak

• At the first condition, you have to free buffer variable and then you can return

Order of variable (Get-next-line)

change the order of declaration varaible ( len before dst)

char	*ft_strdup(const char *src)
{
	size_t	len = ft_strlen(src) + 1;
        char	*dst = malloc(len);
	
	if (dst == NULL)
		return (NULL);
	ft_strcpy(dst, src);
	return (dst);
}

BUFFER_SIZE

The subject tells "BUFFER_SIZE=xx, which has to be used as the buffer size for the read calls", but you use 10000 as the fixed size of the buffer. Is it authorized at the exam ?

the signature of the function in the ft_printf.c repo is not correct

Line 26 shows this:

-int	  ft_printf(const char *format, ...)

but is not correct, as it should be

-int	  ft_printf(const char *format, ... )

with a space also AFTER the three dots.

I know it could be a small problem, even if your readme shows the real signature from the subject, but in the repo its wrong, and this wrong version also works in the 42 grademe program https://grademe.fr/ so its really a hidden error.

It is frustrating because today I gave the exam, and It would not specify that the problem was in the signature of the function, as it would show traces listing the tests so it made solving the issue really confusing.

As always, reading the subject in the minute details would have saved me and other from this frustrating situation, hope this helps a bit other students!

leaks in the code you provide

#include <stdlib.h>
#include <unistd.h>

char *get_next_line(int fd)
{
int i = 0;
int rd = 0;
char character;

if (BUFFER_SIZE <= 0) 
    return (NULL);
char *buffer = malloc(100000);  // check before the current BUFFER_SIZE and then malloc
while ((rd = read(fd, &character, BUFFER_SIZE - BUFFER_SIZE + 1)) > 0)
{
    buffer[i++] = character;    
    if (character == '\n')     
        break;                  
}
buffer[i] = '\0';             
if (rd == -1 || i == 0 || (!buffer[i - 1] && !rd))
    return (free(buffer), NULL); 
return (buffer);

}

iteration before '\0'

Hi,
I think you i++ one time more line 24.
*on get_next_line.c

Get_next_line not working

Hello, your get_next_line solution is not working for us in the Exam rank 03 at 42 Prague.

This code does not work for GNL new instructions (Rome 42 campus, since May 2023)

Here are the new instructions for get_next_line in the rank 03 exam at 42 Rome:

"- What we call a "line that has been read" is a succession of 0 to n characters that end with '\n' (ascii code 0x0a) or with End Of File (EOF).

• '\n' should be included if there is one

• When you've reached the EOF, you must store the current buffer in a char * and return it.

• If the buffer is empty you must return NULL.

• In case of error, you must return NULL.

• In case of not returning NULL, the pointer should be free-able.

- Your program will be compiled with the flag -D BUFFER_SIZE=xx, which has to be used as the buffer size for the read calls in your functions.

• Your program can be compiled with AND without the -D flag

• Your function must be memory leak free

• When you've reached the EOF, your function should keep 0 memory allocated with malloc, except the line that has been returned.

• Calling your function get_next_line in a loop will therefore allow you to read the text available on a file descriptor one line at a time until the end of the text, no matter the size or either the text or one of its lines

• Make sure that your function behaves well when it reads from a file, from the standard output, from a redirection, etc...

• No call to another function will be done on the file descriptor between 2 calls of get_next_line.

• We consider that get_next_line has an undefined behavior when reading from a binary file."

The instruction in bold is new compared to this current version.
Unfortunately, even after implementing a ifndef in the .h file in order to accommodate this new rule, the exam is consistently failed.
Some classmates have suggested that BUFFER_SIZE cannot be modified. Perhaps this can be a clue in solving why we are currently unable to pass this exam with the new rules?

Thanks a lot!