Error in static_assert example?

[u97...@gmail.com]

In page 148 (N4296) there's a static_assert example

-----------------------------

[ Example:
static_assert(sizeof(long) >= 8, "64-bit code generation required for this library.");
—end example ]

-----------------------------

For such a short code, there seems to be two errors, but I would like have a confirmation:
    -sizeof(long) should be sizeof(void*)?
    -Comparison should be == 8 or the comment "At least 64-bit code generation..."?

While this is just a small example, for someone having frustrating experiences with code that won't work in 64-bit Windows build at least partly due to pointers being casted to long (in 64-bit MSVC sizeof(long) < sizeof(void*)), this kind of example in C++ standard itself stands out especially since, please correct if wrong, the code is not portable C++.

If this is erroneous, what would be a correct replacement to be suggested, perhaps
static_assert(sizeof(void*) == 8, "64-bit code generation required for this library.");

[Nicol Bolas]

On Sunday, March 15, 2015 at 9:33:25 AM UTC-4, u97...@gmail.com wrote:

In page 148 (N4296) there's a static_assert example

-----------------------------

[ Example:
static_assert(sizeof(long) >= 8, "64-bit code generation required for this library.");
—end example ]

-----------------------------

For such a short code, there seems to be two errors, but I would like have a confirmation:
    -sizeof(long) should be sizeof(void*)?

Few are the C++ compilers that, when compiling 64-bit, will make long 64-bits in size. However, that doesn't mean that a particular user might not write code that only works on those few compilers. So the test itself is not a priori wrong, simply unconventional.

    -Comparison should be == 8 or the comment "At least 64-bit code generation..."?

While this is just a small example, for someone having frustrating experiences with code that won't work in 64-bit Windows build at least partly due to pointers being casted to long (in 64-bit MSVC sizeof(long) < sizeof(void*)), this kind of example in C++ standard itself stands out especially since, please correct if wrong, the code is not portable C++.

Any such static_assert is not intended to be "portable C++". The only way to write completely portable C++ is to work with whatever sizes the compiler supplies. By putting this static_assert in, you're announcing that you aren't writing "portable C++".

[u97...@gmail.com]

On Sunday, 15 March 2015 18:48:25 UTC+2, Nicol Bolas wrote:

On Sunday, March 15, 2015 at 9:33:25 AM UTC-4, u97...@gmail.com wrote:

In page 148 (N4296) there's a static_assert example

-----------------------------

[ Example:
static_assert(sizeof(long) >= 8, "64-bit code generation required for this library.");
—end example ]

-----------------------------

For such a short code, there seems to be two errors, but I would like have a confirmation:
    -sizeof(long) should be sizeof(void*)?

Few are the C++ compilers that, when compiling 64-bit, will make long 64-bits in size. However, that doesn't mean that a particular user might not write code that only works on those few compilers. So the test itself is not a priori wrong, simply unconventional.

[assuming you meant "will make" = "wlll not make"]
As said Microsoft Visual C++ is one of those compilers, so we're not talking about marginal compilers here. But whether there are few or many is irrelevant, this is about correctness. If the intention of the test, as the comment suggests, is to test for 64 build (sizeof(void*) == 8), it's simply wrong, not unconventional.

 

    -Comparison should be == 8 or the comment "At least 64-bit code generation..."?

While this is just a small example, for someone having frustrating experiences with code that won't work in 64-bit Windows build at least partly due to pointers being casted to long (in 64-bit MSVC sizeof(long) < sizeof(void*)), this kind of example in C++ standard itself stands out especially since, please correct if wrong, the code is not portable C++.

Any such static_assert is not intended to be "portable C++". The only way to write completely portable C++ is to work with whatever sizes the compiler supplies. By putting this static_assert in, you're announcing that you aren't writing "portable C++".

By portable in this context I meant that it will do the right thing for all compilers where the 64-bit build can be done.

[Nicol Bolas]

On Sunday, March 15, 2015 at 1:26:26 PM UTC-4, u97...@gmail.com wrote:

On Sunday, 15 March 2015 18:48:25 UTC+2, Nicol Bolas wrote:

On Sunday, March 15, 2015 at 9:33:25 AM UTC-4, u97...@gmail.com wrote:

In page 148 (N4296) there's a static_assert example

-----------------------------

[ Example:
static_assert(sizeof(long) >= 8, "64-bit code generation required for this library.");
—end example ]

-----------------------------

For such a short code, there seems to be two errors, but I would like have a confirmation:
    -sizeof(long) should be sizeof(void*)?

Few are the C++ compilers that, when compiling 64-bit, will make long 64-bits in size. However, that doesn't mean that a particular user might not write code that only works on those few compilers. So the test itself is not a priori wrong, simply unconventional.

[assuming you meant "will make" = "wlll not make"]

 "Few" "will make".
 

As said Microsoft Visual C++ is one of those compilers, so we're not talking about marginal compilers here. But whether there are few or many is irrelevant, this is about correctness. If the intention of the test, as the comment suggests, is to test for 64 build (sizeof(void*) == 8), it's simply wrong, not unconventional.

Maybe this programmer doesn't think having 64-bit pointers is "sufficiently 64-bit" for them. This programmer clearly needs 'long' to be 64-bit, since that's what he's testing. And he doesn't consider any compiler that makes its 'long' 32-bits in 64-bit mode to be a "real" 64-bit compiler.

That's a legitimate, if unconventional, distinction for a programmer to make.
 

 

    -Comparison should be == 8 or the comment "At least 64-bit code generation..."?

While this is just a small example, for someone having frustrating experiences with code that won't work in 64-bit Windows build at least partly due to pointers being casted to long (in 64-bit MSVC sizeof(long) < sizeof(void*)), this kind of example in C++ standard itself stands out especially since, please correct if wrong, the code is not portable C++.

Any such static_assert is not intended to be "portable C++". The only way to write completely portable C++ is to work with whatever sizes the compiler supplies. By putting this static_assert in, you're announcing that you aren't writing "portable C++".

By portable in this context I meant that it will do the right thing for all compilers where the 64-bit build can be done.

But if he's writing code that asserts on the size of a long, then it won't be portable to all 64-bit compilers. It will only be portable to 64-bit compilers that make 'long' 64-bits in size.

[Thiago Macieira]

On Sunday 15 March 2015 06:33:25 u97...@gmail.com wrote:
> [ Example:
> static_assert(sizeof(long) >= 8, "64-bit code generation required for this
> library.");
> —end example ]

Don't worry, that's not how people detect 64-bit builds.

Most code simply checks for the _WIN64 and __LP64__ macros...

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[u97...@gmail.com]

Yes there can be valid reasons for the programmer to require sizeof(long) >= 8, but it's about the consistency between the condition and the comment. If the comment would be something like "Require non LLP64/IL32P64 data model" or "Require long to be at least 64-bits, fine, but it's something else.

[u97...@gmail.com]

On Sunday, 15 March 2015 19:37:06 UTC+2, Thiago Macieira wrote:

On Sunday 15 March 2015 06:33:25 u97...@gmail.com wrote:
> [ Example:
> static_assert(sizeof(long) >= 8, "64-bit code generation required for this
> library.");
> —end example ]

Don't worry, that's not how people detect 64-bit builds.

Most code simply checks for the _WIN64 and __LP64__ macros...

It's not about the way to detect 64-bit platform, it's about the promotion of the misconception that it's correct to assume sizeof(long) == sizeof(void*), which I think is what the example is implicitly doing. And the reason for the attention to such detail is not theoretical, but stem from seeing too much code that has no Win64 build due to such problems and when that assumption propagates to KLOC or MLOC codebase, fixing it can be very far from being trivial.


 

[Tony V E]

On Sun, Mar 15, 2015 at 6:18 PM, <u97...@gmail.com> wrote:

On Sunday, 15 March 2015 19:37:06 UTC+2, Thiago Macieira wrote:

On Sunday 15 March 2015 06:33:25 u97...@gmail.com wrote:
> [ Example:
> static_assert(sizeof(long) >= 8, "64-bit code generation required for this
> library.");
> —end example ]

Don't worry, that's not how people detect 64-bit builds.

Most code simply checks for the _WIN64 and __LP64__ macros...

It's not about the way to detect 64-bit platform, it's about the promotion of the misconception that it's correct to assume sizeof(long) == sizeof(void*), which I think is what the example is implicitly doing. And the reason for the attention to such detail is not theoretical, but stem from seeing too much code that has no Win64 build due to such problems and when that assumption propagates to KLOC or MLOC codebase, fixing it can be very far from being trivial.


 

I'd rather the comment change than the check.  "64-bit code generation" can mean many things, so checking for sizeof(void*) could also be wrong.

But:

   static_assert(sizeof(long) >= 8, "This library requires longs to be at least 64 bits");
 

is pretty accurate.

Wait, actually, if 64 bits was the goal, it should be sizeof(long) * CHAR_BIT >= 64, in case they had 16 bit chars.  And require a #include for CHAR_BIT.

Or "This library requires longs to be at least 8 times larger than chars" ?

[u97...@gmail.com]

Thanks for the input; those were just the kind of details I was expecting to have failed to notice (e.g. the CHAR_BIT). Nevertheless I reckon that in vast majority of cases CHAR_BIT is 8 and "64-bit code generation" means sizeof(void*) == 8, so given all the choices for an example one has to demonstrate the behaviour of static_assert, current example seems particularly poorly chosen (although this is not the only usage of static_assert in the standard).

As said in earlier post, my motivation for this originates from practice and while I would hope to have experienced a very rare case of misuse of long in pointer casts, the fact that there's this kind of example even in the standard limits my optimism. So I would like to see this "fixed", but since I'm not that familiar how the standard evolves in practice, I would appreciate to have an advice whether this is kind of thing that qualifies as a new defect report to begin with? And if so, what would be an example neutral enough to demonstrate static_assert without rising such concerns? Some candidates for starters:
static_assert(sizeof(void*) >= 8, "Pointer size should be at least 8");
static_assert(sizeof(T) == 8, "Size of T should be 8");
static_assert(std::is_integral<T>::value == true, "T should be an integral type");

[Matthew Woehlke]

On 2015-03-15 12:48, Nicol Bolas wrote:
> On Sunday, March 15, 2015 at 9:33:25 AM UTC-4, u97...@gmail.com wrote:
>> In page 148 (N4296) there's a static_assert example
>>
>> -----------------------------
>>
>> [ Example:
>> static_assert(sizeof(long) >= 8, "64-bit code generation required for this
>> library.");
>> —end example ]
>>
>> -----------------------------
>>
>> For such a short code, there seems to be two errors, but I would like have
>> a confirmation:
>> -sizeof(long) should be sizeof(void*)?
>
> Few are the C++ compilers that, when compiling 64-bit, will make long
> 64-bits in size.

Er... no. LP64 was the de-facto standard (at least on desktop and larger
machines) until Microsoft decided to not follow it. Windows is the only
(64-bit) system I'm aware of that is not LP64. Desktop Linux, Solaris,
HP-UX, Irix, and others are all LP64. At best¹, that's several compilers
that are either pure LP64 or are IL32LLP64 on Windows and LP64
otherwise, versus *one* compiler, MSVC, that is only IL32LLP64. (And I'm
not even 100% sure that gcc/clang/etc. aren't LP64 on Windows too,
particularly in e.g. mingw / cygwin modes.)

(¹ That's "best" as in "best (most favorable) for your argument".
"Worst" would be MSVC is *the only* non-LP64 compiler. I don't think
that's actually the case, but your assertion is still backwards.)

> However, that doesn't mean that a particular user might
> not write code that only works on those few compilers. So the test itself
> is not a priori wrong, simply unconventional.

Assuming LP64 was a perfectly valid assumption for years before
Microsoft decided to ignore the convention and create yet another
impediment to writing portable code. (I've been there. My previous job
was on a large project that supported a lot of platforms, including many
64-bit, that was written before there was such a thing as amd64 Windows.
We were *really* irritated that Microsoft went IL32LLP64, as it made it
*much more difficult* to port to that platform.)

That said, I generally agree with your statement, if by "unconventional"
you mean that whoever wrote that only cares about platforms that *don't*
go out of their way to make porting painful :-).

>> While this is just a small example, for someone having frustrating
>> experiences with code that won't work in 64-bit Windows build at least
>> partly due to pointers being casted to long (in 64-bit MSVC sizeof(long) <
>> sizeof(void*)), this kind of example in C++ standard itself stands out
>> especially since, please correct if wrong, the code is not portable C++.
>
> Any such static_assert is not intended to be "portable C++". The only way
> to write completely portable C++ is to work with whatever sizes the
> compiler supplies. By putting this static_assert in, you're announcing that
> you aren't writing "portable C++".

True, but it's still a bad example; as others have covered, the
assertion and text should match better. I'd like to think we can strive
to avoid poor examples such as this in the standard :-).

--
Matthew

[Thiago Macieira]

On Tuesday 24 March 2015 10:24:22 Matthew Woehlke wrote:
> (And I'm
> not even 100% sure that gcc/clang/etc. aren't LP64 on Windows too,
> particularly in e.g. mingw / cygwin modes.)

They're LLP64 too because otherwise you'd have ABI mismatch problems when
dealing with the Win32 API and the headers from Windows SDK.

[u97...@gmail.com]

Unless LP64 has been quaranteed in the C++ standard, I don't see how it could have ever been a valid assumption.

[Matthew Woehlke]

On 2015-03-25 14:33, u97...@gmail.com wrote:
> On Tuesday, 24 March 2015 16:24:45 UTC+2, Matthew Woehlke wrote:
>> Assuming LP64 was a perfectly valid assumption for years before
>> Microsoft decided to ignore the convention and create yet another
>> impediment to writing portable code.
>
> Unless LP64 has been quaranteed in the C++ standard, I don't see how it
> could have ever been a valid assumption.

That depends on your definition of "valid".

I assume, for example, that a 'char' is eight bits. Whether or not this
is mandated by the standard, I would call it "a valid assumption"
because in practice I don't encounter or care about any platforms for
which this is not the case. Similarly, before WIN64 came along, I had
code that built on a number of platforms that were all LP64. Assuming
LP64 was therefore a "correct" (de facto) assumption for what I was
doing, regardless of whether or not it was standard mandated (de jure)
or not.

I used "valid", above, in the "de facto correct" sense, not the "de
jure" sense.

Now, I realize that there *are* platforms with other-than-eight-bit
'char'. The reality is that many developers will never encounter such
platforms, and I'd guess there is a lot of code "in the wild" making
that assumption that is broken on such platforms. The same was true for
LP64. Less so now that MS has introduced a popular platform that
violates the previously-reasonable-in-many-common-cases assumption, but
based on the comments in this thread, such code is not all dead or fixed
yet.

--
Matthew

[u97...@gmail.com]

In a way I agree, but feel that assumptions LP64 and CHAR_BIT=8 are very different in practice.

-Simply the coverage. LP64 is not valid on the operating system family that reportedly has for past decades covered most of personal computers in the world, while platform with CHAR_BIT != 8 is something that perhaps most developers have never seen (at least I haven't, not that it tells much). While Win64 systems are not that new, I would reckon that the specs that it will not be LP64 has been around for quite a long time.

-Having CHAR_BIT != 8 sounds something that really affects the way code is written. Or actually it's even simpler: vast majority of programs use libraries and the libraries most likely won't work on platforms with CHAR_BIT != 8 so the assumption is forced from the beginning. And library writers most likely want to spent their time on something else than e.g. thinking how to write constants, enum flags (0x1, 0x2...) and masks that works on all possible CHAR_BIT combinations. Or how about bit shift limits, integer <-> floating point conversion behaviour etc.? In contrast, whether or not sizeof(long) is equal to sizeof(void*) doesn't seem like a profound matter. But admittedly I have the feeling of not noticing something here because I find it difficult to see that there would actually be that much of proper use for integer type with guarantee "sizeof(long) >= sizeof(int)" to begin with; examples are welcome. In particular, it's size is not guaranteed to be == sizeof(void*) or == sizeof(size_t), which is the type that many standard functions return.

-This is not just about 64-bitness. I'm not an expert on the area, but 32 come after 16, 64 after 32 from this short sequence an (uneducated) guess would be that it won't stop there even if it is not topical. And what should long be in 128-bit systems and will even the LP64 camp for sure continue with sizeof(long) == sizeof(void*)? The relevancy on the matter is that even if Windows would have chosen LP64, would the relevant LP64 assumptions even then have been valid, future-proof assumptions?

[Nevin Liber]

11 days and 15 messages?

I'm pretty sure this could be handled editorially should someone submit an issue for it.

I'm just sayin'...

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussio...@isocpp.org.
To post to this group, send email to std-dis...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.

--

 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  (847) 691-1404

[u97...@gmail.com]

Being the one bringing up this matter, I can take a look at submitting an issue, although I might leave the 'proposed wording' empty so that more proficient people can come up with a better example.

[Myriachan]

On Monday, March 30, 2015 at 9:33:10 AM UTC-7, u97...@gmail.com wrote:

Being the one bringing up this matter, I can take a look at submitting an issue, although I might leave the 'proposed wording' empty so that more proficient people can come up with a better example.

static_assert(std::numeric_limits<int>::min() < -std::numeric_limits<int>::max(),
    "This library requires a two's-complement machine.");

I traditionally write this with extra parentheses, though, due to the tendency for some headers to define min and max macros:

static_assert((std::numeric_limits<int>::min)() < -(std::numeric_limits<int>::max)(),
    "This library requires a two's-complement machine.");

I doubt the extra parentheses should be in the Standard, though...?

Melissa

[Thiago Macieira]

On Monday 30 March 2015 12:14:57 Myriachan wrote:
> I doubt the extra parentheses should be in the Standard, though...?

No, please let's not do it. The extra parentheses make for a weird read and
would require additional explanation.

Headers that still define bool, min and max as macros should be shot with
prejudice (yes, I'm looking at you, X11/Xlib.h and windows.h).

[Nevin Liber]

On 30 March 2015 at 14:14, Myriachan <myri...@gmail.com> wrote:

On Monday, March 30, 2015 at 9:33:10 AM UTC-7, u97...@gmail.com wrote:

Being the one bringing up this matter, I can take a look at submitting an issue, although I might leave the 'proposed wording' empty so that more proficient people can come up with a better example.

static_assert(std::numeric_limits<int>::min() < -std::numeric_limits<int>::max(),
    "This library requires a two's-complement machine.");

I traditionally write this with extra parentheses, though, due to the tendency for some headers to define min and max macros:

static_assert((std::numeric_limits<int>::min)() < -(std::numeric_limits<int>::max)(),
    "This library requires a two's-complement machine.");

That seems awfully complicated for an example which is showing how static_assert works...

[u97...@gmail.com]

I also think that the numeric_limits example is quite complicated for being a simple example. And given rarely thought aspects such as possibility for CHAR_BIT != 8 and especially those that one isn't even aware of, for non-experts such as myself it's not even completely clear whether the example is guaranteed to be valid for all possible implementations, so it's out of my scope at least.

[Chris Hallock]

Myriachan wrote:

static_assert(std::numeric_limits<int>::min() < -std::numeric_limits<int>::max(),
    "This library requires a two's-complement machine.");

On theoretical ones' complement or signed magnitude implementations, the signed negation overflows and... bam! Nasal demons everywhere.

[Casey Carter]

Sign-magnitude: -(011...111) == (111...111) does not overflow.

One's complement: -(011...111) == (100...000) does not overflow.

The whole point of the test is that -max = min + 1 in two's complement systems, whereas -max = min on one's complement and sign-magnitude.

[David Krauss]

On 2015–03–31, at 12:33 AM, u97...@gmail.com wrote:

Being the one bringing up this matter, I can take a look at submitting an issue, although I might leave the 'proposed wording' empty so that more proficient people can come up with a better example.

There’s no “proposed wording” to worry about. Just briefly describe your concern at https://github.com/cplusplus/draft/issues .

You might be thinking of the ISO defect report process, which is more complicated.

If machine word size determination somehow controversial, just invent a different example. A more foolproof demonstration in the same vein is:

static_assert ( std::numeric_limits< double >::digits10 >= 10, "Machine must support 10 digits of precision." );

[Chris Hallock]

Casey Carter wrote:

The whole point of the test is that -max = min + 1 in two's complement systems, whereas -max = min on one's complement and sign-magnitude.

Ahhh, you're right, I badly misread Myriachan's example. Sorry....

[u97...@gmail.com]

Thanks for the Github hint. I wasn't aware of it as there was no mention about it in isocpp.org -> Standardization -> How to Submit a New Issue / Defect Report (https://isocpp.org/std/submit-a-library-issue), which seemed like the best place to start.

[Ville Voutilainen]

On 30 March 2015 at 23:48, <u97...@gmail.com> wrote:
> I also think that the numeric_limits example is quite complicated for being
> a simple example. And given rarely thought aspects such as possibility for
> CHAR_BIT != 8 and especially those that one isn't even aware of, for
> non-experts such as myself it's not even completely clear whether the
> example is guaranteed to be valid for all possible implementations, so it's
> out of my scope at least.

I have good news and bad news for you. Examples are not normative, so they
are not guaranteed to be valid to begin with, let alone for all
possible implementations.

If you feel like asking whether that was the good or bad news, and
where's the other, that was both.

That doesn't mean that examples won't be improved if they are lacking,
either via issue processing
or editorially, but I do recommend against reading too much into
examples, especially an example
that's trying to illustrate what static_assert does, rather than
providing a canonical means
to detect a 64-bit platform.

[Tony V E]

In theory, C++ supports other representations besides those ones.  (C does not.)

Tony

[u97...@gmail.com]

While the standard is obviously not the place to look for educating examples, when you have had to deal with code that in some aspects seems to be almost beyond repair because of the widespread use of assumption sizeof(void*) == sizeof(long), I hope it's understandable that it's somewhat disturbing to see essentially the same assumption even in the standard's example. But given the reasons behind my motivation, my views on the importance of this tiny detail can be expected to be biased. It's has been educating to see insights from other people, thank you for those, and I'll see later if, based on this (rather long) thread, I find it worth doing the report on github.

[Richard Smith]

I've editorially updated the example to

  static_assert(char(-1) < 0, "this library requires plain 'char' to be signed");

Hopefully that will prove less contentious. Incidentally, threads such as this one are the reason why the core language usually avoids meaningful example and tends to use names such as T or foo.

[Thiago Macieira]

On Wednesday 08 April 2015 11:20:52 Richard Smith wrote:
> Hopefully that will prove less contentious. Incidentally, threads such as
> this one are the reason why the core language usually avoids meaningful
> example and tends to use names such as T or foo.

And yet examples are so helpful when reading the spec to understand what was
meant.

This thread was a total bikeshed. As such, bikesheds can and should be
ignored.

Thanks Richard for fixing the issue without creating more contentious cases.