Skip to content
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.

[BUG-227485] [PATCH] Fix build warnings relating to polymorphic types and complex copy-assignments in GCC 8.3.0+ #5760

Closed
sl-service-account opened this issue Aug 13, 2019 · 2 comments

Comments

@sl-service-account
Copy link

sl-service-account commented Aug 13, 2019

What just happened?

GCC gets angry about and refuses to continue when polymorphic types and complex copy-assignments.
In specific, GCC prefers catch (std::bad_alloc&) over catch (std::bad_alloc) (As well with various other exceptions)
As well as memset(static_cast<void*>(tan1), 0, vertexCount*2*sizeof(LLVector4a)); over memset(tan1, 0, vertexCount*2*sizeof(LLVector4a));.

What were you doing when it happened?

Compiling with GCC 8.3.0 on linux.

What were you expecting to happen instead?

Successful warningless compile.

Other information

Although I am still amateur level when it comes to C++, static_cast<void*> seems correct, but it might not actually be correct. It is possible that static_cast<LLVector4a\*> would be more correct, but I am unsure. As far as I can tell, void* works. Still learning about structs and their magic.

Additionally, I would have submitted a pull request but I am unsure if there is a specific protocol to those.
Bitbucket changeset link: https://bitbucket.org/Chaser_Zaks/viewer-release/commits/5d1686850dca1857041bc01df58c20cf13d6cf79

Attachments

Original Jira Fields
Field Value
Issue BUG-227485
Summary [PATCH] Fix build warnings relating to polymorphic types and complex copy-assignments in GCC 8.3.0+
Type Bug
Priority Unset
Status Closed
Resolution Accepted
Reporter Chaser Zaks (chaser.zaks)
Created at 2019-08-13T08:09:31Z
Updated at 2020-05-04T16:06:11Z
{
  'Build Id': 'unset',
  'Business Unit': ['Platform'],
  'Date of First Response': '2019-10-16T08:27:05.345-0500',
  "Is there anything you'd like to add?": 'Although I am still amateur level when it comes to C++, `static_cast<void*>` _seems_ correct, but it might not actually be correct. It is possible that `static_cast<LLVector4a*>` would be more correct, but I am unsure. As far as I can tell, `void*` works. Still learning about structs and their magic.\r\n\r\nAdditionally, I would have submitted a pull request but I am unsure if there is a specific protocol to those.\r\nBitbucket changeset link: https://bitbucket.org/Chaser_Zaks/viewer-release/commits/5d1686850dca1857041bc01df58c20cf13d6cf79',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'System': 'SL Viewer',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': 'GCC gets angry about and refuses to continue when polymorphic types and complex copy-assignments.\r\nIn specific, GCC prefers `catch (std::bad_alloc&)` over `catch (std::bad_alloc)`.\r\nAs well as `memset(static_cast<void*>(tan1), 0, vertexCount*2*sizeof(LLVector4a));` over `memset(tan1, 0, vertexCount*2*sizeof(LLVector4a));`.',
  'What were you doing when it happened?': 'Compiling with GCC 8.2.0 on linux.',
  'What were you expecting to happen instead?': 'Successful warningless compile.',
}
@sl-service-account
Copy link
Author

AndreyK ProductEngine commented at 2019-10-16T13:27:05Z, updated at 2019-10-16T13:44:29Z

Void's size is system dependent (4 bytes on 32 bit system, 8 on 64.) and casting class to void for memset likely won't work right (access violation would be the best case).

In case of LLVector4a memset works because it is a very simple class, but generally it is a bad idea to memset a class (and your compiler is doing the right thing here, these resets need to be remade).

@sl-service-account
Copy link
Author

AndreyK ProductEngine commented at 2019-10-24T13:41:01Z

https://bitbucket.org/lindenlab/viewer-neko/commits/67025f02dc502effa258d65fbdf61611ce9ef997

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

No branches or pull requests

1 participant