Various fixes for building with new compilers#466
Various fixes for building with new compilers#466starseeker merged 17 commits intostepcode:developfrom
Conversation
Co-authored-by: starseeker <238416+starseeker@users.noreply.github.com>
Co-authored-by: starseeker <238416+starseeker@users.noreply.github.com>
…arations Co-authored-by: starseeker <238416+starseeker@users.noreply.github.com>
Improves error handling in STEPattributeList operator[] - return an error attribute and set error state rather than trying to rely on crashing via a NULL deference. That's undefined behavior, so it was not guaranteed - this requires the calling code to check the return, but is *much* cleaner. Co-authored-by: starseeker <238416+starseeker@users.noreply.github.com>
Co-authored-by: starseeker <238416+starseeker@users.noreply.github.com>
|
Does the latest EXPRESS compiler updates successfully compile the AP 242 ed4 long form schema: |
…ype-andor Fix test_exppp_supertype_andor CMake version inconsistency
|
@cshorler Are you still active with stepcode? |
|
@TRThurman A quick experiment shows the following error from the schema scanner: That's this block: The short answer is no, stepcode apparently can't handle it at the moment. I'm not quite sure what it would take to support it - it could be fairly non-trivial, judging by a quick round with Copilot. |
|
It turns out that is a critical aggregate. |
As well as one behavior correction - rather than trying to use a NULL pointer deference to crash in an error case (bad practice and undefined behavior anyway) return an error attribute calling applications can deal with gracefully.