Skip to content

Conversation

@lgritz
Copy link
Collaborator

@lgritz lgritz commented Jul 24, 2025

  • span-ify ParamValue (including ctr and init)
  • add span versions of attribute() and getattribute() to the classes that have them: ParamValueList, ImageSpec, ImageCache, TextureSystem.

Much like the previous span/image_span additions we've made elsewhere, now each of these calls has 3 flavors:

  1. The previously existing -- but acknowledged "unsafe" -- version that takes a TypeDesc and a raw pointer (which had better match the TypeDesc in type and size, but who knows?)
  2. A version that takes a TypeDesc and a span<std::byte> delineating the raw memory to use, that must match the size implied by the type, and is implemented underneath (for now) by calling the pointer version after checking that the size is adequate.
  3. A template version that takes a TypeDesc and a span<T> that must match both in total size and appropriate type and asserts in debug builds if they don't. It's implemented by calling the raw byte version after the type check.

The third variety is the preferred one for apps to call, whenever possible, but the others are still exposed for special cases.

@lgritz lgritz added core APIs Affecting public APIs of core functionality classes, such as ImageInput, ImageOutput, ImageBuf. roadmap This is a priority item on the roadmap for the next major release. strategic Strategic initative with far-reaching effects (in time and code space) labels Jul 24, 2025
@lgritz
Copy link
Collaborator Author

lgritz commented Jul 24, 2025

@EmilDohne 👀 🙏

@EmilDohne
Copy link
Contributor

I'll take a look this weekend!

@lgritz
Copy link
Collaborator Author

lgritz commented Jul 30, 2025

I'd love to get this merged by the end of the week, if nobody has any objections.

/// Note that when retrieving a string, you need to pass a span of either
/// `const char*` or `ustring`, not a pointer to the first character of
/// the string. The caller does not need to ever free the memory that
/// contains the characters.
Copy link
Contributor

Choose a reason for hiding this comment

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

[nit] expand on who owns the string, whether that may be the ImageSpec or a ustring

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

[nit] expand on who owns the string, whether that may be the ImageSpec or a ustring

Amended

Comment on lines 51 to 53
void* ptr = malloc(size);
if (_value)
memcpy(ptr, _value, size); //NOSONAR
if (_value.size())
memcpy(ptr, _value.data(), size); //NOSONAR
Copy link
Contributor

Choose a reason for hiding this comment

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

[consider] since _value.size() can either be == size or == 0 as asserted above we should probably just do malloc(_value.size()) and then memcpy(ptr, _value.data(), _value.size())

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

You mean just to eliminate the "if"?

Copy link
Contributor

Choose a reason for hiding this comment

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

I meant more something along the lines of:

void* ptr = malloc(_value.size());
if (_value.size())
   memcpy(ptr, _value.data(), _value.size());

and then be rid of the //NOSONAR since I'm assuming it triggered on copying from a buffer that may be smaller than size

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

OH, I see your point now. Yes, I agree. Will fix.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

So amended.

@EmilDohne
Copy link
Contributor

I'll take a look this weekend!

Sorry I only got around to it now, except for those things this LGTM

lgritz added 2 commits July 30, 2025 11:32
@lgritz
Copy link
Collaborator Author

lgritz commented Jul 31, 2025

Seem all set to you know, @EmilDohne?

Copy link
Contributor

@EmilDohne EmilDohne left a comment

Choose a reason for hiding this comment

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

LGTM!

@lgritz lgritz merged commit e36031c into AcademySoftwareFoundation:main Aug 1, 2025
30 of 31 checks passed
zachlewis pushed a commit to zachlewis/OpenImageIO that referenced this pull request Sep 1, 2025
…ation#4838)

* span-ify ParamValue (including ctr and init)
* add span versions of attribute() and getattribute() to the classes
that have them: ParamValueList, ImageSpec, ImageCache, TextureSystem.

Much like the previous span/image_span additions we've made elsewhere,
now each of these calls has 3 flavors:
1. The previously existing -- but acknowledged "unsafe" -- version that
takes a TypeDesc and a raw pointer (which had better match the TypeDesc
in type and size, but who knows?)
2. A version that takes a TypeDesc and a `span<std::byte>` delineating
the raw memory to use, that must match the size implied by the type, and
is implemented underneath (for now) by calling the pointer version after
checking that the size is adequate.
3. A template version that takes a TypeDesc and a `span<T>` that must
match both in total size and appropriate type and asserts in debug
builds if they don't. It's implemented by calling the raw byte version
after the type check.

The third variety is the preferred one for apps to call, whenever
possible, but the others are still exposed for special cases.

---------

Signed-off-by: Larry Gritz <[email protected]>
@lgritz lgritz deleted the lg-attribspan branch October 3, 2025 00:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

core APIs Affecting public APIs of core functionality classes, such as ImageInput, ImageOutput, ImageBuf. roadmap This is a priority item on the roadmap for the next major release. strategic Strategic initative with far-reaching effects (in time and code space)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants