Clang and GCC have a builtin __SIZE_MAX__ macro which resolves to 32-bit or 64-bit ~0. MSVC doesn't though.
But maybe this would make sense? #if defined(__SIZE_MAX__) #define WGPU_WHOLE_SIZE (__SIZE_MAX__) #else ... #endif On Friday, 20 January 2023 at 02:12:27 UTC+1 kai...@google.com wrote: > Happy to help! I think you're right about ~0 just being 32-bits and thus > not the correct solution. Another possibility I've seen is -1, but this is > a bit sensitive to which casts you put it through (i32 -> i64 -> u64 is ok, > i32 -> u32 -> u64 is not ok). And whether you get warnings or not is > sensitive to the compiler and warning options used. > > -Kai (he/they) > > > On Wed, Jan 18, 2023 at 7:26 PM Mark Sibly <mark...@gmail.com> wrote: > >> Hi Kai, >> >> Thanks for that, I'll start using the right macros! >> >> I'm not sure ~0 is a good idea, it seems like a bit of a hack. In fact, >> it implies C converts 32->64 bit before converting signed->unsigned in >> situations where it has to do both, doesn't it? , ie: ~0u wouldn't work as >> you'd just end up with 0 in the upper bytes. Well, that's something new I >> learned today! >> >> Bah, whatever, back to work... >> >> Bye! >> Mark >> >> >> On Thu, Jan 19, 2023 at 4:07 PM Kai Ninomiya <kai...@google.com> wrote: >> >>> Forwarding directly while my message sits in the moderation queue. :) >>> >> >>> ---------- Forwarded message --------- >>> From: Kai Ninomiya <kai...@google.com> >>> Date: Wed, Jan 18, 2023 at 7:05 PM >>> Subject: Re: WGPU_WHOLE_SIZE warning >>> To: Sam Clegg <s...@google.com> >>> Cc: <emscripte...@googlegroups.com> >>> >>> >>> Thanks for the CC! Indeed there is a type difference, hence we have two >>> different macros and you're meant to use the other one here :) >>> >>> #define WGPU_WHOLE_MAP_SIZE SIZE_MAX >>> #define WGPU_WHOLE_SIZE (0xffffffffffffffffULL) >>> >>> This is a bit fussy, but it _is_ a C API.... In C++, things are a bit >>> better, because they're typed: >>> >>> static constexpr size_t kWholeMapSize = WGPU_WHOLE_MAP_SIZE; >>> static constexpr uint64_t kWholeSize = WGPU_WHOLE_SIZE; >>> >>> We could do this in the C API but it's somewhat unidiomatic - we had >>> someone complain about our use of static const instead of #define >>> before. >>> >>> That said we should probably consider the ~0 solution, maybe this would >>> let us get rid of the two definitions entirely. Would you file an issue to >>> suggest it here? >>> https://github.com/webgpu-native/webgpu-headers/ >>> >>> -Kai (he/they) >>> >>> >>> On Wed, Jan 18, 2023 at 4:14 PM Sam Clegg <s...@google.com> wrote: >>> >>>> It looks like WGPU_WHOLE_SIZE is designed to be used WGPUBindGroupEntry >>>> where size is 64-bit, but wgpuBufferMapAsync uses size_t for size (which >>>> is >>>> either 32-bit ot 64-bit depending on the architecture). >>>> >>>> I'm not sure if this is intended behaviour or not. Perhaps its a bug? >>>> cc'ing Kai who will know more. >>>> >>>> On Wed, Jan 18, 2023 at 2:57 PM Mark Sibly <mark...@gmail.com> wrote: >>>> >>>>> This works and gets rid of the warning: >>>>> >>>>> #define WGPU_WHOLE_SIZE ~0 >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "emscripten-discuss" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to emscripten-disc...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/emscripten-discuss/adac8f05-fb52-4124-8b73-d1354fd67485n%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/emscripten-discuss/adac8f05-fb52-4124-8b73-d1354fd67485n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/483c997d-263f-4083-aa7f-7306e3924194n%40googlegroups.com.
