From Newsgroup: comp.arch

In article <10vpuu9$3ttut$1@dont-email.me>, tkoenig@netcologne.de (Thomas Koenig) wrote:

(which shows that big-endian Linux is still supported).

Which PowerPC Linux was that? Not many distributions have big-endian.

But if the software you are targeting is primarily written on,
and for, little-endian systems like x86

My employer found some value in building and testing on big-endian
platforms, because it made some kinds of bugs much more obvious. However,
it wasn't enough value to make it worth buying hardware for Solaris on
SPARC or AIX on POWER once there were no customers for them. If there's a big-endian PowerPC Linux with a future, that would be interesting.

John
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

John Dallman <jgd@cix.co.uk> schrieb:

In article <10vpuu9$3ttut$1@dont-email.me>, tkoenig@netcologne.de (Thomas Koenig) wrote:

(which shows that big-endian Linux is still supported).

Which PowerPC Linux was that? Not many distributions have big-endian.

Linux cfarm121 7.1.3+deb14-powerpc64 #1 SMP PREEMPT Debian 7.1.3-1 (2026-07-04) ppc64 GNU/Linux

https://portal.cfarm.net/machines/list/ has a list of machines
for the gcc compile farm.


There are also regular gcc testsuite runs on big-endian POWER, for
example at

https://gcc.gnu.org/pipermail/gcc-testresults/2026-September/885985.html

There is also a guy in Japan running big-endian Debian on POWER9,
plus big-endian FreeBSD on POWER (talk about exotic...)

But if the software you are targeting is primarily written on,
and for, little-endian systems like x86

My employer found some value in building and testing on big-endian
platforms, because it made some kinds of bugs much more obvious.

Like passing a char to an int...

If it is for debugging, then the Talos II could be an alternative.
Since it is based on POWER9, it is no longer very competetive on
performance, but for debugging, it could still be interesting.

However,
it wasn't enough value to make it worth buying hardware for Solaris on
SPARC or AIX on POWER once there were no customers for them. If there's a big-endian PowerPC Linux with a future, that would be interesting.

Not sure what the future is... hard to say who is still actually
running it.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 06/09/2026 11:20, Thomas Koenig wrote:

John Dallman <jgd@cix.co.uk> schrieb:

In article <10vpuu9$3ttut$1@dont-email.me>, tkoenig@netcologne.de (Thomas
Koenig) wrote:

But if the software you are targeting is primarily written on,
and for, little-endian systems like x86

My employer found some value in building and testing on big-endian
platforms, because it made some kinds of bugs much more obvious.

Like passing a char to an int...

Could you expand on that? I am curious about what you mean here.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

David Brown <david.brown@hesbynett.no> schrieb:

On 06/09/2026 11:20, Thomas Koenig wrote:

John Dallman <jgd@cix.co.uk> schrieb:

In article <10vpuu9$3ttut$1@dont-email.me>, tkoenig@netcologne.de (Thomas >>> Koenig) wrote:

But if the software you are targeting is primarily written on,
and for, little-endian systems like x86

My employer found some value in building and testing on big-endian
platforms, because it made some kinds of bugs much more obvious.

Like passing a char to an int...

Could you expand on that? I am curious about what you mean here.

I was being rather imprecise, thinking of Fortran more than of C.
What I meant was something like

#include <stdio.h>

void printit(void *p)
{
char *c = p;
printf ("Value is: %d\n", *c);
}

int main()
{
int i = 42;
printit (&i);
return 0;
}

which yields "Value is: 0" on a big-endian machine.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 06/09/2026 14:17, Thomas Koenig wrote:

David Brown <david.brown@hesbynett.no> schrieb:

On 06/09/2026 11:20, Thomas Koenig wrote:

John Dallman <jgd@cix.co.uk> schrieb:

In article <10vpuu9$3ttut$1@dont-email.me>, tkoenig@netcologne.de (Thomas >>>> Koenig) wrote:

But if the software you are targeting is primarily written on,
and for, little-endian systems like x86

My employer found some value in building and testing on big-endian
platforms, because it made some kinds of bugs much more obvious.

Like passing a char to an int...

Could you expand on that? I am curious about what you mean here.

I was being rather imprecise, thinking of Fortran more than of C.
What I meant was something like

#include <stdio.h>

void printit(void *p)
{
char *c = p;
printf ("Value is: %d\n", *c);
}

int main()
{
int i = 42;
printit (&i);
return 0;
}

which yields "Value is: 0" on a big-endian machine.

Okay, but that is well-defined behaviour in C (with a smattering of implementation-defined behaviour for the signedness of plain char and
the sizes involved - the machine could have the same size for "char" and "int", and thus print "42"). You are using a character pointer to
access the first byte of the representation of "i" in memory, and that
is of course the MSB in a big-endian system. It is one of relatively
few ways you can distinguish the endianness.

I know very little of Fortran - is it significantly different from C
here? (Again, this is just curiosity.)



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

David Brown <david.brown@hesbynett.no> schrieb:

On 06/09/2026 14:17, Thomas Koenig wrote:

David Brown <david.brown@hesbynett.no> schrieb:

On 06/09/2026 11:20, Thomas Koenig wrote:

John Dallman <jgd@cix.co.uk> schrieb:

In article <10vpuu9$3ttut$1@dont-email.me>, tkoenig@netcologne.de (Thomas >>>>> Koenig) wrote:

But if the software you are targeting is primarily written on,
and for, little-endian systems like x86

My employer found some value in building and testing on big-endian
platforms, because it made some kinds of bugs much more obvious.

Like passing a char to an int...

Could you expand on that? I am curious about what you mean here.

I was being rather imprecise, thinking of Fortran more than of C.
What I meant was something like

#include <stdio.h>

void printit(void *p)
{
char *c = p;
printf ("Value is: %d\n", *c);
}

int main()
{
int i = 42;
printit (&i);
return 0;
}

which yields "Value is: 0" on a big-endian machine.

Okay, but that is well-defined behaviour in C (with a smattering of implementation-defined behaviour for the signedness of plain char and
the sizes involved - the machine could have the same size for "char" and "int", and thus print "42"). You are using a character pointer to
access the first byte of the representation of "i" in memory, and that
is of course the MSB in a big-endian system. It is one of relatively
few ways you can distinguish the endianness.

Jep.

However, if code depends on a particular ordering, for example if
this needs to print 42, the code is buggy on big-endian systems.
And if you make the mismatch int*/long* instead, you will get
undefined behavior that is also difficult to catch, if you lie
to your compiler.

Another thing that is also access to subwords via unions.

I know very little of Fortran - is it significantly different from C
here? (Again, this is just curiosity.)

Fortran argument passing is not specified by the standard. In
FORTRAN 77 days, it was usually implemented via pointers to each
argument. If you had

INTEGER*4 I
I = 42
CALL FOO(I)

...

SUBROUTINE FOO(I)
INTEGER*2 I
PRINT *,I

you would get the same effect, but the program would be illegal
from the start.

This is the kind of error that little-endian will hide, and
big-endian will not.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 06/09/2026 16:41, Thomas Koenig wrote:

David Brown <david.brown@hesbynett.no> schrieb:

On 06/09/2026 14:17, Thomas Koenig wrote:

David Brown <david.brown@hesbynett.no> schrieb:

On 06/09/2026 11:20, Thomas Koenig wrote:

John Dallman <jgd@cix.co.uk> schrieb:

In article <10vpuu9$3ttut$1@dont-email.me>, tkoenig@netcologne.de (Thomas
Koenig) wrote:

But if the software you are targeting is primarily written on,
and for, little-endian systems like x86

My employer found some value in building and testing on big-endian >>>>>> platforms, because it made some kinds of bugs much more obvious.

Like passing a char to an int...

Could you expand on that? I am curious about what you mean here.

I was being rather imprecise, thinking of Fortran more than of C.
What I meant was something like

#include <stdio.h>

void printit(void *p)
{
char *c = p;
printf ("Value is: %d\n", *c);
}

int main()
{
int i = 42;
printit (&i);
return 0;
}

which yields "Value is: 0" on a big-endian machine.

Okay, but that is well-defined behaviour in C (with a smattering of
implementation-defined behaviour for the signedness of plain char and
the sizes involved - the machine could have the same size for "char" and
"int", and thus print "42"). You are using a character pointer to
access the first byte of the representation of "i" in memory, and that
is of course the MSB in a big-endian system. It is one of relatively
few ways you can distinguish the endianness.

Jep.

However, if code depends on a particular ordering, for example if
this needs to print 42, the code is buggy on big-endian systems.

"Buggy" might not be an appropriate term, depending on the requirements
and specifications for the code - "outside of specifications" might be
better. Certainly code that depends on a particular assumption like endianness will have limited portability. And if code relies on such assumptions, then it should ideally force a compile-time error if the assumptions are not valid:

#if __STDC_ENDIAN_NATIVE__ !=__STDC_ENDIAN_LITTLE__
#error This code requires a litte-endian target
#endif

Unfortunately, that was only standardised in C23. Fortunately, most
compilers have had implementation-specific alternatives for decades, and
you can put together (or find on the internet, or generate with ai) pre-processor directives to check for common compilers and their
endianness symbols.

And if you make the mismatch int*/long* instead, you will get
undefined behavior that is also difficult to catch, if you lie
to your compiler.

Lying to your compiler is rarely a good idea! But this one is easy -
"int" and "long int" are not compatible, so it is /never/ appropriate to
mix them - regardless of size.

Another thing that is also access to subwords via unions.

That will also be endian-dependent, because it is reliant on
re-interpretation of the underlying representation. (It can also be a
risk in that while type-punning via unions is defined behaviour in C, it
is UB in C++.)

I know very little of Fortran - is it significantly different from C
here? (Again, this is just curiosity.)

Fortran argument passing is not specified by the standard. In
FORTRAN 77 days, it was usually implemented via pointers to each
argument. If you had

INTEGER*4 I
I = 42
CALL FOO(I)

...

SUBROUTINE FOO(I)
INTEGER*2 I
PRINT *,I

you would get the same effect, but the program would be illegal
from the start.

This is the kind of error that little-endian will hide, and
big-endian will not.

Okay, thanks.

I guess in early C code people where often a bit loser about
declarations of functions and making sure those matched the function definition - implicit function declaration could easily lead to mixups
and UB like that in older C (and badly written newer C too, with a lax compiler).


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

In article <117jb85$27q1b$1@dont-email.me>, tkoenig@netcologne.de (Thomas Koenig) wrote:

Not sure what the future is... hard to say who is still actually
running it.

Doesn't seem like many people. Thanks, noted, but I won't do anything
more.

John
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


David Brown <david.brown@hesbynett.no> posted:
---------------

And if you make the mismatch int*/long* instead, you will get
undefined behavior that is also difficult to catch, if you lie
to your compiler.

What about ILP32 programming environments ??

Lying to your compiler is rarely a good idea! But this one is easy -
"int" and "long int" are not compatible, so it is /never/ appropriate to
mix them - regardless of size.

What about ILP32 programming environments ??

Another thing that is also access to subwords via unions.

That will also be endian-dependent, because it is reliant on re-interpretation of the underlying representation. (It can also be a
risk in that while type-punning via unions is defined behaviour in C, it
is UB in C++.)

When done it must be done where the struct declaration has #ifdef ENDIAN
so the struct is properly defined in both endian-nesses.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sun, 6 Sep 2026 14:41:22 -0000 (UTC), Thomas Koenig wrote:

Fortran argument passing is not specified by the standard. In
FORTRAN 77 days, it was usually implemented via pointers to each
argument.

This applied even to arguments which were literals or expressions.

For expressions, a temporary location would be assigned the value and
passed by address.

If the expression was a literal, and the same literal were used in
more than one place, some early compilers might rCLoptimizerCY the
allocation of only a single copy of that literal.

So if a called function/subroutine changed the value of that argument,
all references to that literal would suddenly pick up the new value!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 07/09/2026 01:51, MitchAlsup wrote:

David Brown <david.brown@hesbynett.no> posted:
---------------

And if you make the mismatch int*/long* instead, you will get
undefined behavior that is also difficult to catch, if you lie
to your compiler.

What about ILP32 programming environments ??

In C, this is UB :

int foo(long int x) {
static_assert(sizeof(int) == sizeof(long int));

long int * pl = &x;
int * pi = (int *) pl;
return *pi;
}

The fact that you need the cast here - you can't assign a "pointer to
long int" directly to a "pointer to int" variable without a cast or
converting via a "void *" intermediary - is a strong indication that you
are trying to do something bad.

Lying to your compiler is rarely a good idea! But this one is easy -
"int" and "long int" are not compatible, so it is /never/ appropriate to
mix them - regardless of size.

What about ILP32 programming environments ??

They are not compatible in any programming environments.

Code that lies to the compiler - saying that you have a pointer to an
"int", when in fact the object pointed to is a "long int" - might work.
But it is UB, and compilers can (and do) optimise on the assumption that
you are a responsible programmer who knows the language and follows the
rules.

int bar(int * pi, long int * pl) {
static_assert(sizeof(int) == sizeof(long int));

*pi = 1;
*pl = 2;
return *pi;
}

Godbolt 32-bit ARM gcc 16, -O2 -Wall -Wextra -Wpedantic -march=armv8-a :

bar:
mov r2, r0
mov r3, #2
mov r0, #1
str r0, [r2]
str r3, [r1]
bx lr

The generated code does not re-read from *pi, but returns 1 directly
because it knows "pl" and "pi" cannot alias unless the programmer has
been lying to the compiler.

Another thing that is also access to subwords via unions.

That will also be endian-dependent, because it is reliant on
re-interpretation of the underlying representation. (It can also be a
risk in that while type-punning via unions is defined behaviour in C, it
is UB in C++.)

When done it must be done where the struct declaration has #ifdef ENDIAN
so the struct is properly defined in both endian-nesses.

No, there is no "must" here unless the code actually has to be usable on
big and little endian systems. The solid majority of code does not need
to be particularly portable.

If you are writing relatively portable code on your x86 PC (or perhaps
ARM system) and you have something that is endian-dependent, then it is
good practice to force a compile-time error if it is compiled for a
big-endian target. But it is /not/ a good idea to define a big-endian variation of your structs or functions, because you will not be testing
them. It is better to leave a compile-time error than to put in code
that you have not, and cannot, test. (You could, perhaps, add the code
and have the compile-time error message say that the code is there but completely untested.)


(Note that this is unrelated to the point that type-punning unions are supported in C but not in C++.)


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

According to Thomas Koenig <tkoenig@netcologne.de>: >https://portal.cfarm.net/machines/list/ has a list of machines

for the gcc compile farm.

I see a bunch of s390 machines on that last. IBM actively supports
linux on zSeries and as long as they do that, there's going to be
some bigendian linux systems.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

John Levine <johnl@taugh.com> schrieb:

According to Thomas Koenig <tkoenig@netcologne.de>:

https://portal.cfarm.net/machines/list/ has a list of machines
for the gcc compile farm.

I see a bunch of s390 machines on that last. IBM actively supports
linux on zSeries and as long as they do that, there's going to be
some bigendian linux systems.

Another interesting tidbit in that respect: gcc 17 will drop
support for 31-bit s390.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


David Brown <david.brown@hesbynett.no> posted:

On 07/09/2026 01:51, MitchAlsup wrote:

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

Code that lies to the compiler - saying that you have a pointer to an
"int", when in fact the object pointed to is a "long int" - might work.
But it is UB, and compilers can (and do) optimise on the assumption that
you are a responsible programmer who knows the language and follows the rules.

int bar(int * pi, long int * pl) {
static_assert(sizeof(int) == sizeof(long int));

*pi = 1;
*pl = 2;
return *pi;
}

Godbolt 32-bit ARM gcc 16, -O2 -Wall -Wextra -Wpedantic -march=armv8-a :

bar:
mov r2, r0
mov r3, #2
mov r0, #1
str r0, [r2]
str r3, [r1]
bx lr

Seems unnecessarily long::

bar:
STW #1,[R1]
STW #2,[R2]
MOV R1,#1
RET
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 07/09/2026 20:22, MitchAlsup wrote:

David Brown <david.brown@hesbynett.no> posted:

On 07/09/2026 01:51, MitchAlsup wrote:

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

Code that lies to the compiler - saying that you have a pointer to an
"int", when in fact the object pointed to is a "long int" - might work.
But it is UB, and compilers can (and do) optimise on the assumption that
you are a responsible programmer who knows the language and follows the
rules.

int bar(int * pi, long int * pl) {
static_assert(sizeof(int) == sizeof(long int));

*pi = 1;
*pl = 2;
return *pi;
}

Godbolt 32-bit ARM gcc 16, -O2 -Wall -Wextra -Wpedantic -march=armv8-a :

bar:
mov r2, r0
mov r3, #2
mov r0, #1
str r0, [r2]
str r3, [r1]
bx lr

Seems unnecessarily long::

bar:
STW #1,[R1]
STW #2,[R2]
MOV R1,#1
RET

ARM does not have instructions to store immediates like that. It's a load/store architecture - you need to put the immediate values into
registers, then store them.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


David Brown <david.brown@hesbynett.no> posted:

On 07/09/2026 20:22, MitchAlsup wrote:

David Brown <david.brown@hesbynett.no> posted:

On 07/09/2026 01:51, MitchAlsup wrote:

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

Code that lies to the compiler - saying that you have a pointer to an
"int", when in fact the object pointed to is a "long int" - might work.
But it is UB, and compilers can (and do) optimise on the assumption that >> you are a responsible programmer who knows the language and follows the
rules.

int bar(int * pi, long int * pl) {
static_assert(sizeof(int) == sizeof(long int));

*pi = 1;
*pl = 2;
return *pi;
}

Godbolt 32-bit ARM gcc 16, -O2 -Wall -Wextra -Wpedantic -march=armv8-a : >>
bar:
mov r2, r0
mov r3, #2
mov r0, #1
str r0, [r2]
str r3, [r1]
bx lr

Seems unnecessarily long::

bar:
STW #1,[R1]
STW #2,[R2]
MOV R1,#1
RET

ARM does not have instructions to store immediates like that. It's a load/store architecture - you need to put the immediate values into registers, then store them.

My 66000 is a LD store architecture, too, but there are encodings that
allow the Rd specifier to be used as a small immediate.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 08/09/2026 00:00, MitchAlsup wrote:

David Brown <david.brown@hesbynett.no> posted:

On 07/09/2026 20:22, MitchAlsup wrote:

David Brown <david.brown@hesbynett.no> posted:

On 07/09/2026 01:51, MitchAlsup wrote:

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

Code that lies to the compiler - saying that you have a pointer to an
"int", when in fact the object pointed to is a "long int" - might work. >>>> But it is UB, and compilers can (and do) optimise on the assumption that >>>> you are a responsible programmer who knows the language and follows the >>>> rules.

int bar(int * pi, long int * pl) {
static_assert(sizeof(int) == sizeof(long int));

*pi = 1;
*pl = 2;
return *pi;
}

Godbolt 32-bit ARM gcc 16, -O2 -Wall -Wextra -Wpedantic -march=armv8-a : >>>>
bar:
mov r2, r0
mov r3, #2
mov r0, #1
str r0, [r2]
str r3, [r1]
bx lr

Seems unnecessarily long::

bar:
STW #1,[R1]
STW #2,[R2]
MOV R1,#1
RET

ARM does not have instructions to store immediates like that. It's a
load/store architecture - you need to put the immediate values into
registers, then store them.

My 66000 is a LD store architecture, too, but there are encodings that
allow the Rd specifier to be used as a small immediate.

That sounds like a nice feature to have (I would not expect it to be
very often used for a store operation, but it would certainly be useful
for things like addition or subtraction instructions). But ARM does not
have it, so the generated code is as good as it gets for that target.

The point, however, was that the generated code is correct because "int"
and "long int" are not compatible types in C, even if they are the same
size - the compiler knows the "int *" and "long int *" pointers do not
alias, and can thus avoid reading back from "*pi".

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

According to Thomas Koenig <tkoenig@netcologne.de>:

John Levine <johnl@taugh.com> schrieb:

According to Thomas Koenig <tkoenig@netcologne.de>: >>>https://portal.cfarm.net/machines/list/ has a list of machines

for the gcc compile farm.

I see a bunch of s390 machines on that last. IBM actively supports
linux on zSeries and as long as they do that, there's going to be
some bigendian linux systems.

Another interesting tidbit in that respect: gcc 17 will drop
support for 31-bit s390.

Not surprising, since I expect everything now runs in 64 bit mode on linux for z.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

MitchAlsup <user5857@newsgrouper.org.invalid> writes:

David Brown <david.brown@hesbynett.no> posted:
---------------

And if you make the mismatch int*/long* instead, you will get
undefined behavior that is also difficult to catch, if you lie
to your compiler.

What about ILP32 programming environments ??

Long obsolete and pretty much useless in these modern times.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 08/09/2026 18:02, Scott Lurndal wrote:

MitchAlsup <user5857@newsgrouper.org.invalid> writes:

David Brown <david.brown@hesbynett.no> posted:
---------------

And if you make the mismatch int*/long* instead, you will get
undefined behavior that is also difficult to catch, if you lie
to your compiler.

What about ILP32 programming environments ??

Long obsolete and pretty much useless in these modern times.

Or as other people know them, totally dominant in terms of the number of systems made and used. You might not find many 32-bit PC's in common
use, but 32-bit is the current norm in the microcontroller world (having
taken over from 8-bit).

Regardless of size, "int" and "long" are incompatible in C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Scott Lurndal <scott@slp53.sl.home> schrieb:

MitchAlsup <user5857@newsgrouper.org.invalid> writes:

David Brown <david.brown@hesbynett.no> posted:
---------------

And if you make the mismatch int*/long* instead, you will get
undefined behavior that is also difficult to catch, if you lie
to your compiler.

What about ILP32 programming environments ??

Long obsolete and pretty much useless in these modern times.

On embedded systems, for example 32-bit ARM?
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Thomas Koenig <tkoenig@netcologne.de> writes:

Scott Lurndal <scott@slp53.sl.home> schrieb:

MitchAlsup <user5857@newsgrouper.org.invalid> writes:

David Brown <david.brown@hesbynett.no> posted:
---------------

And if you make the mismatch int*/long* instead, you will get
undefined behavior that is also difficult to catch, if you lie
to your compiler.

What about ILP32 programming environments ??

Long obsolete and pretty much useless in these modern times.

On embedded systems, for example 32-bit ARM?

Point granted.
--- Synchronet 3.22a-Linux NewsLink 1.2