42school / norminette

Official 42 norminette

norminette for 42 schools

Install

Requires python3.8+ (3.8, 3.9, 3.10, 3.11)

Directly inside your global commands

Install using pip.

python3 -m pip install --upgrade pip setuptools
python3 -m pip install norminette

Install using pipx.

sudo apt update
sudo apt install python3-setuptools
sudo apt install pipx
pipx install norminette
pipx ensurepath

Install using a virtual environment.

python3 -m venv $HOME/.venv
source $HOME/.venv/bin/activate
python3 -m pip install --upgrade pip setuptools
python3 -m pip install norminette
echo "export PATH=\$PATH:$HOME/.venv/bin" >> $HOME/.${SHELL##/bin/}rc
deactivate

To upgrade an existing install, use

python3 -m pip install --upgrade norminette

Usage

• Runs on the current folder and any subfolder:

norminette

• Runs on the given filename(s):

norminette filename.[c/h]

• Prevents stopping on various blocking errors:

norminette -d

• Outputs all the debug logging:

norminette -dd

Docker usage

docker build -t norminette .
cd ~/42/ft_printf
docker run --rm -v $PWD:/code norminette

If you encounter an error or an incorrect output, you can:

• Open an issue on github
• Post a message on the dedicated slack channel (#norminette-v3-beta)

Please try to include as much information as possible (the file on which it crashed, etc)

Feel free to do pull requests if you want to help as well. Make sure that run_test.sh properly runs after your modifications.

Run for development

This new version uses poetry as a dependency manager.

If you want to contribute:

poetry install

# Run dev norminette
poetry run norminette

# Or... with virtual env
source .venv/bin/activate
norminette

# Run tests
poetry run pytest

norminette's Issues

Comments in function bodies are not detected

The whole thing seems to not check comments.
All of these things pass norminette3 as OK.
Even though the PDF states that it's not allowed to use comments inside functions' bodies.

Someone pointed out that this then might have to be checked by the evaluator, but that's not mentioned in the pdf, so I am assuming that is not the case.

int	main(int i/*comment in function parameters*/
		, int x)// comment after function declaration
{
	int	num1;
	int	num2;/* comment in function body not at end of line */// comment in function body
	/*
		Multi line comment in function body

	*/
	num1 = 25;
	num2 = 0;
	while (num2 != 25 && num2 != 25/* comment in while */
		&& num1 < 60)
	{
		num2 += 2;
		num1++;
	}
	return (0); // single line comment
}

Incorrect copyright notice in license file

The LICENSE file contains this copyright notice:

Copyright (c) 2018 The Python Packaging Authority

But it doesn't reflect norminette authors.

Functions indentation

As said in the Norm 2.0.2 :

Your functions’ identifiers must be aligned within a same file. Same goes for header files.

But in any file, we have to put one and only one tabs before declaration.

For example, in this file :

/* ************************************************************************** */
/*                                                                            */
/*                                                        :::      ::::::::   */
/*   ft_strtrim.c                                       :+:      :+:    :+:   */
/*                                                    +:+ +:+         +:+     */
/*   By: mescande <[email protected]>                    +#+  +:+       +#+        */
/*                                                +#+#+#+#+#+   +#+           */
/*   Created: 2019/04/05 15:37:49 by mescande          #+#    #+#             */
/*   Updated: 2019/11/07 19:13:41 by mescande         ###   ########.fr       */
/*                                                                            */
/* ************************************************************************** */

#include "libft.h"
#include <stdlib.h>

static int	testsep(char *str, const char *set)
{
	size_t	len;
	size_t	n;

	len = ft_strlen(set);
	n = 0;
	while (n < len)
		if (*str == set[n++])
			return (1);
	return (0);
}

char		*ft_strtrim(const char *s1, const char *set) //this is ligne 29
{
	char	*res;
	char	*cpy;
	size_t	len;

	if (s1 == NULL)
		return (NULL);
	cpy = (char *)s1;
	while (*cpy && testsep(cpy, set))
		cpy++;
	if (!*cpy)
		return (ft_memalloc(1));
	len = ft_strlen(cpy);
	while (testsep(cpy + len - 1, set))
		len--;
	res = ft_strnew(len);
	if (res == 0)
		return (0);
	res = ft_memcpy(res, cpy, len + 1);
	res[len] = 0;
	return (res);
}

We've got this error :

ft_strtrim.c: KO!
	TOO_MANY_TABS_FUNC    (line: 29, col: 9):	extra tabs before function name

Infinite loop with missing semicolon

If a return statement lacks his semicolon, the norminette will loop indefintely, searching for the semicolon
It is caused by rules/is_expression_statement.py lines 35-36

norminette/norminette/rules/is_expression_statement.py

Lines 35 to 36 in 116d03b

	while context.check_token(i, "SEMI_COLON") is False:
	i += 1

Demo code:

int main(void)
{
	return 42
}

Multi-line function arguments

Norminette is inconstant with how it treats multi-line function arguments, as when using this header file:

#ifndef FT_EXAMPLE_H
# define FT_EXAMPLE_H

void	ft_foobar(
	char really_long_variable_name_for_the_purposes_of_this_example,
	char the_second_one_wouldent_fit_on_the_same_line
);

#endif

ft_example.h: KO!
TOO_FEW_TAB (line: 5, col: 1): Missing tabs for indent level

This can be address by adding more tabs in front of the arguments:

void	ft_foobar(
			char really_long_variable_name_for_the_purposes_of_this_example,
			char the_second_one_wouldent_fit_on_the_same_line
);

However then the ); also has to be moved:

TOO_FEW_TAB (line: 7, col: 1): Missing tabs for indent level

This violates a norm rule so its not a solution:

NO_SPC_BFR_PAR (line: 7, col: 13): Extra space before parenthesis (brace/bracket)

The only working 'configuration' is to move the ); one line up:

void	ft_foobar(
			char really_long_variable_name_for_the_purposes_of_this_example,
			char the_second_one_wouldent_fit_on_the_same_line);

ft_example.h: OK!

All of this however is not an issue in the function it self:

#include "ft_example.h"

#include <stdio.h>

void	ft_foobar(
	char really_long_variable_name_for_the_purposes_of_this_example,
	char the_second_one_wouldent_fit_on_the_same_line
)
{
	printf("%c%c",
		really_long_variable_name_for_the_purposes_of_this_example,
		the_second_one_wouldent_fit_on_the_same_line
	);
}

ft_example.c: OK!

As far as I can see the first header file 'configuration' should not be violating any norm-rules, is the most readable and is consistent with how its setup for functions in c files.

Multiple errors with function pointer declaration

The lines 96-97 contain my function pointer declaration:

These are encounter errors:

Thanks

Missing space after keywords inconsistent AND allows for bypass of 80 char line limit

Describe the bug
On an initial norme error:

Norminette wants a space between void and *. Okay, so far so good:

But as you can see, I go 1 character over the 80 char limit.
BUT there is no error being given:

Erroneous code

int	philo_loop(t_philo *philo)
{
	int			i;

	i = 0;
	philo->last_eat = timestamp_get(philo->settings);
	if (pthread_create(&philo->thread, NULL, &philo_monitor_local,
			(void*)philo) != 0)
		return (0);
	while (philo->settings->num_eat == -1 || i < philo->settings->num_eat)
	{
		philo_take_forks(philo);
		philo_eat(philo);
		philo_sleep(philo);
		philo_think(philo);
		i++;
	}
	if (philo->settings->num_eat != -1 && i == philo->settings->num_eat)
		return (EXIT_SUCCESS);
	return (EXIT_FAILURE);
}

Also funny enough, I don't get "You need a space after a keyword" on this example code:

(Line 102)

So possible there are 2 bugs at play here?

Additional infos

• OS: Ubuntu 20.04.2 LTS
• python --version: Python 3.8.5
• norminette -v: 3.1.0

Additional context

Endless loop and crash

Norminette doesn't like the following line(s) of code.
Endless loop:

void	read_config(t_list **lights, t_gui gui){}

Runs fine:

void	read_config(t_list **lights, t_gui gui)
{}

Norminette crashes on:

void	read_config(t_list **lights, t_gui gui)

With error message:

Traceback (most recent call last):
  File "/home/joppe/.pyenv/versions/3.9.0/bin/norminette", line 33, in <module>
    sys.exit(load_entry_point('norminette==3.0', 'console_scripts', 'norminette')())
  File "/home/joppe/.pyenv/versions/3.9.0/lib/python3.9/site-packages/norminette-3.0-py3.9.egg/norminette/__main__.py", line 87, in main
    registry.run(context, source)
  File "/home/joppe/.pyenv/versions/3.9.0/lib/python3.9/site-packages/norminette-3.0-py3.9.egg/norminette/registry.py", line 58, in run
    ret, jump = self.run_rules(context, rule)
  File "/home/joppe/.pyenv/versions/3.9.0/lib/python3.9/site-packages/norminette-3.0-py3.9.egg/norminette/registry.py", line 20, in run_rules
    ret, read = rule.run(context)
  File "/home/joppe/.pyenv/versions/3.9.0/lib/python3.9/site-packages/norminette-3.0-py3.9.egg/norminette/rules/is_func_prototype.py", line 189, in run
    ret, read = self.check_func_format(context)
  File "/home/joppe/.pyenv/versions/3.9.0/lib/python3.9/site-packages/norminette-3.0-py3.9.egg/norminette/rules/is_func_prototype.py", line 173, in check_func_format
    i = context.skip_nest(i)
  File "/home/joppe/.pyenv/versions/3.9.0/lib/python3.9/site-packages/norminette-3.0-py3.9.egg/norminette/context.py", line 287, in skip_nest
    c = self.peek_token(pos).type
AttributeError: 'NoneType' object has no attribute 'type'

fixed length array interpreted as VLA when size is a sizeof typedef'd type

Getting a VLA_FORBIDDEN error when declaring an array using sizeof on a typedef'd type as the array size.

typedef unsigned int	t_u32;

int main(void)
{
	unsigned char	bytes[sizeof(t_u32)];
	
	return (0);
}

As a comparison, the following code doesn't triggger any norm error

typedef unsigned int	t_u32;

int main(void)
{
	unsigned char	bytes[sizeof(unsigned int)];
	
	return (0);
}

The error appears multiple times depending on the size of the typedef name.
For the above example, with the name t_u32 it appears twice. But for the typedef name t_way_too_long_type_name it triggers 19 errors !

Dereferencing pointer trigger SPC_AFTER_OPERATOR

Hey !

I think this is not intended, so I have an issue with the norminette, it trigger SPC_AFTER_OPERATOR error when dereferencing a pointer.

The error

Here is the error :

queue_dequeue.c: KO!
        SPC_AFTER_OPERATOR   (line: 19, col: 13):       missing space after operator

The code

Here is the code :

/* ************************************************************************** */
/*                                                                            */
/*                                                        :::      ::::::::   */
/*   queue_dequeue.c                                    :+:      :+:    :+:   */
/*                                                    +:+ +:+         +:+     */
/*   By: bbellavi <[email protected]>          +#+  +:+       +#+        */
/*                                                +#+#+#+#+#+   +#+           */
/*   Created: 2020/09/30 09:09:45 by bbellavi          #+#    #+#             */
/*   Updated: 2020/11/15 16:49:30 by bbellavi         ###   ########.fr       */
/*                                                                            */
/* ************************************************************************** */

#include "lexer.h"

/*
**
** Description :
**    The dequeue function remove first item of the queue.
**
*/

t_queue	*dequeue(t_queue **head)
{
	t_queue	*first;

	first = *head;
	if (first == NULL)
		return (NULL);
	*head = (*head)->next;
	return (first);
}

The line

This is the line that causes the error

	first = *head;

I don't have the time for now to fix the problem and create a pull request, but wish you a good luck !

Best regards, Tony.

Newline in function declaration

The new version of norminette founds an error when putting a newline in function declaration which is not mention on normv3 pdf

LINE_TOO_LONG on multiline string.

I tried using a noticeably long string in one of my printf, and so inserted a backslash in the middle to spread
it across two lines :

	printf("\nOh noes. I, n°%i, no longer thinks, and therefore, is no more.\
	*dies in philosopher*\n", this->uid);

Accounting for the tabulation at the beginning, the first line amounts to 78 characters, but the norminette seems to believe both lines are one :

simulation.c: KO!
	LINE_TOO_LONG        (line:  32, col: 115):	line too long

115 happens to be close to the the length of both lines combined (first tabulation removed).

Source file: simulation.c.tar.gz

Unrecognized line with bitwise OR operator in enums

I get the following error:
Unrecognized line (7, 1) while parsing line [<TAB>, <IDENTIFIER=second_enum>, <SPACE>, <BWISE_OR>]

with the following example code:

enum	e_bitmask_enum
{
	first_enum_with_value_zero = 0,
	second_enum,
	third_enum,
	fourth_enum_with_value_based_on_other_enums = (first_enum_with_value_zero |
	second_enum | third_enum)
};

I tried similar things outside of an enum declaration but couldn't reproduce the same error.
Of course this specific error can be fixed by adding a backslash to the previous line, but I'm assuming norminette should always be able to recognize a line that is compilable C code.

bug: double asterisk pointer identified as multiplier sign

This snippet doesn't pass the norm:

/* ************************************************************************** */
/*                                                                            */
/*                                                        :::      ::::::::   */
/*   test.c                                             :+:      :+:    :+:   */
/*                                                    +:+ +:+         +:+     */
/*   By: rbarbero <[email protected]>          +#+  +:+       +#+        */
/*                                                +#+#+#+#+#+   +#+           */
/*   Created: 2020/12/26 10:56:02 by rbarbero          #+#    #+#             */
/*   Updated: 2020/12/26 11:04:46 by rbarbero         ###   ########.fr       */
/*                                                                            */
/* ************************************************************************** */

typedef char    t_my_type;

int     main(int argc, char **argv)
{
        size_t  size;

        size = sizeof(*(t_my_type **)argv);
        return (0);
}

This is the error:

% norminette test.c
test.c: KO!
        SPC_AFTER_OPERATOR   (line: 19, col: 31):       missing space after operator

Replacing t_my_type with charfixes the problem.

Starting line with * requires 2-tab indentation

This is invalid:

With errror:

test.c: KO!
        TOO_FEW_TAB          (line:  29, col:   1):     Missing tabs for indent level

To get rid of this error the line has to be indented with 2 tabs:

Copy-paste able code:

static bool	intersect_base(t_ray ray, t_vec3 c, double *t, t_cylinder cy)
{
	n.D = - (n.A * (c.x - cy.origin.x) + n.B * (c.y - cy.origin.y) + n.C
		* (c.z - cy.origin.z));
	n.dist = - (n.A * n.p0.x + n.B * n.p0.y + n.C * n.p0.z + n.D)
		/ (n.A * ray.dir.x + n.B * ray.dir.y + n.C * ray.dir.z);
}

There's no output on version 3.0.5

On version 3.0.5 only 'v', 'h' flags are works and norminette just keeps running without any output.

py38 compatibility

check/implement

Impossible to put function prototype exceeding 81 characters in headerfile

Either "line too long"
or "unrecognized variable type" when splitting the prototype over multiple lines

example that results in "unrecognized variable type":

void                get_draw_info(t_draw *draw, double perpwalldist,
                                    t_texture texture[4], t_mov mov);

example that results in "line too long":

void                get_draw_info(t_draw *draw, double perpwalldist, t_texture texture[4], t_mov mov);

Is there another way to put this prototype into my header in a norm-compliant way?

V2.52: multiplier sign interpreted as pointer sign

Hello. One of my malloc for my strsplit triggered a warning for the wrong reason. You can see the issue on the attached log: the triggers seems to be the parenthesis:

> cat test.c
int	main(void)
{
	char	*p;
	int		n;

	n = 2;
	p = malloc((1) * sizeof(*p));
	p = malloc((n + 1) * sizeof(*p));
	return (0);
}
> cat test2.c
int	main(void)
{
	char	*p;
	int		n;

	n = 2;
	p = malloc((1) *sizeof(*p));
	p = malloc((n + 1) *sizeof(*p));
	return (0);
}
> norminette test*
zsh: /usr/local/bin/norminette: bad interpreter: /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/bin/ruby: no such file or directory
test.c: KO!
	SPC_AFTER_POINTER     (line: 7, col: 20):	space after pointer
	SPC_AFTER_POINTER     (line: 8, col: 24):	space after pointer
test2.c: OK!

SPC_AFTER_POINTER

The following code triggers SPC_AFTER_POINTER for me twice

void	ft_step_init(t_cam cam, t_dda *dda)
{
	if (cam.ray.dir.x < 0.0)
	{
		dda->step.x = -1;
		dda->sidedist.x = (cam.pos.x - (int)cam.pos.x) * dda->deltadist.x;
	}
	else
	{
		dda->step.x = 1;
		dda->sidedist.x = ((int)cam.pos.x + 1.0 - cam.pos.x) * dda->deltadist.x;
	}
	if (cam.ray.dir.y < 0)
	{
		dda->step.y = -1;
		dda->sidedist.y = (cam.pos.y - (int)cam.pos.y) * dda->deltadist.y;
	}
	else
	{
		dda->step.y = 1;
		dda->sidedist.y = ((int)cam.pos.y + 1.0 - cam.pos.y) * dda->deltadist.y;
	}
}

I sincerely hope it's not just an issue on my part, I made sure to even remove the old installation, then made sure I was up to date with master and reinstalled it

EDIT:
It was an issue on my part, it wouldn't update my installation, only way to get it to update was to run the pip install --upgrade -i https://test.pypi.org/simple/ norminette provided on the readme under To upgrade an existing install, use

Allow globals that are marked const and static

There is no reason to disallow globals that are immutable and static.

For example, If a student wants to create a lookup table that is bigger than what a function would allow, then it's impossible to do without having to waste computational resources.

Different behaviour with <foo> and "foo" on include statements

Hello,

#include "foo.bar.h" works but #include <foo.bar.h> returns a norm error:

INCLUDE_HEADER_ONLY (line: 1, col: 1): .c file includes are forbidden

Pointer is confused with multiplier

dest = (char *)malloc((len + 1) * sizeof(char));
SPC_AFTER_POINTER (line: 47, col: 37): space after pointer

Error in check for SPC_AFTER_POINTER

The following code triggers SPC_AFTER_POINTER for me
SPC_AFTER_POINTER (line: 32, col: 60): space after pointer

		dda->sidedist.x = ((int)cam.pos.x + 1.0 - cam.pos.x) * dda->deltadist.x;

External user defined identifiers are matched against the Norm

For example, using XK_Escape from X11/keysym.h causes:

	FORBIDDEN_CHAR_NAME  (line: **, col: **):	user defined identifiers should contain only lowercase characters, digits or '_'

typedef function errors based on argument type

When using typedef for a function definition it gives errors depending on the arguments.

This is seen as a error:
typedef void (*t_func_definiton)(int arg);
with norminette output:
TAB_REPLACE_SPACE (line: 16, col: 13): Found tab when expecting space
SPACE_REPLACE_TAB (line: 16, col: 40): Found space when expecting tab
USER_DEFINED_TYPEDEF (line: 16, col: 41): User defined typedef must start with t_

But when changing the argument type to something else it is does not give a norm error:
typedef void (*t_func_definiton)(t_func_definiton arg);

Amount of tabulations not checked after user defined typedef

After a user defined typedef, an unspecified amount of tabulations is allowed.
As long as the line does not reach over 80 characters and declarations are aligned.
Im unsure if this is intentional but it can make for some ugly cases.

Erroneous code
Marked as correct by norminette:

typedef foo <TAB> <TAB> <TAB> t_bar;
typedef bar <TAB> <TAB> <TAB> t_foo;

typedef struct s_foo
{
} <TAB> <TAB> <TAB> t_bar;

typedef struct s_bar
{
} <TAB> <TAB> <TAB> <TAB> <TAB> t_foo;

Marked as incorrect by norminette:

typedef foo <TAB> <TAB> t_bar;
typedef bar <TAB> <TAB> <TAB> t_foo;

Additional infos

• OS: OSX 11.1
• python --version: 3.9.1
• norminette -v: 3.1.1

incrementation not considered as assignations?

Hello, sorry if im out of context but i tough incrementations would be considered as assignations (i++ is equivalent to i += 1 or i = i + 1) but the norminette doesn't seem to set KO to a .c file which would contain such thing in a control structure as :

...
while (i++)
...

Edit: my bad i just showed my noobness, apparently incrementation operators are separated from assignation operators, excuse my lack of knowledge..

Return value only has to start with parenthesis, not the whole thing

If you start the return with something in parenthesis, v3 seems to think it's okay. (this was also something that I noticed in v2)
These examples are currently marked as OK:

return (void *) 0;
return (int) var_name;
return (var1) + var2;
return (void *)(var_name);
return (int) var1 + 2;

Where, from the PDF, I'm assuming they should all be completely in parenthesis, not just starting with something between parenthesis and leaving the rest out.
I think it should look like this:

return ((void *) 0);
return ((int) var_name);
return ((var1) + var2);
return ((void *)(var_name));
return ((int) var1 + 2);

Norminette check function name from external library.

It seem the new norminette check function name not only at declaration and definition, but also at every single line.
Causing problems when using functions from libraries that don't use our naming convention.

sound_management.c: KO!
        FORBIDDEN_CHAR_NAME  (line: 24, col: 15):       user defined identifiers should contain only lowercase characters, digits or '_'
        FORBIDDEN_CHAR_NAME   (line: 38, col: 5):       user defined identifiers should contain only lowercase characters, digits or '_'
        FORBIDDEN_CHAR_NAME   (line: 52, col: 5):       user defined identifiers should contain only lowercase characters, digits or '_'

void	destroy_sound(t_sound to_destroy)
{
	free(to_destroy.filename);
	FMOD_Sound_Release(to_destroy.ptr);
}

Would it be better if the norminette check names only in prototypes and definitions ?

FORBIDDEN_CHAR_NAME triggers on C99 _Bool typedef

Code:

/* ************************************************************************** */
/*                                                                            */
/*                                                        :::      ::::::::   */
/*   bool.c                                             :+:      :+:    :+:   */
/*                                                    +:+ +:+         +:+     */
/*   By: secondfry <[email protected]>        +#+  +:+       +#+        */
/*                                                +#+#+#+#+#+   +#+           */
/*   Created: 2020/12/23 15:13:46 by secondfry         #+#    #+#             */
/*   Updated: 2020/12/23 15:36:30 by secondfry        ###   ########.fr       */
/*                                                                            */
/* ************************************************************************** */

#define TRUE 1
#define FALSE 0

typedef _Bool	t_bool;

t_bool	test(void)
{
	return (TRUE);
}

int	main(void)
{
	return (test());
}

Norminette:

bool.c: KO!
        FORBIDDEN_CHAR_NAME   (line: 16, col: 9):       user defined identifiers should contain only lowercase characters, digits or '_'

Can no longer use anonymous / embedded structs

#ifndef HEADER_H
# define HEADER_H

typedef struct s_mystruct
{
	int	x;
	int	y;
	struct s_embeded
	{
		int	height;
		int	width;
	}	anonymous;
}	t_mystruct;

#endif

As seen in the code snippet above, using anonymous or embedded structures seems to be bugged.

I tried several alignment styles, to name the struct or not, but it seems that the only solution to that issue is to typedef the structure which is to be embedded. This is annoying as there's no need for a typedef in that case.

The PDF doesn't say a thing about that, and it was possible to do that back at the norm v2.

"Missing tabs for indent level" at return statement

Describe the bug
When running norminette over this file, it starts complaining about a missing tab at the line of the return statement.

Error:

This was the initial "broken" code:

Changing it to these versions also did not remove the error:

However, changing it to THIS did for some reason fix it:
(But this hurts my heart and eyes to do...)

Erroneous code

size_t	usec_get(t_settings *settings)
{
	struct timeval	tv;
	size_t			s_delta;

	gettimeofday(&tv, NULL);
	s_delta = tv.tv_sec - settings->start_s;
	return (((unsigned int)(s_delta * 1000000 + tv.tv_usec)
		- settings->start_us));
}

Additional infos

• OS: Ubuntu 20.04.2 LTS
• python --version: Python 3.8.5
• norminette -v: 3.1.0

Additional context
None

Comments not counted in 80 char line limit

Describe the bug
I think this speaks for itself:

(The white vertical line marks 80 characters)

Erroneous code
There is no error :)

Additional infos

• OS: Ubuntu 20.04.2 LTS
• python --version: Python 3.8.5
• norminette -v: 3.1.0

Additional context
None

Unable to declare const

DECL_ASSIGN_LINE (line: 45, col: 25): Declaration and assignation on a single line
const int len = ft_len(n);
The only way to assign const is to do this :(

Allow preprocessor directives in c file - Or delete bonus rule ?

To turn in bonuses to your project, you must include a rule bonus to your Makefile,which will add all the various headers, librairies or functions that are forbidden onthe main part of the project. Bonuses must be in a different file_bonus.{c/h}.Mandatory and bonus part evaluation is done separately

Actually there is no way to respect the bonus rule.
(Except for libft - libasm, but useless anyway because they're just libraries)

• Should preprocessor directives be allowed in c files ?
• Or bonus rule should be deleted on all subjects ?

This rule confuse new students trying to go further than mandatory part.

https://stackoverflow.com/c/42network/questions/1624/1625

Pointer = operator ?

SPC_BFR_OPERATOR (line: 22, col: 49): missing space before operator SPC_AFTER_OPERATOR (line: 22, col: 49): missing space after operator
return ((unsigned char)*s1 - (unsigned char)*s2);

paradoxical indentation with enum

with the following sample code:

enum e_random_enum
{
	first_enum = 0,
	second_enum,
	third_enum,
	fourth_enum = 42
	};

I get the following errors:

        TOO_FEW_TAB            (line: 7, col: 1):       Missing tabs for indent level
        TOO_MANY_TAB           (line: 7, col: 1):       Extra tabs for indent level

Which seems rather paradoxical. 😉

It seems that the last enum assignment affects how the closing line is judged, since when I remove the specific value of 42, the error changes to TOO_MANY_INSTR (line: 7, col: 5): Too many instructions on a single line

SPC_AFTER_OPERATOR in multiline comment

Describe the bug
Negating the outcome of an expression like the one in the example requires me to put spaces before and after the operator. The normal norminette didn't complain about this.

Erroneous code
if ((-(cy->height * 0.5)) < z[0] && z[0] < ((cy->height * 0.5)))

Additional infos

• OS: Ubuntu 18.04.4 LTS (Bionic Beaver) on WSL 2
• python --version: 3.7.5
• norminette -v: norminette 3.1.0

Additional context

Inconsistent norm operand parsing

The code

if (p.x < cy.origin.x + cy.radius &&
	p.x > cy.origin.x - cy.radius)
{
	foo();
}

gives the errors:

test.c: KO!
        SPC_AFTER_OPERATOR   (line:  28, col:  39):     missing space after operator
        EOL_OPERATOR         (line:  28, col:  39):     Logic operator at the end of line

However if we change the location of the &&:

if (p.x < cy.origin.x + cy.radius
	&& p.x > cy.origin.x - cy.radius)
{
	foo();
}

Gives no errors

This is invalid since the Norm V3 says:
• Each operator or operand must be separated by one - and only one - space.
In neither of these examples the && operator is separated by one - and only one - space

• In the first example the && is separated by first a space and second a newline.
• In the second example the && is separated by first: a newline and a tab and second a space.

Either both or none of the two examples should be allowed.

PREPROC_CONSTANT error upon defining compound literal macros

The Norm states:

Preprocessor constants (or #define) you create must be used only for associate literal and constant values.

https://en.cppreference.com/w/c/language/expressions#Constants_and_literals states:

Constant values of certain types may be embedded in the source code of a C program using specialized expressions known as literals (for lvalue expressions) and constants (for non-lvalue expressions):
...
compound literals are values of struct, union, or array type directly embedded in program code (since C99)

So then I do define compound literal:

#define NALYSANN ((struct s_nalysann { size_t size; }) { sizeof(char) * 3 })
#define RUSTAM ((size_t[]) { sizeof(char) * 3 })
#define DEFINITELY_CONSTANT ((size_t[]) { 26, 39 })

It results in:

bool.c: KO!
        PREPROC_CONSTANT     (line: 14, col: 33):       Preprocessor statement must only contain constant defines
        PREPROC_CONSTANT     (line: 14, col: 44):       Preprocessor statement must only contain constant defines
        TOO_MANY_VALS        (line: 14, col: 46):       Too many values on define
        TOO_MANY_VALS        (line: 14, col: 53):       Too many values on define
        PREPROC_CONSTANT     (line: 14, col: 62):       Preprocessor statement must only contain constant defines
        PREPROC_CONSTANT     (line: 14, col: 70):       Preprocessor statement must only contain constant defines
        TOO_MANY_VALS        (line: 14, col: 79):       Too many values on define
        PREPROC_CONSTANT     (line: 15, col: 25):       Preprocessor statement must only contain constant defines
        PREPROC_CONSTANT     (line: 15, col: 31):       Preprocessor statement must only contain constant defines
        PREPROC_CONSTANT     (line: 15, col: 35):       Preprocessor statement must only contain constant defines
        PREPROC_CONSTANT     (line: 15, col: 43):       Preprocessor statement must only contain constant defines
        TOO_MANY_VALS        (line: 15, col: 52):       Too many values on define
        PREPROC_CONSTANT     (line: 16, col: 39):       Preprocessor statement must only contain constant defines
        PREPROC_CONSTANT     (line: 16, col: 45):       Preprocessor statement must only contain constant defines
        PREPROC_CONSTANT     (line: 16, col: 49):       Preprocessor statement must only contain constant defines
        TOO_MANY_VALS        (line: 16, col: 51):       Too many values on define
        TOO_MANY_VALS        (line: 16, col: 55):       Too many values on define

SPC_AFTER_OPERATOR with pointer

SPC_AFTER_OPERATOR (line: 17, col: 48): missing space after operator
int ((*conv[13])(t_syntax syntax, t_buffer *buffer, va_list va));

Space after pointer

g->spritedist[i] = ((g->posx - sprite.x) * (g->posx - sprite.x) + (g->posy - sprite.y) * (g->posy - sprite.y));

Space after pointer col 46

`const` in return function pointer declaration requires extra tab

In a header file, a function declaration like this:
const char *func(void);

requires a tab after const although a space is expected. The only tab required must be after char.

EDIT:
The actual code is: const char *(*func)(void);
The error is:
SPACE_REPLACE_TAB (line: 16, col: 6): Found space when expecting tab

V2.52: Tilde operator unusable after a parenthesis

Hello. Here are my log with my test file included. I also have an error with my Ruby version but this is probably unrelated.

> cat test.c
int	main(void)
{
	int	a;

	a = 1;
	return (~a);
}
> cat test2.c
int	main(void)
{
	int	a;

	a = 1;
	return ( ~ a);
}
> norminette test.c test2.c
zsh: /usr/local/bin/norminette: bad interpreter: /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/bin/ruby: no such file or directory
test.c: KO!
	SPC_BFR_OPERATOR      (line: 6, col: 13):	missing space before operator
	SPC_AFTER_OPERATOR    (line: 6, col: 13):	missing space after operator
test2.c: KO!
	NO_SPC_AFR_PAR        (line: 6, col: 12):	Extra space after parenthesis (brace/bracket)

Norm complain about space / tab before a connecting line

Describe the bug
When there is a long line that needs to broken down into two lines, norm complain about both spaces & tabs before the second line.

Erroneous code

if (pthread_create(&philos[i].philo_status_thread, NULL, \
	check_status, &philos[i]))
	return (-1);

Before the second line (check_status), when I put only tabs, norm says it should be spaces. When I change it to spaces, norm says it should be tabs.

Additional infos

• OS: pop-os
• python --version: 3.8.5
• norminette -v: 3.1.0

Additional context

screenshot of the actual line

output from norm

t_map *map SPC_BFR_OPERATOR and SPC_AFTER_OPERATOR

Hello,
The norminette-beta v3 on guacamole is displaying :

int render_map(void *param)
{
    int     endian;
    t_map   *map;   <<<< error is here

endian = 0;
    map = (t_map *)param;

And it display

SPC_BFR_OPERATOR (line: 18, col: 13):missing space before operator
SPC_AFTER_OPERATOR (line: 18, col: 13):missing space after operator

I don't have this issue with the norminette v2.

having trouble executing norminette

hello,

I'm having trouble executing norminette on my personal mac.

after installing with command python3 setup.py install,

I am getting this error everywhere where I try executing norminette.

Traceback (most recent call last):
  File "/usr/local/bin/norminette", line 11, in <module>
    load_entry_point('norminette==3.0.4', 'console_scripts', 'norminette')()
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/site-packages/pkg_resources/__init__.py", line 489, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2852, in load_entry_point
    return ep.load()
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2443, in load
    return self.resolve()
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2449, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "<frozen zipimport>", line 259, in load_module
  File "/Library/Python/3.8/site-packages/norminette-3.0.4-py3.8.egg/norminette/__main__.py", line 10, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "/Library/Python/3.8/site-packages/norminette-3.0.4-py3.8.egg/norminette/registry.py", line 2, in <module>
  File "<frozen zipimport>", line 259, in load_module
  File "/Library/Python/3.8/site-packages/norminette-3.0.4-py3.8.egg/norminette/context.py", line 3, in <module>
ModuleNotFoundError: No module named 'tools.colors'

Here are more details of my local environment:

As many of you see, I'm pretty much new to programming world, so please let me know what I'll need to do to fix the problem. Thanks!

Error on typedef on arrays with defined size

Hello,

typedef char t_word[8]; works, but typedef char t_word[LENGTH]; returns two norm errors:

TAB_REPLACE_SPACE (line: 5, col: 13): Found tab when expecting space
USER_DEFINED_TYPEDEF (line: 5, col: 24): User defined typedef must start with t_

Note: LENGTH is defined with # define LENGTH 8

bug: wrong prototype alignment computing

I got this error with the code snippet below:

test.h: KO!
        MISALIGNED_FUNC_DECL (line: 22, col: 18):       Misaligned function declaration

/* ************************************************************************** */
/*                                                                            */
/*                                                        :::      ::::::::   */
/*   test.h                                             :+:      :+:    :+:   */
/*                                                    +:+ +:+         +:+     */
/*   By: rbarbero <[email protected]>          +#+  +:+       +#+        */
/*                                                +#+#+#+#+#+   +#+           */
/*   Created: 2020/12/24 01:14:12 by rbarbero          #+#    #+#             */
/*   Updated: 2020/12/24 01:52:22 by rbarbero         ###   ########.fr       */
/*                                                                            */
/* ************************************************************************** */

#ifndef TEST_H
# define TEST_H

struct          s_dict
{
    size_t      size;
};

int             ft_hash(char *str);
struct s_dict   *ft_hash_table_create(size_t size);

#endif