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

Support multiple NoteData within a NoteSegment #87

Merged
merged 4 commits into from
Apr 11, 2022

Conversation

jerkerolofsson
Copy link

Added support for multiple NoteData within a single NoteSegment, as is common in ELF core dumps:

  • Added support for parsing multiple NodeData in NoteSegment and storing them in a List
  • Added INodeData interface to expose NodeData from a INoteSegment to package users
  • Updated INodeSegment with a 'Nodes' property returning IReadOnlyList containing all the NoteData

Copy link
Owner

@konrad-kruczynski konrad-kruczynski left a comment

Choose a reason for hiding this comment

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

Thanks for the input, a few remarks here and there and I'll merge it :)

{
internal string Name { get; private set; }
public const ulong NOTE_DATA_HEADER_SIZE = 12; // name size + description size + field
Copy link
Owner

Choose a reason for hiding this comment

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

Naming convention for constants in the project is PascalCase.

/// <summary>
/// Owner of the note.
/// </summary>
string Name { get;}
Copy link
Owner

Choose a reason for hiding this comment

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

Suggested change
string Name { get;}
string Name { get; }

/// <summary>
/// Owner of the note.
/// </summary>
string Name { get;}
Copy link
Owner

Choose a reason for hiding this comment

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

Suggested change
string Name { get;}
string Name { get; }

internal byte[] Description { get; private set; }
public string Name { get; private set; }

public byte[] Description { get; private set; }
Copy link
Owner

Choose a reason for hiding this comment

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

As we now go public, I'd like to go with something immutable (I know that we have it in NoteSegment, but this was a mistake. As ImmutableArray is not available in .NET Standard 2.0, I think that ReadOnlyCollection would be the best choice.

internal byte[] Description { get; private set; }
public string Name { get; private set; }

public byte[] Description { get; private set; }
Copy link
Owner

Choose a reason for hiding this comment

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

As we now go public, I'd like to go with something immutable (I know that we have it in NoteSegment, but this was a mistake. As ImmutableArray is not available in .NET Standard 2.0, I think that ReadOnlyCollection would be the best choice.

using ELFSharp.ELF.Sections;
using ELFSharp.Utilities;

namespace ELFSharp.ELF.Segments
{
public sealed class NoteSegment<T> : Segment<T>, INoteSegment
{
private List<NoteData> mNotes = new List<NoteData>();
Copy link
Owner

Choose a reason for hiding this comment

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

In this project private fields should be located at the end of the class. Also, don't prefix private fields with m or anything else, so just notes.

using ELFSharp.ELF.Sections;
using ELFSharp.Utilities;

namespace ELFSharp.ELF.Segments
{
public sealed class NoteSegment<T> : Segment<T>, INoteSegment
{
private List<NoteData> mNotes = new List<NoteData>();
Copy link
Owner

Choose a reason for hiding this comment

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

In this project private fields should be located at the end of the class. Also, don't prefix private fields with m or anything else, so just notes.

}
else
{
// File is damaged
Copy link
Owner

Choose a reason for hiding this comment

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

I'd go with throwing exception here, unless you know that non-conforming files are frequent. Otherwise we'll wait for such an issue with accepting structure like here.

}
else
{
// File is damaged
Copy link
Owner

Choose a reason for hiding this comment

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

I'd go with throwing here, unless you know that non-conforming files are frequent. Otherwise we'll wait for such an issue with accepting structure like here.

Copy link
Author

Choose a reason for hiding this comment

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

I can add an exception here. My reasoning for not doing it was that "if there are non-confirming files", that means that the change would be breaking behavior for backwards compatibility.

@jerkerolofsson
Copy link
Author

Requested changes commited in b61c3cb

{
internal string Name { get; private set; }
public const ulong NOTE_DATA_HEADER_SIZE = 12; // name size + description size + field
Copy link
Owner

Choose a reason for hiding this comment

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

Naming convention for constants in the project is PascalCase.

@konrad-kruczynski konrad-kruczynski merged commit 1a227f7 into konrad-kruczynski:master Apr 11, 2022
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.

2 participants