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

atl24 cleanup for latest tools #434

Merged
merged 23 commits into from
Oct 22, 2024
Merged

atl24 cleanup for latest tools #434

merged 23 commits into from
Oct 22, 2024

Conversation

elidwa
Copy link
Contributor

@elidwa elidwa commented Oct 2, 2024

No description provided.

@elidwa elidwa requested a review from jpswinski October 2, 2024 14:44
@@ -160,7 +160,8 @@ FieldArray<T,N>::FieldArray(std::initializer_list<T> init_list):
*----------------------------------------------------------------------------*/
template <class T, int N>
FieldArray<T,N>::FieldArray(void):
FieldUnsafeArray<T>(&values[0], N)
FieldUnsafeArray<T>(&values[0], N),
values()
Copy link
Member

Choose a reason for hiding this comment

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

I prefer to leave a value uninitialized when it is actually uninitialized. This allows address sanitizer / valgrind to catch uninitialized data access.


// encoding
template<class T>
inline uint32_t getImpliedEncoding(void) {
T dummy;
T dummy = T();
Copy link
Member

@jpswinski jpswinski Oct 9, 2024

Choose a reason for hiding this comment

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

This code is only used to set the encoding type of the field class and should not have data associated with it. By calling the initialization function of the type, the dummy variable is initialized, but then never used. I don't know how the compiler will treat a variable that has been written to and then ignored. My feeling (and I admit it is only that), is that keeping it uninitialized makes it unambiguous that there are no side effects to calling the function getImpliedEncoding, which means that it should just completely optimize away and be replaced with the encoding type.

inline uint32_t toEncoding(double& v) { (void)v; return Field::DOUBLE; };
inline uint32_t toEncoding(time8_t& v) { (void)v; return Field::TIME8; };
inline uint32_t toEncoding(string& v) { (void)v; return Field::STRING; };
inline uint32_t toEncoding(const bool& v) { (void)v; return Field::BOOL; };
Copy link
Member

Choose a reason for hiding this comment

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

When the getImpliedEncoding function calls these functions with a variable that is uninitialized, the compiler will complain if the variable is declared const because at that point the assumption is that it is read only and not set.

inline uint32_t toEncoding(FieldColumn<double>& v) { (void)v; return Field::NESTED_COLUMN | Field::DOUBLE; };
inline uint32_t toEncoding(FieldColumn<time8_t>& v) { (void)v; return Field::NESTED_COLUMN | Field::TIME8; };
inline uint32_t toEncoding(FieldColumn<string>& v) { (void)v; return Field::NESTED_COLUMN | Field::STRING; };
inline uint32_t toEncoding(const FieldColumn<bool>& v) { (void)v; return Field::NESTED_COLUMN | Field::BOOL; };
Copy link
Member

Choose a reason for hiding this comment

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

same as above

@@ -282,6 +282,7 @@ FieldColumn<T>& FieldColumn<T>::operator= (const FieldColumn<T>& column)
}

encoding = column.encoding;
chunkSize = column.chunkSize;
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 a bug. The chunkSize has to be the same as was used in the lines above when appending elements.

@@ -73,7 +73,7 @@ class FieldElement: public Field
*--------------------------------------------------------------------*/

operator bool() const {
return value != 0; // Object is "true" if value is non-zero
return static_cast<T>(value) != 0; // Object is "true" if value is non-zero
Copy link
Member

Choose a reason for hiding this comment

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

I am very nervous about this change. The code, as it was, will allow the compiler to issue an error when it is inappropriately used. I think the new code would do the same, but I am not sure why there would ever be a reason to perform a static cast of a variable of type T to the exact same type that it already is.

The problem with this change, is that I know the original code will cause the compiler to issue an error when I do something that doesn't make sense, but I don't know how the new code will behave.

@@ -102,7 +102,7 @@ FieldElement<T>::FieldElement(T default_value):
*----------------------------------------------------------------------------*/
template <class T>
FieldElement<T>::FieldElement():
Field(ELEMENT, getImpliedEncoding<T>())
Field(ELEMENT, getImpliedEncoding<T>()), value()
Copy link
Member

Choose a reason for hiding this comment

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

I prefer to avoid artificially initializing variables because that prevents tools like valgrind and address sanitizer from catching my mistakes.

@@ -126,6 +126,7 @@ FieldEnumeration<T,N>::FieldEnumeration(std::initializer_list<bool> init_list):
template <class T, int N>
FieldEnumeration<T,N>::FieldEnumeration(void):
Field(ENUMERATION, getImpliedEncoding<T>()),
values(),
Copy link
Member

Choose a reason for hiding this comment

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

same as above

@@ -203,7 +203,22 @@ long FieldList<T>::length(void) const
template<class T>
const Field* FieldList<T>::get(long i) const
{
return reinterpret_cast<const Field*>(&values[i]);
Copy link
Member

Choose a reason for hiding this comment

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

this code only makes sense when there is a list of fields; I want the code to crash if that is not the case.

@jpswinski jpswinski merged commit d8c1767 into main Oct 22, 2024
2 of 5 checks passed
@elidwa elidwa deleted the atl24-cleanup branch October 24, 2024 16:09
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