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

code cleanup for building with latest tools #421

Merged
merged 3 commits into from
Jul 22, 2024
Merged

code cleanup for building with latest tools #421

merged 3 commits into from
Jul 22, 2024

Conversation

elidwa
Copy link
Contributor

@elidwa elidwa commented Jul 21, 2024

H5Coro.cpp has an issue with info.data which is uint8_t*
It gets allocation as byte array but later the pointer gets casted to float/double etc. This is not safe. Starting in C++ 17 'new' on byte array may be aligned to 2, 4, 8, 16 bytes. Before C++ 17 it was either 4 or 8 bytes. cpp-check is very unhappy about it. For now, I added this line to project-config.cmake to disable the warning:

"--suppress=invalidPointerCast:/H5Coro.cpp" # info.data (uint8_t being cast to float/double ptrs. Alignment issues)

We could ignore it (what we do now)
Allocate memory with with std::aligned_alloc() guaranteeing the max needed alignment.

BathyOcensEyes.cpp line 653. Added check for kd_range_index value being out of bounds. cpp-check detected that UNCERTAINTY_COEFF_MAP may be indexed out of bounds.

@elidwa elidwa requested a review from jpswinski July 21, 2024 16:34
@jpswinski
Copy link
Member

Instead of the addition on line 653 of BathyOcensEyes.cpp, can we modify the lines above it with the following (notice the minus one in the kd_range_index check):

            /* get kd range index */
            int kd_range_index = 0;
            while(kd_range_index < (NUM_KD_RANGES - 1) && KD_RANGES[kd_range_index][1] < kd)
            {
                kd_range_index++;
            }

@jpswinski
Copy link
Member

Also, do we need the memset on line 459 of H5Coro.cpp that was added?

@elidwa
Copy link
Contributor Author

elidwa commented Jul 21, 2024

Updated BathyOcensEyes.cpp as requested.
As for the memset on line 459 in H5Coro.cpp the cpp-checker gets confused and reports:

[ 1%] Building CXX object CMakeFiles/slideruleLib.dir/packages/h5/H5Coro.cpp.o
/home/elidwa/ICESat2/sliderule/packages/h5/H5Coro.cpp:466:29: error: Uninitialized variable: &info [uninitvar]
const H5Dataset dataset(&info, context, datasetname, slice, slicendims, _meta_only);

I have two choices. Keep the memset and initialize the variable or disable cppcheck-suppress uninitvar
I would have to do it for the whole file. Doing it per file/line works but the moment the file changes the check would be in a wrong place and would fail again.

I suspect that cppchecker gets confused in
void H5Dataset::readDataset (info_t* info)
there are 'if' statements which check for particular case of metaData.type but these don't have default 'else'. Checker sees that info->datatype only gets set for some of the metaData.type and complains about it. There may be other reasons as well. I tried fixing it by adding 'else' but it still complained.

@jpswinski
Copy link
Member

I've been trying to move away from memsets when possible (though I am sure there are still a ton in the code). The reason is that it precludes any meaningful check of uninitialized access that would be caught by the address sanitizer in the self test.

As for the alignment of new I didn't realize that new might not align to 8 bytes - I think we should fix this in the code. Do you know if there are any performance considerations between using new uint64_t [] vs std::aligned_alloc()? I think x86 and ARM both support misaligned access, but is there a performance penalty to it?

@elidwa
Copy link
Contributor Author

elidwa commented Jul 22, 2024

memset has been removed

info.data is being newed with C++ 17 overloaded new operator which allows for alignment. This method is preferred from st::aligned_alloc() Notice how operator delete[] also has to specify alignment or address sanitizer blows up if regular delete[] is called.

x86 and ARM both support misaligned access. There is a small performance hit for both architectures since loading unaligned address to the register may require multiple fetch data instructions. ARM seems to be better at it than x86. There is also the data cache performance hit. Unaligned data may span multiple cache lines.

@jpswinski jpswinski merged commit c2ffed6 into main Jul 22, 2024
5 checks passed
@jpswinski jpswinski deleted the cleanbuild branch July 22, 2024 14:34
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