Ecma262: Please use uint8_t instead of unsigned char etc

[safinaskar]

Subsection "TypedArray Objects" has a table. The table has a column "Equivalent C Type", which currently reads: "signed char", "unsigned char", "short" etc. Unfortunately, C standard doesn't guarantee exact size for all this types (even for chars). So, please use types int8_t, uint8_t, int16_t etc instead, or, better, simply remove this column

[littledan]

@safinaskar That sounds like a great idea. Would you like to make a PR for this change?

[safinaskar]

@littledan, no. I don't know what you will decide: to fix column or to remove it

[safinaskar]

@littledan, anyway I am not interested in making trivial PRs

[kaicataldo]

What's the required change here? I'd love to make a trivial PR!

[jridgewell]

@kaicataldo: Change the column values to use int8_t, etc.

[devsnek]

@kaicataldo in the table here: https://tc39.github.io/ecma262/#sec-typedarray-objects

there's a column called "Equivalent C Type." it currently contains types like signed char and double. However these types actually do not have any specified width, unlike the TypedArray types they are in the table with.

The fix would be to either change stuff like signed char to int8_t and unsigned char to uint8_t etc, or to just remove the column entirely.

Personally I would just remove the column entirely, the other columns are more than enough information.

[littledan]

I am on the fence here. When I was implementing TypedArray methods, I felt like that column was kind of silly and not meaningful. However, looking back, it seems like some good exposition for new readers. If we keep it, I think it would be nice to make it clear that it is non-normative (i.e. a note).

[safinaskar]

Also, C standard doesn't guarantee that float, double etc confirm to IEEE. So, we have to leave corresponding cells empty. I still think that the best solution is to remove this column. Even if you choose to keep it, please state that this column is informational

[kaicataldo]

Sorry - had a family emergency and lost track of this. Sounds like there isn't consensus on the best way forward yet, so I'll hold off on a PR for now.

[ljharb]

So, would we prefer to remove the column, or to update the values? It seems like removing the column would be better than referring to C.

[rkirsling]

I'd vote for removing the column. It appears that the original intent was to put a "name" (like char or short) alongside types that are otherwise largely identified by a number. Yet if we use the fixed-width types, then the Equivalent C Type column will in essence just be a duplicate of the Element Type column.