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.

Sign up for GitHub

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

Jump to bottom

Added checks for undefined #509

Merged
merged 3 commits into from
Sep 29, 2023
Merged

Added checks for undefined #509

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
2b6494c
Added checks for undefined
Sep 26, 2023
d12b078
Added checks for undefined
Sep 26, 2023
5998144
Merge branch 'bugfix/ftn_address_fromString' of https://github.com/An…
Sep 27, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Added checks for undefined
  • Loading branch information
anthony committed Sep 27, 2023
commit d12b0789aa0ba2b3fea7467d9a7d9bb754f2c503
2 changes: 1 addition & 1 deletion core/ftn_address.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -135,7 +135,7 @@ module.exports = class Address {
static fromString(addrStr) {
const m = FTN_ADDRESS_REGEXP.exec(addrStr);

if (m) {
if (m && m[2] && m[3]) {
Copy link
Owner

Choose a reason for hiding this comment

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

I think we need to revert this part, right?

Copy link
Author

@AnthonyHarwood AnthonyHarwood Sep 28, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

The test for m[2] might not be needed.

To be honest, I never found a way to cause m[2] to be null. I just figured if testing for m[3] was necessary, testing for m[2] was probably not a bad idea. Perhaps I was being a bit too defensive.

Anyways... I tried removing the test for m[3] just now, and found that entering a numeric value in the address field will cause an error and disconnect me. So I believe that test is still needed.

I'm curious to know if the tests for m[2] and m[3] might become unnecessary if FTN_ADDRESS_REGEXP was tweaked a bit. And then we could just test m??? Just a thought.

// start with a 2D
let addr = {
net: parseInt(m[2]),
Expand Down
2 changes: 1 addition & 1 deletion core/system_view_validate.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -91,7 +91,7 @@ function validateGeneralMailAddressedTo(data, cb) {
// :TODO: remove hard-coded FTN check here. We need a decent way to register global supported flavors with modules.
const addressedToInfo = getAddressedToInfo(data);

if (Message.AddressFlavor.FTN === addressedToInfo.flavor) {
if (Message.AddressFlavor.Local !== addressedToInfo.flavor) {
return cb(null);
}

Expand Down