hexadecimal literal types and sign mess

[dgutson .]

As far as I understand, the type of literals such as 0xFFFFFFFF depends on the integral type that can represent them, in the list int, unsigned int, long int, etc.

And, if I also understand correctly, this wouls end up depending on the platform's int size, turning the reliable usage of these literals non portable, especially when they are used in bitwise and/or right-shifting operations.

I would like to open the discussion for how to solve the portability issue as a standard solution. For example, by defining a new literal suffix, or a UDL.

In other words, I would like to ensure that the type (and especially the sign) of an hexadecimal literal is fixed without depending on the integer size.

Opinions?

Thanks,

    Daniel.

--

Who’s got the sweetest disposition?
One guess, that’s who?
Who’d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

[Thiago Macieira]

On Wednesday, 29 November 2017 12:03:52 PST dgutson . wrote:
> I would like to open the discussion for how to solve the portability issue
> as a standard solution. For example, by defining a new literal suffix, or a
> UDL.
> In other words, I would like to ensure that the type (and especially the
> sign) of an hexadecimal literal is fixed without depending on the integer
> size.

Why do we need anything?

int(0xFFFFFFFF);
0xFFFFFFFFU;
0xFFFFFFFFULL;

etc.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Myriachan]

On Wednesday, November 29, 2017 at 12:47:51 PM UTC-8, Thiago Macieira wrote:

On Wednesday, 29 November 2017 12:03:52 PST dgutson . wrote:
> I would like to open the discussion for how to solve the portability issue
> as a standard solution. For example, by defining a new literal suffix, or a
> UDL.
> In other words, I would like to ensure that the type (and especially the
> sign) of an hexadecimal literal is fixed without depending on the integer
> size.

Why do we need anything?

        int(0xFFFFFFFF);
        0xFFFFFFFFU;
        0xFFFFFFFFULL;

etc.

Not to mention UINT64_C and such in <cstdint>.

Melissa

[dgutson .]

On Wed, Nov 29, 2017 at 5:47 PM, Thiago Macieira <thi...@macieira.org> wrote:

On Wednesday, 29 November 2017 12:03:52 PST dgutson . wrote:
> I would like to open the discussion for how to solve the portability issue
> as a standard solution. For example, by defining a new literal suffix, or a
> UDL.
> In other words, I would like to ensure that the type (and especially the
> sign) of an hexadecimal literal is fixed without depending on the integer
> size.

Why do we need anything?

We may not need anything, that's why I opened the discussion :)

 

        int(0xFFFFFFFF);

This suffers the portability problem I mentioned initially: int may be smaller.

And what I wanted to suggest are suffices, rather than casts or creation of types, such as int32_t(0xFFFFFFFF) (which, by the way, is that a literal as well by definition?).

 

        0xFFFFFFFFU;
        0xFFFFFFFFULL;

I think that the problem is for the signed literals. In the case of unsigned literals, what's the exact size of the u suffix? Is it portable?

Maybe this can be summarized in fixed-size suffices.

 

etc.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/35287753.28XM5GbDuN%40tjmaciei-mobl1.

[Nicol Bolas]

On Wednesday, November 29, 2017 at 4:19:07 PM UTC-5, dgutson wrote:

On Wed, Nov 29, 2017 at 5:47 PM, Thiago Macieira <thi...@macieira.org> wrote:

On Wednesday, 29 November 2017 12:03:52 PST dgutson . wrote:
> I would like to open the discussion for how to solve the portability issue
> as a standard solution. For example, by defining a new literal suffix, or a
> UDL.
> In other words, I would like to ensure that the type (and especially the
> sign) of an hexadecimal literal is fixed without depending on the integer
> size.

Why do we need anything?

We may not need anything, that's why I opened the discussion :)

 

        int(0xFFFFFFFF);

This suffers the portability problem I mentioned initially: int may be smaller.

Smaller than what, exactly? `int` is required by the standard to be a signed number that offers at least 32-bits of precision; MAX_INT cannot be less than 2^31-1.

The standard has guarantees about the minimum sizes of various types. So if you code against those, you're portable.

[dgutson .]

On Wed, Nov 29, 2017 at 6:34 PM, Nicol Bolas <jmck...@gmail.com> wrote:

On Wednesday, November 29, 2017 at 4:19:07 PM UTC-5, dgutson wrote:

On Wed, Nov 29, 2017 at 5:47 PM, Thiago Macieira <thi...@macieira.org> wrote:

On Wednesday, 29 November 2017 12:03:52 PST dgutson . wrote:
> I would like to open the discussion for how to solve the portability issue
> as a standard solution. For example, by defining a new literal suffix, or a
> UDL.
> In other words, I would like to ensure that the type (and especially the
> sign) of an hexadecimal literal is fixed without depending on the integer
> size.

Why do we need anything?

We may not need anything, that's why I opened the discussion :)

 

        int(0xFFFFFFFF);

This suffers the portability problem I mentioned initially: int may be smaller.

Smaller than what, exactly? `int` is required by the standard to be a signed number that offers at least 32-bits of precision; MAX_INT cannot be less than 2^31-1.

OK my bad.

So we are good also for 0xFFFFFFFFFF ? (a literal bigger than 32 bits)

 

The standard has guarantees about the minimum sizes of various types. So if you code against those, you're portable.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a5f2d2bc-5416-4a7c-a8b8-db8d2c651636%40isocpp.org.

[Michał Dominiak]

On Wed, Nov 29, 2017 at 10:34 PM Nicol Bolas <jmck...@gmail.com> wrote:

On Wednesday, November 29, 2017 at 4:19:07 PM UTC-5, dgutson wrote:

On Wed, Nov 29, 2017 at 5:47 PM, Thiago Macieira <thi...@macieira.org> wrote:

On Wednesday, 29 November 2017 12:03:52 PST dgutson . wrote:
> I would like to open the discussion for how to solve the portability issue
> as a standard solution. For example, by defining a new literal suffix, or a
> UDL.
> In other words, I would like to ensure that the type (and especially the
> sign) of an hexadecimal literal is fixed without depending on the integer
> size.

Why do we need anything?

We may not need anything, that's why I opened the discussion :)

 

        int(0xFFFFFFFF);

This suffers the portability problem I mentioned initially: int may be smaller.

Smaller than what, exactly? `int` is required by the standard to be a signed number that offers at least 32-bits of precision; MAX_INT cannot be less than 2^31-1.

Citation needed.

`int` is required to be at least 16 bits; the C++ standard refers to the C standard, and the C standard says that INT_MAX must be at least 32767.

What you are claiming about `int` is, in fact, true about `long`.

[Thiago Macieira]

On Wednesday, 29 November 2017 13:19:04 PST dgutson . wrote:
> > int(0xFFFFFFFF);
>
> This suffers the portability problem I mentioned initially: int may be
> smaller.

Then I don't understand what your problem is.

I thought you wanted to force a given literal to be of a given type,
regardless of whether it gets promoted. For example
0x7FFFFFFF
is an int, but
0xFFFFFFFF
is unsigned int and
0x100000000
is long. Note also that
0xFFFFFFFFL
is unsigned long on 32-bit and on Windows, and
0x100000000L
is long long there.

> And what I wanted to suggest are suffices, rather than casts or creation of
> types, such as int32_t(0xFFFFFFFF) (which, by the way, is that a literal as
> well by definition?).

Why do you need a literal? In what context would a literal work but function-
style casting would not?

> > 0xFFFFFFFFU;
> > 0xFFFFFFFFULL;
>
> I think that the problem is for the signed literals. In the case of
> unsigned literals, what's the exact size of the u suffix? Is it portable?

It's unsigned, with whatever size unsigned is.

[Nicol Bolas]

Fair enough. My point is that there are guarantees in the standard. If you are writing a literal number that you know needs X precision, then you can use the type Y that is guaranteed to provide that precision. And thereby write portable code.

[Victor Dyachenko]

Use types like uint_least16_t, int_least32_t, etc when you need portability and minimal length guarantee

[Victor Dyachenko]

On Friday, December 1, 2017 at 10:08:43 AM UTC+3, Victor Dyachenko wrote:

Use types like uint_least16_t, int_least32_t, etc when you need portability and minimal length guarantee

In addition it perfectly documents your intention in code (as opposed to using just int when you need at least 16 bits).