What does the "L" mean

[T]

Hi All

MB_ICONEXCLAMATION
0x00000030L

What does the "L" at the end mean?

Many thanks,
-T

[Bonita Montero]

Am 04.12.2019 um 08:38 schrieb T:
> Hi All
> MB_ICONEXCLAMATION
> 0x00000030L
> What does the "L" at the end mean?

It means that the integral literal is a long.

[T]

64 bit integer?

[Geoff]

No. It has 8 hexadecimal digits and they are 4 bits each.
8 x 4 = 32 last I checked.

[T]

Cool. Thank you!

[T]

On 2019-12-03 23:43, Bonita Montero wrote:

Thank you!

[Fred. Zwarts]

Op 04.dec..2019 om 09:05 schreef T:

It means "long". The size of long depends on your platform.

[Paavo Helde]

Depends on the platform/implementation. In this case the constant is
from Windows headers, and in Windows/MSVC a long is 32-bit even in
64-bit Windows.

This is basically so because long happened to be 32-bit in 16-bit DOS 35
years ago, and MS used it a lot instead of 16-bit int (which was indeed
unusable for many purposes). As a result, now they cannot change 'long'
to 64-bit because they have abused it so much.

[T]

Thank you!

[T]

Great explanation. Thank you!

In Perl6 , we have:

int8 (int8_t in C)
int16 (int16_t in C)
int32 (int32_t in C)
int64 (int64_t in C)

$ p6 'my int64 $x=0xF; say $x;'
15

$ p6 'my int64 $x=0xFFFFFFFFFFFFFFF; say $x;'
1152921504606846975

$ p6 'my int64 $x=0xFFFFFFFFFFFFFFFF; say $x;'
Cannot unbox 64 bit wide bigint into native integer
in block <unit> at -e line 1

[Bo Persson]

Some languages historically also target more exotic hardware, so in C
(and C++) int and long are allowed be 36 bits instead of 16 and 32

https://stackoverflow.com/a/6972551


Bo Persson

[Paavo Helde]

Does not follow. 0x30L is not 8 bits even though it has 2 hex digits only.

The reason why MB_ICONEXCLAMATION is written with 8 hex digits is
because MS programmers *thought* long is always 32 bits.

[Geoff]

I agree. They were signaling to themselves to expect 32 bits.
Serves me right for being a smart ass about it. :)

[T]

36 bit? My brain hurts

[Bonita Montero]

>> Am 04.12.2019 um 08:38 schrieb T:
>>> Hi All
>>> MB_ICONEXCLAMATION
>>> 0x00000030L
>>> What does the "L" at the end mean?

>> It means that the integral literal is a long.

> 64 bit integer?

Forget it, these suffixes are mostly useless as the compiler can
determine the type from the value.

[Thiago Adams]

In C we have macros to expand to the corresponding size.
For instance
UINT64_C(0x123) might expand to the integer constant 0x123ULL.

[Fred. Zwarts]

Op 04.dec..2019 om 13:47 schreef Bonita Montero:

The suffixes can be very important, in particular if the macros are
later used in operations. Take as an example a platform where int is 16
bits and long is 32 bits.

#define V1 0X7EEE
#define V2 0X7EEEL

#define R1 (2 * V1)
#define R2 (2 * V2)

Then the result of R1 is undefined because of an integer overflow,
whereas R2 is defined.

[James Kuyper]

Op 04.dec..2019 om 13:47 schreef Bonita Montero:

The whole point of the suffixes is cope with the possibility (which
occurs pretty frequently) that the type that is determined by the value
differs from the one you want the constant to have. A cast can be more
specific, but a suffix is more convenient, when it's sufficient to do
what you want.

[Bonita Montero]

> The suffixes can be very important, in particular if the macros are
> later used in operations. Take as an example a platform where int is 16
> bits and long is 32 bits.
> #define V1 0X7EEE
> #define V2 0X7EEEL
> #define R1 (2 * V1)
> #define R2 (2 * V2)
> Then the result of R1 is undefined because of an integer overflow,
> whereas R2 is defined.

I wrote "mostly useless" and not "useless every time".

[Keith Thompson]

T <T...@invalid.invalid> writes:
> MB_ICONEXCLAMATION
> 0x00000030L
>
> What does the "L" at the end mean?

The type of a hexadecimal integer literal with an "L" suffix is of the
first of
long int
unsigned long int
long long int
unsigned long long int
in which its value will fit (C++11 2.14.2 [lex.icon]). Since long
int is guaranteed to be at least 32 bits, 0x00000030L is of type
long int.

The leading 0s are presumably intended to imply a 32-bit quantity,
which is probably the case for the system for which the code is
intended, but it's not guaranteed. (64-bit Linux-based systems
usually have 64-bit long; on such systems 0x00000030L is 64 bits.
It's *always* of type long int under any conforming implementations.)
Leading zeros are ignored. 0x00000000000000000000000000000030L
is equivalent to 0x00000030L.

A conforming implementation could make long int any size 32 bits
or wider. The size in bits is a multiple of CHAR_BIT, which is at
least 8. An implementation could have 33-bit long int; on such a
system characters would have to be either 11 or 33 bits.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[Vir Campestris]

On 04/12/2019 09:20, T wrote:
> 36 bit?  My brain hurts

I've used systems where the native word size is 16, 24, 32, 36 and 64
bit. Other values are available :(

The one that really strained C was the one where incrementing a pointer
by 1 went to the next bit. Not byte or word. (TI GPU)

The one with 36 bits (DECSystem10) an address was the address of a word,
and you couldn't point to a character inside the word. I didn't use C on it.

Andy

[Ben Bacarisse]

Vir Campestris <vir.cam...@invalid.invalid> writes:
<cut>

> The one that really strained C was the one where incrementing a
> pointer by 1 went to the next bit. Not byte or word. (TI GPU)

What problems does C have on a bit-addressed machine?

--
Ben.

[Vir Campestris]

Code that assumes you can copy a pointer into a number, then manipulate
it. Lots of people do it, even though they shouldn't.

sizeof is interesting when things don't have to be whole numbers of
bytes. (you have a greyscale graphics plane with 3 bits per pixel,
800x600. How much RAM is that? On this thing it was literally 3 _bits_
x800x600, when most machines would end up unpacking the pixels into bytes.)

But it's a long time ago. I don't recall all the details.

Andy

[Ben Bacarisse]

Vir Campestris <vir.cam...@invalid.invalid> writes:

> On 05/12/2019 01:33, Ben Bacarisse wrote:
>> Vir Campestris <vir.cam...@invalid.invalid> writes:
>> <cut>
>>> The one that really strained C was the one where incrementing a
>>> pointer by 1 went to the next bit. Not byte or word. (TI GPU)
>>
>> What problems does C have on a bit-addressed machine?
>
> Code that assumes you can copy a pointer into a number, then
> manipulate it. Lots of people do it, even though they shouldn't.

That also should work on a bit-addressed machine. You mean, I think,
that the code assumes some very specific things about the manipulation,
most probably that (int)(p + 1) == (int)p + sizeof *p.

<cut>
--
Ben.

[Robert Wessel]

On Wed, 04 Dec 2019 08:28:23 -0800, Keith Thompson <ks...@mib.org>
wrote:

>T <T...@invalid.invalid> writes:
>> MB_ICONEXCLAMATION
>> 0x00000030L
>>
>> What does the "L" at the end mean?
>
>The type of a hexadecimal integer literal with an "L" suffix is of the
>first of
> long int
> unsigned long int
> long long int
> unsigned long long int
>in which its value will fit (C++11 2.14.2 [lex.icon]). Since long
>int is guaranteed to be at least 32 bits, 0x00000030L is of type
>long int.
>
>The leading 0s are presumably intended to imply a 32-bit quantity,
>which is probably the case for the system for which the code is
>intended, but it's not guaranteed. (64-bit Linux-based systems
>usually have 64-bit long; on such systems 0x00000030L is 64 bits.
>It's *always* of type long int under any conforming implementations.)
>Leading zeros are ignored. 0x00000000000000000000000000000030L
>is equivalent to 0x00000030L.
>
>A conforming implementation could make long int any size 32 bits
>or wider. The size in bits is a multiple of CHAR_BIT, which is at
>least 8. An implementation could have 33-bit long int; on such a
>system characters would have to be either 11 or 33 bits.

To be pedantic, aren't longs allowed to have pad bits? Thus you could
have a 33-bit long stored in five 8-bit characters.

[Keith Thompson]

Robert Wessel <robert...@yahoo.com> writes:
> On Wed, 04 Dec 2019 08:28:23 -0800, Keith Thompson <ks...@mib.org>
> wrote:

[...]

>>A conforming implementation could make long int any size 32 bits
>>or wider. The size in bits is a multiple of CHAR_BIT, which is at
>>least 8. An implementation could have 33-bit long int; on such a
>>system characters would have to be either 11 or 33 bits.
>
> To be pedantic, aren't longs allowed to have pad bits? Thus you could
> have a 33-bit long stored in five 8-bit characters.

Yes, C++ permits padding bits (bits that do not contribute to
the value). You're suggesting a long type with a *size* of 5
bytes / 40 bits and a *width* of 33 bits, which is permitted.
(The width includes the sign bit.)

When I wrote "33-bit long int", I meant
CHAR_BIT * sizeof (long int) == 33
I could have made that clearer.

[Vir Campestris]

On 05/12/2019 15:31, Ben Bacarisse wrote:
> Vir Campestris<vir.cam...@invalid.invalid> writes:
>
>> On 05/12/2019 01:33, Ben Bacarisse wrote:
>>> Vir Campestris<vir.cam...@invalid.invalid> writes:
>>> <cut>
>>>> The one that really strained C was the one where incrementing a
>>>> pointer by 1 went to the next bit. Not byte or word. (TI GPU)
>>> What problems does C have on a bit-addressed machine?
>> Code that assumes you can copy a pointer into a number, then
>> manipulate it. Lots of people do it, even though they shouldn't.
> That also should work on a bit-addressed machine. You mean, I think,
> that the code assumes some very specific things about the manipulation,
> most probably that (int)(p + 1) == (int)p + sizeof *p.

You could write code that worked on that TI chip, making assumptions
about the way the addresses work.

You could also write code that works on the 99% of machines where

char vec[2];
assert(((int)&vec[1] - (int)vec) == 1);

works.

BTW the Dec10 - the 36 bit one I used - an int was 36 bits, but a
character string was stored as set of 5 7-bit ASCII characters plus one
pad bit in each word... Never used C on it though.

Andy

[Bart]

At least, on Windows 'long' is consistently 32-bit.

On Linux, as I understand it, 'long' is either 32 bits or 64 bits,
depending on whether the OS is 32 or 64 bits.

This means that if you use 'long' on Linux64, and depend on it being 64
bits, the same program might not work properly on Linux32.

And if a 'long' is wide enough on Linux32, then on Linux64 it will
wastefully be 64 bits (ie. an array of 'long' takes twice the memory).

(Suggestion: don't bother with 'long' at all; either use plain int (32
bits on most relevant machines), or long long int (64 bits), which has
the -LL suffix for constants that need to be considered 64 bits.)

[bol...@nowhere.co.uk]

#include <stdint.h>

int32_t myint;
int64_t mylong;
uint32_t myuint;
uint64_t myulong;

Sorted.

[Scott Lurndal]

Even better. Use the standard types uint64_t or uint_least64_t if you
need values in the range 0 .. 2^64-1, or int64_t/int_least64_t if you
need values in the range -2^63 .. +2^63-1.

[Bart]

So, do you write 3, 3L or 3LL if you wanted three be considered a 'long'
type in calculations?

If you need to use a format code (I don't know how much that is still
prevalent in C++), is it %d, %ld or %lld?

> Sorted.

You use a library where the author also 'sorted' by using a type 'mylong'.

Is a mylong* of your type compatible with a mylong* of theirs? (Ignoring
the name clashing, but the question would still be how your mylong1
relates to their mylong2.)

[Scott Lurndal]

Bart <b...@freeuk.com> writes:
>On 06/12/2019 16:30, bol...@nowhere.co.uk wrote:
>> On Fri, 6 Dec 2019 16:20:07 +0000
>> Bart <b...@freeuk.com> wrote:
>>> On 04/12/2019 08:40, Paavo Helde wrote:
>
>>>> This is basically so because long happened to be 32-bit in 16-bit DOS 35
>>>> years ago, and MS used it a lot instead of 16-bit int (which was indeed
>>>> unusable for many purposes). As a result, now they cannot change 'long'
>>>> to 64-bit because they have abused it so much.
>>>>
>>>
>>> At least, on Windows 'long' is consistently 32-bit.
>>>
>>> On Linux, as I understand it, 'long' is either 32 bits or 64 bits,
>>> depending on whether the OS is 32 or 64 bits.
>>>
>>> This means that if you use 'long' on Linux64, and depend on it being 64
>>> bits, the same program might not work properly on Linux32.
>>>
>>> And if a 'long' is wide enough on Linux32, then on Linux64 it will
>>> wastefully be 64 bits (ie. an array of 'long' takes twice the memory).
>>>
>>> (Suggestion: don't bother with 'long' at all; either use plain int (32
>>> bits on most relevant machines), or long long int (64 bits), which has
>>> the -LL suffix for constants that need to be considered 64 bits.)
>>
>> #include <stdint.h>
>>
>> int32_t myint;
>> int64_t mylong;
>
>So, do you write 3, 3L or 3LL if you wanted three be considered a 'long'
>type in calculations?

Yes.

[Bart]

On 05/12/2019 15:15, Vir Campestris wrote:
> On 05/12/2019 01:33, Ben Bacarisse wrote:
>> Vir Campestris <vir.cam...@invalid.invalid> writes:
>> <cut>
>>> The one that really strained C was the one where incrementing a
>>> pointer by 1 went to the next bit. Not byte or word. (TI GPU)
>>
>> What problems does C have on a bit-addressed machine?
>>
>
> Code that assumes you can copy a pointer into a number, then manipulate
> it. Lots of people do it, even though they shouldn't.
>
> sizeof is interesting when things don't have to be whole numbers of
> bytes. (you have a greyscale graphics plane with 3 bits per pixel,
> 800x600. How much RAM is that?

Actual physical memory, or address space?

On this thing it was literally 3 _bits_
> x800x600, when most machines would end up unpacking the pixels into bytes.)

I made one device (video memory) that used 1024 x 6 bits. Total physical
RAM: 768 bytes; address space: 1KB. Another that used 16K x 4 bits.
Total physical RAM: 8KB; address space: 16KB.

Unless this is a special kind of memory known to the language, it will
be working with the address space.

[Bart]

On 04/12/2019 21:46, Vir Campestris wrote:
> On 04/12/2019 09:20, T wrote:
>> 36 bit?  My brain hurts
>
> I've used systems where the native word size is 16, 24, 32, 36 and 64
> bit. Other values are available :(
>
> The one that really strained C was the one where incrementing a pointer
> by 1 went to the next bit. Not byte or word. (TI GPU)

You'd think the compiler would turn ++p into the correct step then.

p would have to be a pointer not an int containing a point. But then it
wouldn't work properly on x64 or ARM either.

> The one with 36 bits (DECSystem10) an address was the address of a word,
> and you couldn't point to a character inside the word. I didn't use C on
> it.

That machine had a hardware extension allowing you to refer to bytes (of
any width) inside a word using special instructions.

This used spare bits in the top half a word, while the bottom half was
the word address. So simply incrementing such a pointer would step to
the next word not the next byte.

A language would need to be aware of this scheme so that ++p would step
to the next byte.

[Ben Bacarisse]

Vir Campestris <vir.cam...@invalid.invalid> writes:
<cut>
>>>> Vir Campestris<vir.cam...@invalid.invalid> writes:
>>>> <cut>
>>>>> The one that really strained C was the one where incrementing a
>>>>> pointer by 1 went to the next bit. Not byte or word. (TI GPU)

<cut>

> BTW the Dec10 - the 36 bit one I used - an int was 36 bits, but a
> character string was stored as set of 5 7-bit ASCII characters plus
> one pad bit in each word... Never used C on it though.

It would be very expensive to implement C using that packed format for
character strings. Some C implementations on other word addressed
machines decided to make char one word; on others arithmetic was needed
to convert between word and "char" pointers. It's notable that,
programmer assumptions aside, word addressed machines are probably more
awkward for C the bit-addressed ones.

--
Ben.

[James Kuyper]

On 12/6/19 10:55 PM, Ben Bacarisse wrote:
> Vir Campestris <vir.cam...@invalid.invalid> writes:

...

>> BTW the Dec10 - the 36 bit one I used - an int was 36 bits, but a
>> character string was stored as set of 5 7-bit ASCII characters plus
>> one pad bit in each word... Never used C on it though.
>
> It would be very expensive to implement C using that packed format for
> character strings. Some C implementations on other word addressed
> machines decided to make char one word; on others arithmetic was needed
> to convert between word and "char" pointers. It's notable that,
> programmer assumptions aside, word addressed machines are probably more
> awkward for C the bit-addressed ones.

I can't vouch for this from personal experience, but I remember being
informed by others in this newsgroup that the byte size was configurable
on that machine. 5 7-bit bytes was just one option. 4 9-bit bytes was
another, and somewhat less expensive than using an entire word to store
a character.

[Tim Rentsch]

Vir Campestris <vir.cam...@invalid.invalid> writes:

> On 04/12/2019 09:20, T wrote:
>
>> 36 bit? My brain hurts
>
> I've used systems where the native word size is 16, 24, 32, 36 and 64

> bit. Other values are available :( [...]

>
> The one with 36 bits (DECSystem10) an address was the address of a
> word, and you couldn't point to a character inside the word.

The PDP-10 did have a format, and instructions that used that
format, to access any contiguous set of bits within a 36-bit
word. They were called, IIRC, byte pointers, and would serve
perfectly well as a representation for 'char *' and 'void *'.

[Tim Rentsch]

The PDP-10 had a special representation for pointing to, and
accessing, "bytes" within a word, and instructions for doing loads,
stores, and pointer arithmetic in terms of "bytes" rather than
words. A nice thing about the PDP-10 byte pointers is the width in
bits of a "byte" is part of the stored representation in each byte
pointer. A C implementation on a PDP-10 could choose 9-bit bytes
for 'char' without too much trouble[*]. Alternatively, for a bit of
fun, bytes could be 12 bits, with two bytes for int's, and three
bytes for long (no longer works for C11, naturally), and two 36-bit
words for long long. But 9-bit bytes would work just fine, even for
C11. (Sorry folks - no uint32_t in those implementations.)

[*] IIRC, "bytes" in the PDP-10 were treated as unsigned, so
signed types would need sign extension on loading.

[bol...@nowhere.co.uk]

On Fri, 6 Dec 2019 17:50:39 +0000

I still use printf, cout is bloody awful for simple text formatting. I've
seen multiple lines of setfill, setwidth etc loads of times, all of which could
have been done with something like a 20 char printf format.

But yes, officially you need to know the size of what you're passing to printf
(and scanf) so it outputs correctly, though given both are built into the
compiler I imagine the compiler could be a bit smart about it and promote/demote
as appropriate but I don't know how often thats done, if ever.

>> Sorted.
>
>You use a library where the author also 'sorted' by using a type 'mylong'.

stdint.h is an official standard header file and has been for decades.

[Bart]

On 07/12/2019 11:57, bol...@nowhere.co.uk wrote:
> On Fri, 6 Dec 2019 17:50:39 +0000
> Bart <b...@freeuk.com> wrote:
>> On 06/12/2019 16:30, bol...@nowhere.co.uk wrote:
>>> On Fri, 6 Dec 2019 16:20:07 +0000
>>> Bart <b...@freeuk.com> wrote:

>>>> (Suggestion: don't bother with 'long' at all; either use plain int (32
>>>> bits on most relevant machines), or long long int (64 bits), which has
>>>> the -LL suffix for constants that need to be considered 64 bits.)
>>>
>>> #include <stdint.h>
>>>
>>> int32_t myint;
>>> int64_t mylong;

>>> Sorted.
>>
>> You use a library where the author also 'sorted' by using a type 'mylong'.
>
> stdint.h is an official standard header file and has been for decades.

Sorry, I thought from the names used in your examples that you were
typedef-ing myint and mylong, rather than declaring instances with those
names.

In that case, you don't know whether your typedef-ed 'mylong' is going
to be defined on top of the same ?intN_t types as someone else's 'mylong'.

[bol...@nowhere.co.uk]

On Sat, 7 Dec 2019 12:04:15 +0000

Eh?

If you want to be sure of the size of an int or long just use the official
typedefs for 32 and 64 bit types. I don't see what the problem is.

[Bart]

Yeah, /I/ can do that. The problem is not everyone else will do so.

Is int64_t* the same as long*? Sometimes yes, sometimes no, sometimes it
depends. Is a 1234L constant equivalent to int64_t, or int32_t?

Messy, but I was originally replying to this comment:

[PH:] "As a result, now they [MS] cannot change 'long' to 64-bit because

they have abused it so much."

As I said, at least on Windows, you know it will be 32-bits.

[Öö Tiib]

That is the problem of those others who do not use official typedefs.
Why it is problem of yours?

> Is int64_t* the same as long*? Sometimes yes, sometimes no, sometimes it
> depends.

If it somehow matters use std::is_same_v<int64_t*,long*>, it is compile
time bool. But I don't use long* in my code anywhere so it does not matter.

> Is a 1234L constant equivalent to int64_t, or int32_t?

Same there. I don't use any longs in code and I don't use L suffixes to
integer literals. As result it is problem of those others who do it
wrong.

> Messy, but I was originally replying to this comment:
>
> [PH:] "As a result, now they [MS] cannot change 'long' to 64-bit because
> they have abused it so much."
>
> As I said, at least on Windows, you know it will be 32-bits.

Where Windows API has long in interface? Signed 32 bit integers seem
everywhere to be LONG or INT32 in it. So user can use conversions
to those (often nop conversions) where integrating with Windows API.
Everywhere else it does not matter.

[Vir Campestris]

On 07/12/2019 06:36, Tim Rentsch wrote:
> The PDP-10 had a special representation for pointing to, and
> accessing, "bytes" within a word, and instructions for doing loads,
> stores, and pointer arithmetic in terms of "bytes" rather than
> words.

You obviously remember it better than I do.

OTOH I was supposed to be studying Biology...

Andy