You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The discussion about support for JSON in issue #820 notes that symbols NV_JSON and NV_JSON_LAST are aliases for other symbols. Which is dangerous and shouldn't be necessary. So I opened PR #1037 to start work on eliminating such aliases. The next step in that cleanup is to change the definition of struct Namval member nvflag to be wider than an unsigned short. However turning it into a 32 bit unsigned int breaks unit tests. Even with no changes to the bit field symbols.
That should be impossible. That is, the size of that bit field should have zero effect on the behavior of the code as long as the size is wide enough to accommodate all bit values stored in that structure member. And converting from unsigned short (16 bits) to uint32_t (32 bits) is guaranteed to satisfy that constraint. This diff breaks 18 unit tests on macOS that pass without this change:
diff --git a/src/cmd/ksh93/include/nval.h b/src/cmd/ksh93/include/nval.h
index 66462dd9..ee293a5b 100644
--- a/src/cmd/ksh93/include/nval.h
+++ b/src/cmd/ksh93/include/nval.h
@@ -104,7 +104,7 @@ struct Namdecl {
struct Namval {
Dtlink_t nvlink; // space for cdt links
char *nvname; // pointer to name of the node
- unsigned short nvflag; // attributes
+ unsigned int nvflag; // attributes
#if _ast_sizeof_pointer >= 8
uint32_t nvsize; // size or base
#else
Something is seriously wrong with the code that allocates or uses a struct Namval. The aforementioned change should have zero effect on the behavior of the code other than the amount of memory used.
The discussion about support for JSON in issue #820 notes that symbols
NV_JSONandNV_JSON_LASTare aliases for other symbols. Which is dangerous and shouldn't be necessary. So I opened PR #1037 to start work on eliminating such aliases. The next step in that cleanup is to change the definition ofstruct Namvalmembernvflagto be wider than anunsigned short. However turning it into a 32 bit unsigned int breaks unit tests. Even with no changes to the bit field symbols.That should be impossible. That is, the size of that bit field should have zero effect on the behavior of the code as long as the size is wide enough to accommodate all bit values stored in that structure member. And converting from
unsigned short(16 bits) touint32_t(32 bits) is guaranteed to satisfy that constraint. This diff breaks 18 unit tests on macOS that pass without this change:Something is seriously wrong with the code that allocates or uses a
struct Namval. The aforementioned change should have zero effect on the behavior of the code other than the amount of memory used.