Closed amalliar closed 3 years ago
Hello,
For the ft_is* functions, I think not testing outside of the 0, 256 range completely defeats the purpose of unit testing, it doesn't make sense to only test correct inputs as the errors often lie outside of the expected parameter range.
As for the putchar, it's really unfortunate that people hardcode the result just to handle this case :( Thus I have changed a bit the behavior of the Unicode test function (https://github.com/alelievr/libft-unit-test/commit/0fb2f5921d1b6b00be5635fa10f2d617e53bbb0d) and I hope this will prevent people from trying to hardcode the result in the future :)
Please note that I added a small section dedicated to [KO] in the readme which, I hope, will help to resolve this misunderstanding. It's also worth mentioning that you are not only evaluated by machines but also humans that can understand those circumstances and they should be discussed during the defense of your project.
@alelievr Hi! Thanks for a quick reply! Unfortunately the current version of the subject has ft_putchar_fd prototyped like this: void ft_putchar_fd(char c, int fd);
So the unicode test is no longer applicable. As for the ctype functions, well, maybe you're right.
@amalliar Yeah, I know. That's why I removed the unicode test for the fd version but not the normal putchar :)
On Linux machines these functions are realised as macros that are capable of handling some unicode characters. This causes confusion for new students making this project at home. Some of them even go as far as to hardcode the expected result into their functions... This needs to stop! 😟