Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix warnings #527

Merged
merged 2 commits into from
Oct 3, 2023
Merged

Fix warnings #527

merged 2 commits into from
Oct 3, 2023

Conversation

bbshelper
Copy link
Contributor

@bbshelper bbshelper commented Sep 25, 2023

These are some warnings exposed by enabling -Wall, and are relatively easy to fix. Others like comparison between signed and unsigned integers are much harder to solve. I suggest that we enable -Wall -Werror ASAP to prevent new warnings, while adding waivers for legacy code.


This change is Reviewable

These warnings can be seen by enabling -Wall.
@@ -136,8 +136,6 @@ static css_font_family_t DEFAULT_FONT_FAMILY = css_ff_sans_serif;
/// minimum EM width of page (prevents show two pages for windows that not enougn wide)
#define MIN_EM_PER_PAGE 20

static int def_font_sizes[] = { 18, 20, 22, 24, 29, 33, 39, 44 };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is used like 10 lines down ftr.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Though strictly I suppose you might argue it should also have USE_LIMITED_FONT_SIZES_SET around it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right. Fixed. I also reverted the change in lvrend.cpp in case of side effects.

Copy link
Member

@NiLuJe NiLuJe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 8 of 16 files at r1, 1 of 8 files at r2, 7 of 7 files at r3, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @bbshelper and @Frenzie)


crengine/src/lvstsheet.cpp line 25 at r3 (raw file):

//#define DUMP_CSS_PARSING

// Helper to debug string parsing, showing current position and context

I imagine that one may have been left in on purpose (but perhaps should be behind ifdefs). Or not. @poire-z will tell us ;).

@poire-z
Copy link
Contributor

poire-z commented Sep 25, 2023

Will look at all that better by end of week.

But what's with the random reordering of fields ?
I guess it's by field length in bytes, for packing/padding reasons.
I did think about packing for classes/structs used often/a lot - but for most others that are not used often or a lot, I did not. And the current ordering is by field topic, logic, or date added.
These random reordering kills this possible logic - and add not really needed diffs :/

@bbshelper
Copy link
Contributor Author

But what's with the random reordering of fields ?

It's about initialization order: https://stackoverflow.com/questions/1828037/whats-the-point-of-g-wreorder

Honestly I haven't noticed any real problems uncovered in our code by this warning, but eliminating them is desirable.

@poire-z
Copy link
Contributor

poire-z commented Sep 28, 2023

I also reverted the change in lvrend.cpp in case of side effects.

If you mean that you finally decided to not remove lUInt16 childElementId = child->getNodeId();, it seems like I forgot to remove it as part of 569e4f7, and I think you could remove it. (Or do you see some real possible side effects?)

@poire-z
Copy link
Contributor

poire-z commented Sep 28, 2023

And the current ordering is by field topic, logic, or date added.
These random reordering kills this possible logic - and add not really needed diffs :/

It's about initialization order

Oh, ok - you did not change my declarations ordering (what I will look at), you just made the initializations (that I will rarely look at) order similar to the declaration order - which is fine and add consistency :) So, fine with me.

Comment on lines 5440 to 5442
int new_h = new_rc.bottom - base_y;
int next_fragments_shift_y = new_rc.bottom - orig_rc.bottom;
// printf("fixing fragment %d (%d ~ %d => %d , +%d => +%d)\n", node->getNodeIndex(), base_y, orig_rc.top, new_rc.top, orig_h, new_h);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please live line 5440 in, just comment it out (new_h is used in the commented out printf on line 5442 - so if removed, that printf won't work if I need debugging - so best to have them both commented out).

Comment on lines 25 to 30
// Helper to debug string parsing, showing current position and context
static void dbg_str_pos(const char * prefix, const char * str) {
printf("/----------|---------- %s\n", prefix);
printf("\\%.*s\n", 20, str - 10);
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might also be useful in the future, so don't remove it please :) Just wrap it with #if 0 or something like that.

Comment on lines 320 to 321
static int substr_compare( const char * sub, const char * & str )
{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No longer used since a few months ago - but don't kill it, might be useful some day. Just wrap it with /* No longer used or something.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this and other comments - I will make the change at some later time. It's already midnight here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good night :) (no hurry needed)

@bbshelper
Copy link
Contributor Author

I also reverted the change in lvrend.cpp in case of side effects.

If you mean that you finally decided to not remove lUInt16 childElementId = child->getNodeId();, it seems like I forgot to remove it as part of 569e4f7, and I think you could remove it. (Or do you see some real possible side effects?)

I wanted to play safe. After another look at getNodeId(), I believe it can be safely removed. It does have side effects: if the node is swapped to the disk it is loaded back, but it's an implementation detail and doesn't matter to the outside.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants