What exactly does that improve? What is unclear about the first part of the sentence?

It clarifies which units of type sizes we are talking about.

How many different units of type sizes are there?

The point I'm trying to make is that AFAIK we nowhere else say that the size of a type is N (except when we say for example "non-zero size"), but we say that in terms of sizeof or we speak of number of bytes. I think that speaking in terms of sizeof just makes the existing wording clearer.

Hm, [basic.fundamental] and [conv.rank] use the term "size" without going through extensive "result of sizeof" gymnastics... I mean, I understand what you're saying, but it would also never have occurred to me that this sentence could be misunderstood or cause implementation divergence... @zygoloid, what do you think?

I'm unconvinced a change is needed, but if it is, "the result of sizeof yields 1" seems wrong. Either sizeof yields 1, or the result of sizeof is 1, but the result doesn't yield anything.

I'm happy with either form.

The sizeof operator is defined to yield the number of bytes. I’m not aware of units of size other than bits, bytes, and elements. Since this isn’t an array or vector, and all of those types must be larger than one bit, the only logical interpretation of the sentence as it currently stands is that it means bytes.

If that does need clarification, I think “If every scalar type has a size of 1 byte” is clearer because it avoids indirection of the definition through sizeof.

If that wording would require clarification, I would have opened an LWG issue instead of an editorial issue, the whole point here is the request for an editorial improvement. I' m happy with any rewording that uses either sizeof or speaks of units of bytes or does in any other way clarify what size units we are talking about.

What about bit order?

I mean, these days, most systems use the "least significant bit is bit 0" format, but there are systems out there that support the "least significant bit is bit 7" format.

Also, I feel like calling it little/big endian is just confusing, just call it the byte order.

Anyway, how can we recommend C2X to include such a feature as well? like, I'm writing a bit reader/writer in C, and this would be a fantastic feature to have...

@bumblebritches57 : Your comment seems to be a request for another feature, which seems unrelated to the present editorial issue.

(Pointer to members have size 2 on any conceivably platform where pointers have size 1.)

Editorial meeting consensus: "If all scalar types have size 1 byte, ..."

Thanks, very much appreciated.

No change has been done yet, the comment above simply records what was decided.

@jensmaurer No, it's a request to make this not completely useless.

Bit order matters, that's a thing that for some reason people don't want to believe exists.

DEFLATE uses the most significant bit first format, so do some forms of the BMP file format, as does some forms of CRC, it's everywhere.

Ignoring the harsh reality to make some idealized version of it doesn't help anyone.

It's not an editorial issue with the current wording, so is off-topic here. Please take it elsewhere.

https://github.com/cplusplus/draft/wiki/How-to-tell-if-an-issue-is-editorial

Where exactly is elsewhere you adversarial asshole?

@bumblebritches57 : I'm sorry, the original issue description here is discussing "sizeof". And that will get addressed by the "editorial meeting consensus". If you feel there is an issue with "bit order", please create a new issue which points to the standard wording that you believe is defective. (I don't think there is any; it's just not a feature we currently offer in the standard.) If you wish to propose such a feature, feel free to write a paper and submit it to WG21 for consideration in one of its future meetings.

I assume this charming individual is referring to http://open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0463r1.html so needs to read https://cplusplus.github.io/LWG/lwg-active.html#submit_issue

thanks for the advice @jensmaurer My only question is, these features are pretty related I think we can both agree, shouldn't they be pushed as one thing? I just don't get why we have to have the overhead of having 2 very related proposals.

Also, I've tried submitting proposals to the C working group (WG14) and it's a huge PITA, I wouldn't even know who to contact in WG21.

https://isocpp.org/std/submit-a-proposal

@bumblebritches57: Both Jens and Jonathan are trying to explain to you that what you suggest here to change is beyond the acceptance criteria for an editorial change request. Only editorial changes to the standard are accepted by this issue list. Normative wording change requests that cover defects need to be send to either the core language issue list (See the Reply-to field in http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html) when the issue affects the clauses before Clause 20 [library], or to the library issue list otherwise (See https://cplusplus.github.io/LWG/lwg-active.html#submit_issue as suggested by Jonathan). If instead of a defect report you would like to suggest to change normative wording for other reasons ("feature requests"), you should write a proposal for this, please read https://isocpp.org/std/submit-a-proposal for the way how to realize that. If you have any further questions in regard to that, I'll encourage you to send an email to the lwgchair (see Reply-to in http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html) where I will respond and where we can extend this discussion if you wish.

Fixed by 24bfe67.

Hey guys, sorry to reopen this issue yet again (the only reason I'm doing so is because Jens doesn't have his contact info public), but I've gone ahead and made my own proposal for C2x (I haven't submitted it yet tho) and I was just trying to get your opinions on my implementation?

it's available here: https://github.com/bumblebritches57/Endian

This is still not the right place.

Wow would you look at that, you're stating the fucking obvious again.

https://isocpp.org/std/submit-a-proposal contains information on where to solicit feedback on proposals and discuss ideas. This repository and its issue tracker are not the right place for such discussions (as in fact nobody interested in technical discussion follows this issues list).