REFACTOR: change code convention to strict C89 #1
No reviewers
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ae2f/Preproc!1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "kenter7317/Preproc:main"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
this is for refactoring for new domain-specific library(served by repo-owner)-standard
this pull request is proposing variable name refactoring and macro reproduction
variable name renamed following rule
now some macro has updated
following macros work style is changed
orginally refer prm_bool's variable value, but in this refactor has deleted that struct and changed bit-masking, now this refactor macros refer bit-masking-code value and will be work like some operation index and the parameter value is stored in
unsigned prm_boolfollowing macros are added
STRLEN(a)is produced for c89's null-terminated size counterfollowing code has changed :
BOOL_AND(u, m) BOOL_NAND(u, m) is macro, for bit-checking and bit adding opeartion
i review this commit, some logical error has produced by human trans-logic process, then i fix such error
Review 0
@ -23,1 +22,3 @@#define prm_first prmbool.m_first#define prm_cmt PRM_CMT#define prm_space_found PRM_SPACE_FOUND#define prm_first PRM_FIRSTFor simple lowercase macros seem not to be relevant | required.
@ -75,0 +76,4 @@* unsigned m_is_fn_arg : 1;* unsigned m_is_bypassing_arg : 1;* } prmbool = { 0, 0, 0, 0, 0 };***/Original code could be checked via commit.
On comments it is irrelevant.
@ -209,2 +219,3 @@prm_bool |= PRM_CMT | PRM_FIRST;stack = 0;prmbool.m_is_fn_arg = 0;prm_bool = BOOL_NAND(prm_bool, PRM_IS_FN_ARG);Logic is wrong.
BOOL_NAND(A, B) is defined ~((A) & (B)) where
Bis(1 << n).Which wants to get
A'snth bit, and bitnot it.That will lead ~(1 << n) or ~0(all bit set 1)
@ -52,2 +49,4 @@#define isNewLine(c) ((c) == '\n' || (c) == '\r')#define BOOL_AND(u, m) ((u) & (m))#define BOOL_NAND(u, m) !(BOOL_AND(u, m))First, that is LOGICAL NOT. The result will be normalised.
Second. pure NAND is not the solution to set a bit 1. See #1 (comment)
after this comment I resolved Logical problem originated at Macro BOOL_NAND and base branch's struct variable's set_zero code that refactored with bit method. See #commit_14ed96dcf8
there are some fall-through porblem only occured at strictC89 until commit #commit_14ed96dcf8, I missed out that problem caused by using bundled gcc and now fixed this problem since commit #commit_20bd4c5031
@ -390,3 +387,3 @@fputc(c, stdout);c = fgetc(stdin);break;You are adding a break line without handling the default branch.
That could lead to false positives.
Rest of the changes also seem to be adding just break which leads logic to skip the branch which process was to be fallen through, resulting to false positives… fix it.
@ -51,29 +48,29 @@ casenewlines#define isVarName(c) ((isAlph(c) || isNumber(c)) || (c) == '_')#define isNewLine(c) ((c) == '\n' || (c) == '\r')#define BOOL_AND(u, m) ((u) & (m))Inconsistent style. Either use
BOOL_ORalso or remove this and use pure macro.@ -53,1 +50,4 @@#define BOOL_AND(u, m) ((u) & (m))#define SET_ZERO(u, m) ((u) & ~((unsigned)m))#define BOOL_OR(u, m) ((u) | (m))Unused macro. Remove this or use it.
@ -391,2 +391,3 @@c = fgetc(stdin);goto FALL_STRING_DEFUALT;break;goto does not necessarily require
breakafter itself (it effectively marks the end of the branch)setTrue(u, m)cea698b22eApproved