api: fix typedefs to known length

[jiri-novotny]

all internal ULONG compares are defined in 32b e.g.

if (list_word == LX_NOR_PHYSICAL_SECTOR_FREE)

where

#define LX_NOR_PHYSICAL_SECTOR_FREE                 0xFFFFFFFF

this change maps internal types to known-length types from <stdint.h>

[jiri-novotny]

@microsoft-github-policy-service agree

[miracoli]

The fixed-width typedefs are reasonable for LevelX media data, but the current patch mixes media-word width and pointer width.

After this change:

typedef uint32_t ULONG;
#define ALIGN_TYPE ULONG

ALIGN_TYPE can no longer hold a pointer on a 64-bit standalone target, despite the comment requiring exactly that. It should probably be based on uintptr_t, and pointer-related size or alignment calculations should use sizeof(uintptr_t) or sizeof(ALIGN_TYPE).

This should not be applied indiscriminately: calculations describing LevelX flash words must continue to use sizeof(ULONG), because the on-media word size is defined as 32 bits.

The NOR and NAND simulators also still store flash words as unsigned long. On LP64 hosts, that type is 64-bit, while the PR changes ULONG to 32-bit. Casting those arrays to ULONG * and dividing their structure sizes by sizeof(ULONG) would therefore produce an inconsistent layout and potentially invalid aliasing or alignment.

I would suggest extending the PR to:

• use uintptr_t for pointer-capable alignment types;
• review pointer-sized calculations for sizeof(uintptr_t) or sizeof(ALIGN_TYPE);
• replace simulator flash-word storage with ULONG or uint32_t;
• add standalone tests for both LP64 and LLP64 hosts.

[fdesbiens]

@miracoli I agree with you this is a useful fix.

The issue is that this is an old PR predating the move of the codebase to Eclipse. So, I cannot merge it without the original author signing the ECA.

@jiri-novotny If you are still around, would you mind following the instructions below to sign the ECA, please?

@miracoli If the original author does not respond, an alternative would be submitting your own PR.

---

@jiri-novotny: Before accepting your contribution, you need to sign the Eclipse Contributor Agreement (ECA). The purpose of the ECA is to provide a written record that you have agreed to provide your code and documentation contributions under the licenses used by the Eclipse ThreadX project. It also makes it clear that you are promising that what you are contributing to Eclipse is code you wrote, and you have the necessary rights to contribute it to our projects. And finally, it documents a commitment from you that your open source contributions will be permanently on the public record.

Signing the ECA requires an Eclipse Foundation account if you do not already have one. You can create one for free at https://accounts.eclipse.org.

Be sure to use the same email address when you register for the account that you intend to use on Git commit records. Also, please add your GitHub ID to your Eclipse account. This enables synchronisation between Eclipse-owned infrastructure and GitHub.

Here is the link to sign the ECA:
https://accounts.eclipse.org/user/login?destination=user/eca