New VSI post on Youtube

Post by Arne VajhÃ¸j
http://youtu.be/BmLEI5O1JSw
I have not seen & heard it all yet.
Somewhere in the middle they summarize the status of the x86-64 port
as: 8920 tests succeed + 271 tests fail + 608 test not run yet.

Did this get lost in all the spam filters?

I guess a YouTube link does look like spam, but ...

Arne

Simon Clubley

2024-08-14 17:48:40 UTC

Did this get lost in all the spam filters?
I guess a YouTube link does look like spam, but ...

I did see this the first time around, but had nothing to say at the time.

However, since you ask, I prefer a writeup rather than a 40 minute video
for this kind of update, but based on the numbers above, they are making
good progress but are not there yet.

Based on the above, I would guess/hope early next year for them to be ready,
which would put them a year behind schedule. It would be interesting to
know the reasons for the failures however and what is different about the
x86-64 environment that resulted in test differences that ended up being
classified as failures.

In total, there's about 10% of the tests which have not been done or have
failed, but as we all know the first 90% of a project takes 90% of the
time and the last 10% takes the other 90% of the time. :-)

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Robert A. Brooks

2024-08-14 18:07:02 UTC

Post by Simon Clubley
It would be interesting to
know the reasons for the failures however and what is different about the
x86-64 environment that resulted in test differences that ended up being
classified as failures.

I don't know specifically, but with my very limited experience with C++, the
X86_64 compiler is much less accepting of the syntax that the Alpha and IA64 compilers
accepted.

Some of the changes are pretty mechanical (casting or simple refactoring); some are not.

Don't ask me to describe the "some are not" part, because I'm getting help to deal wit
those.

For the tests failing, it may be due to code not yet working, but I don't have
any inside knowledge there.

--
-- Rob

Arne Vajhøj

2024-08-14 18:33:27 UTC

Post by Robert A. Brooks

I don't know specifically, but with my very limited experience with C++, the
X86_64 compiler is much less accepting of the syntax that the Alpha and IA64 compilers
accepted.
Some of the changes are pretty mechanical (casting or simple
refactoring); some are not.
Don't ask me to describe the "some are not" part, because I'm getting help to deal wit
those.

Being more strict is just one thing.

I also believe it is missing some of the VMS specific extensions.

And it has different size of long and pointers. Causing problems
for two cases:
* code that make implicit assumptions that those are 32 bit
* mixing C and C++

Arne

Robert A. Brooks

2024-08-14 18:45:17 UTC

Post by Robert A. Brooks
Some of the changes are pretty mechanical (casting or simple refactoring); some are not.
Don't ask me to describe the "some are not" part, because I'm getting help to deal wit
those.

Being more strict is just one thing.
I also believe it is missing some of the VMS specific extensions.
And it has different size of long and pointers. Causing problems
* code that make implicit assumptions that those are 32 bit

/POINTER_SIZE = 32 is your friend. In my case, all the pointers
were 32 bits long, so that was an easy thing to add to the build.

This is for the OMNI and OSAP products for industrial control.

--
-- Rob

Arne Vajhøj

2024-08-14 18:57:02 UTC

Post by Arne VajhÃ¸j
And it has different size of long and pointers. Causing problems
* code that make implicit assumptions that those are 32 bit

/POINTER_SIZE = 32 is your friend. In my case, all the pointers
were 32 bits long, so that was an easy thing to add to the build.

compile/POINTER_SIZE=32, LINK/SEG=CODE=P0 etc. can all help get stuff
working.

But it is not the right long term solution.

Arne

Robert A. Brooks

2024-08-14 19:49:28 UTC

Post by Arne VajhÃ¸j
compile/POINTER_SIZE=32, LINK/SEG=CODE=P0 etc. can all help get stuff
working.
But it is not the right long term solution.

For C++, the default pointer size should have remained 32.
It was a mistake to change the default from what it was on Alpha and IA64.

There is a lot of VMS-developed C++ code that expects a pointer size of 32,
so in the case I cited, that compilation qualifer will remain forever, because
the code will not change.

--
-- Rob

Arne Vajhøj

2024-08-14 20:21:39 UTC

Post by Robert A. Brooks

Post by Arne VajhÃ¸j
compile/POINTER_SIZE=32, LINK/SEG=CODE=P0 etc. can all help get stuff
working.
But it is not the right long term solution.

For C++, the default pointer size should have remained 32.
It was a mistake to change the default from what it was on Alpha and IA64.

Given how much C vs C++ issues we have seen, then I think there
is a case for that.

But as I understand it the plan was to keep C++ very close to out of
the box clang.

In hindsight ...

Post by Robert A. Brooks
There is a lot of VMS-developed C++ code that expects a pointer size of 32,

I believe that.

Post by Robert A. Brooks
so in the case I cited, that compilation qualifer will remain forever, because
the code will not change.

Unless the system in question has EOL and replacement planned, then
I doubt that.

Everything eventually change or die.

Arne

Stephen Hoffman

2024-08-15 00:35:07 UTC

Post by Robert A. Brooks

compile/POINTER_SIZE=32, LINK/SEG=CODE=P0 etc. can all help get stuff working.
But it is not the right long term solution.

For C++, the default pointer size should have remained 32.
It was a mistake to change the default from what it was on Alpha and IA64.

It was a mistake to use 32 and not 64 on Alpha and Itanium, but that
pain will continue for the foreseeable future.

--
Pure Personal Opinion | HoffmanLabs LLC

Craig A. Berry

2024-08-15 01:26:00 UTC

Post by Stephen Hoffman

compile/POINTER_SIZE=32, LINK/SEG=CODE=P0 etc. can all help get stuff working.
But it is not the right long term solution.

For C++, the default pointer size should have remained 32.
It was a mistake to change the default from what it was on Alpha and IA64.

It was a mistake to use 32 and not 64 on Alpha and Itanium, but that
pain will continue for the foreseeable future.

It is past time to change the default. I suspect a lot of the
difficulties in porting are not just from pointer sizes but also integer
sizes. Specifying "long" because the docs for an API say to use a
longword is a 40-year-old habit that will be hard to break, and not all
of the APIs have 64-bit equivalents. A lot of things probably assume
"long" is the same size as "int" even though that is now no longer the
case. As far as I know there is no compiler switch to say
/DATA_MODEL=ILP32 to override the new default of LP64.

Stephen Hoffman

2024-08-16 16:11:16 UTC

Post by Craig A. Berry

Post by Stephen Hoffman

compile/POINTER_SIZE=32, LINK/SEG=CODE=P0 etc. can all help get stuff working.
But it is not the right long term solution.

For C++, the default pointer size should have remained 32.
It was a mistake to change the default from what it was on Alpha and IA64.

It was a mistake to use 32 and not 64 on Alpha and Itanium, but that
pain will continue for the foreseeable future.

It is past time to change the default. I suspect a lot of the
difficulties in porting are not just from pointer sizes but also
integer sizes. Specifying "long" because the docs for an API say to
use a longword is a 40-year-old habit that will be hard to break, and
not all of the APIs have 64-bit equivalents. A lot of things probably
assume "long" is the same size as "int" even though that is now no
longer the case. As far as I know there is no compiler switch to say
/DATA_MODEL=ILP32 to override the new default of LP64.

In the approaches available to apps likely to be ported, cranking up
the compiler diagnostics settings can find a whole lot of latent bad.
This even if there isn't an app port in the immediate future.

Expect that anybody providing maintenance or porting estimates will
likely increase those estimates for each instance of /VAXC located, for
instance.

The 32-/64-bit addressing design was the right decision at the time.

That the design worked as well as it's done, and allowed code
coexistence was and is valuable.

But we're most of 30 years past Eagle/Theta/V7.0.

Different times. Different tradeoffs. Different hardware. Different
expectations.

Developers have been adding to the complexity here with new work, too.
Which isn't a good place.

If the existing API morass ever gets resolved, flat 64-bit would be preferred.

Because the whole what-does-it-return and which-call-can-I-use and the
size_t/ptrdiff_t mess we ended up with from Eagle/Theta/V7.0 is, well,
a mess.

Yes, that means dragging some apps forward. And dragging systen APIs forward.

It also means an opportunity to age out and deprecate the most
problematic of the old APIs.

And it means leaving the old stuff building and running in 32-bit and
32-/64-bit legacy-compatibility mode and for the foreseeable future.

But any replacement really needs to be further forward than flat 64-bit
using previous-millennium API designs and coding practices.

Which gets into discussions of compiler and API overhauls and other
topics for new 64-bit code.

As for itemlists and descriptors. Good ideas ~40 years ago. Now, not so much.

To be absolutely clear, the existing 32-/64-bit morass would have to
continue in parallel with the 64-bit environment for a decade or so.

All of which have been discussed before.

VSI have far larger projects. Which means this "pain will continue for
the foreseeable future".

And some perspective: we're a decade farther from Eagle/Theta/V7.0 now
than Eagle/Theta/V7.0 was from VAX/VMS V1.0.

--
Pure Personal Opinion | HoffmanLabs LLC

Lawrence D'Oliveiro

2024-08-17 01:06:51 UTC

Post by Stephen Hoffman
Yes, that means dragging some apps forward. And dragging systen APIs forward.

Reinventing POSIX?

Craig A. Berry

2024-08-17 01:29:40 UTC

Post by Stephen Hoffman
Yes, that means dragging some apps forward. And dragging systen APIs forward.

Reinventing POSIX?

POSIX is just an API. If you have to worry about whether it's a
"system" API or not, then you're in an environment that doesn't conform
to the POSIX standard.

And on VMS dragging system APIs forward just means that calls like
SYS$FILESCAN have 64-bit as well as 32-bit versions, as many other
system calls already do.

Lawrence D'Oliveiro

2024-08-17 02:44:32 UTC

Post by Craig A. Berry

Post by Stephen Hoffman
Yes, that means dragging some apps forward. And dragging systen APIs forward.

Reinventing POSIX?

POSIX is just an API.

It was an API that was careful to define higher-level types like “time_t”
and “uintptr_t” and “size_t”, precisely because the *nix systems were at
the forefront of the 64-bit transition and they had to be prepared.

Arne Vajhøj

2024-08-18 00:12:09 UTC

Post by Craig A. Berry

Post by Stephen Hoffman
Yes, that means dragging some apps forward. And dragging systen APIs forward.

Reinventing POSIX?

POSIX is just an API.

Those implementation specific types was sort of best try back
in the 90's.

The approach has been mostly abandoned in newer languages. Today
standard defined types are usually preferred. And does an API need
a new type, then it means a new function/method/property.

Too many problems with those implementation specific types. They
often work great for small/medium size but run into problems with
big/huge stuff. The combination of:
- a need to convert between those implementation specific types
and something of well defined type (persistence, network, mix
other languages or something else)
- the fact that C typedefs are not real types but just type aliases
can end up in serious headache.

Arne

Lawrence D'Oliveiro

2024-08-18 00:34:29 UTC

[POSIX] was an API that was careful to define higher-level types like
“time_t” and “uintptr_t” and “size_t”, precisely because the *nix
systems were at the forefront of the 64-bit transition and they had to
be prepared.

Those implementation specific types was sort of best try back in the
90's.
The approach has been mostly abandoned in newer languages.

We still use them. POSIX is still the dominant OS paradigm, the basis for
essentially all open-source software. Proprietary platforms like Windows
and VMS are measured by how POSIX-conformant they are. Which you can see
by the complexity of the special cases in the build scripts in that open-
source software, when trying to bring it up on those proprietary
platforms.

Actually, it’s more proper to say “Linux” rather than “POSIX”. POSIX
itself has become just a small part of what’s needed.

Today standard defined types are usually preferred.

We still have both 32-bit and 64-bit platforms. Such generic types ease
the job of porting software between both.

John Dallman

2024-08-16 20:38:00 UTC

Post by Robert A. Brooks
There is a lot of VMS-developed C++ code that expects a pointer
size of 32, so in the case I cited, that compilation qualifer
will remain forever, because the code will not change.

Presumably, most of the open source ported to VMS uses 32-bit pointers?

John

Arne Vajhøj

2024-08-16 21:17:09 UTC

Presumably, most of the open source ported to VMS uses 32-bit pointers?

My guess would be that most C++ open source comes from the Linux
world and is mostly tested with 64 bit pointers.

Arne

Lawrence D'Oliveiro

2024-08-17 01:06:20 UTC

My guess would be that most C++ open source comes from the Linux world
and is mostly tested with 64 bit pointers.

A lot of open source is still compatible with both 32-bit and 64-bit
platforms. Debian, for example, is still available in 32-bit form, and has
been going through a conversion to 64-bit time_t to avoid the upcoming
year-2038 problem.

Craig A. Berry

2024-08-17 01:22:08 UTC

Presumably, most of the open source ported to VMS uses 32-bit pointers?

Yes, but very little of it is written in C++. Mark Berryman has been
wrestling with mariadb and xpdf as reported on the VSI forum, but most
of what has been ported before is just C, not C++.

I suspect most of the C++ on VMS has been customer code.

Simon Clubley

2024-08-19 12:38:58 UTC

Presumably, most of the open source ported to VMS uses 32-bit pointers?

One of the nice things about higher-level languages such as C (when
compared to Macro-32/BLISS and their associated OS APIs) is that the
pointer types are abstracted so the programmer doesn't need to worry
about pointer size differences in many cases unless they start using
VMS-specific APIs.

Of course, that all changes if you are porting crappy software that
tries to stuff addresses into integers or if you are doing device
driver/hardware work where things like bounce buffers may come into play.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Arne Vajhøj

2024-08-19 13:55:05 UTC

Presumably, most of the open source ported to VMS uses 32-bit pointers?

One of the nice things about higher-level languages such as C (when
compared to Macro-32/BLISS and their associated OS APIs) is that the
pointer types are abstracted so the programmer doesn't need to worry
about pointer size differences in many cases unless they start using
VMS-specific APIs.
Of course, that all changes if you are porting crappy software that
tries to stuff addresses into integers or if you are doing device
driver/hardware work where things like bounce buffers may come into play.

Or if the application is passing pointers between code compiled
with different languages/compilers/compiler settings.

Arne

Simon Clubley

2024-08-20 12:04:13 UTC

Post by Simon Clubley
One of the nice things about higher-level languages such as C (when
compared to Macro-32/BLISS and their associated OS APIs) is that the
pointer types are abstracted so the programmer doesn't need to worry
about pointer size differences in many cases unless they start using
VMS-specific APIs.
Of course, that all changes if you are porting crappy software that
tries to stuff addresses into integers or if you are doing device
driver/hardware work where things like bounce buffers may come into play.

Or if the application is passing pointers between code compiled
with different languages/compilers/compiler settings.

Of course, that is what ABIs are _supposed_ to be for...

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Arne Vajhøj

2024-08-20 13:19:39 UTC

Or if the application is passing pointers between code compiled
with different languages/compilers/compiler settings.

Of course, that is what ABIs are _supposed_ to be for...

Yes.

But that is the point.

The ABI is right by definition. The compilers pointer size is
just usually right.

Arne

Arne Vajhøj

2024-08-14 18:48:04 UTC

Post by Arne VajhÃ¸j
And it has different size of long and pointers. Causing problems
* code that make implicit assumptions that those are 32 bit
* mixing C and C++

I am getting more and more convinced that C and C++
code should completely switch to the explicit length
model.

So:

#include <stdint.h>

or:

#include <cstdint>

and use:

int8_t
int16_t
int32_t
int64_t
uint8_t
uint16_t
uint32_t
uint64_t

and consider putting:

#define int ">>>> DO NOT USE INT <<<<"
#define short ">>>> DO NOT USE SHORT <<<<"
#define long ">>>> DO NOT USE LONG <<<<"

in as well to enforce.

Where did I put that asbestos suit to protect me
from the C/C++ crowd?

:-)

Arne

Stephen Hoffman

2024-08-15 00:34:01 UTC

Post by Arne VajhÃ¸j
And it has different size of long and pointers. Causing problems
* code that make implicit assumptions that those are 32 bit
* mixing C and C++

I am getting more and more convinced that C and C++ code should
completely switch to the explicit length model.
...
Where did I put that asbestos suit to protect me from the C/C++ crowd?
:-)
Arne

I'd have no issues with that.

Don't forget [u]int_{fast,least}{n}_t available in C99 and later, too.

That, and add deprecation warnings for the problem calls.

One bunch has the deprecation warnings enabled by default, with
_CRT_SECURE_NO_WARNINGS to disable those checks.

Related (and eventually probably more accessible on OpenVMS x86-64) is
clang-tidy:
https://clang.llvm.org/extra/clang-tidy/checks/bugprone/unsafe-functions.html

Semi-related to interoperating with C:
https://ziglang.org/learn/why_zig_rust_d_cpp/

Semi-related to Rdb: What is "large" to SQLite is quite possibly very
much larger than OpenVMS and its apps.

But given forty years of existing code in Rdb (and in OpenVMS),
wholesale language migrations just aren't happening ever, and any
incremental migrations, and refactoring and overhauls, are going to
happen over decades at the fastest.

--
Pure Personal Opinion | HoffmanLabs LLC

Simon Clubley

2024-08-15 12:34:22 UTC

Post by Arne VajhÃ¸j
And it has different size of long and pointers. Causing problems
* code that make implicit assumptions that those are 32 bit
* mixing C and C++

I am getting more and more convinced that C and C++
code should completely switch to the explicit length
model.
#include <stdint.h>
#include <cstdint>
int8_t
int16_t
int32_t
int64_t
uint8_t
uint16_t
uint32_t
uint64_t
#define int ">>>> DO NOT USE INT <<<<"
#define short ">>>> DO NOT USE SHORT <<<<"
#define long ">>>> DO NOT USE LONG <<<<"
in as well to enforce.
Where did I put that asbestos suit to protect me
from the C/C++ crowd?

That works great until you need to interface to the OS unfortunately.

BTW, I've been writing my own code with explicit sizing for many years.

To extend this, I also know the difference between signed and unsigned
variables and I have a default-unsigned approach unless I absolutely
_need_ a signed variable.

Unfortunately, a lot of the material out there doesn't seem to understand
that designing a program is about modelling a real-world problem and that
it isn't OK to just use a signed integer to store an unsigned value.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Arne Vajhøj

2024-08-15 13:59:41 UTC

Post by Arne VajhÃ¸j
And it has different size of long and pointers. Causing problems
* code that make implicit assumptions that those are 32 bit
* mixing C and C++

I am getting more and more convinced that C and C++
code should completely switch to the explicit length
model.

That works great until you need to interface to the OS unfortunately.

Encapsulate and handle the conversion between stdint API and
various CRTL/OS API's.

Do test builds on all sorts of platforms with high warning level to
see if someone went unnoticed.

Arne

Arne Vajhøj

2024-08-15 14:00:26 UTC

Post by Arne VajhÃ¸j
And it has different size of long and pointers. Causing problems
* code that make implicit assumptions that those are 32 bit
* mixing C and C++

I am getting more and more convinced that C and C++
code should completely switch to the explicit length
model.

That works great until you need to interface to the OS unfortunately.

Encapsulate and handle the conversion between stdint API and
various CRTL/OS API's.

Do test builds on all sorts of platforms with high warning level to
see if someone went unnoticed.

Arne

chrisq

2024-08-19 18:56:53 UTC

Post by Arne VajhÃ¸j
And it has different size of long and pointers. Causing problems
* code that make implicit assumptions that those are 32 bit
* mixing C and C++

That works great until you need to interface to the OS unfortunately.
BTW, I've been writing my own code with explicit sizing for many years.
To extend this, I also know the difference between signed and unsigned
variables and I have a default-unsigned approach unless I absolutely
_need_ a signed variable.
Unfortunately, a lot of the material out there doesn't seem to understand
that designing a program is about modelling a real-world problem and that
it isn't OK to just use a signed integer to store an unsigned value.
Simon.

Absolutely, must have come from an assembler background, where the use
of signed branches and arithmetic, can get you into serious trouble.
The standard C library, of course, tends to use signed variables for
everything, a gross error that has never been fixed...

Chris

Arne Vajhøj

2024-08-19 19:07:36 UTC

Post by Simon Clubley
To extend this, I also know the difference between signed and unsigned
variables and I have a default-unsigned approach unless I absolutely
_need_ a signed variable.
Unfortunately, a lot of the material out there doesn't seem to understand
that designing a program is about modelling a real-world problem and that
it isn't OK to just use a signed integer to store an unsigned value.

At least the C people can define an unsigned variable.

Java does not have unsigned data types at all. OK - higher level
language and all that. But still a PITA.

Arne

Lawrence D'Oliveiro

2024-08-19 23:08:31 UTC

Post by Arne VajhÃ¸j
At least the C people can define an unsigned variable.
Java does not have unsigned data types at all. OK - higher level
language and all that. But still a PITA.

Beat me to it. Java’s lack of unsigned integer types is indeed a downright
pain. Along with its omission of typedefs. I think they were trying to
come up with a simpler language than C++, but that was a) (at least a
partial) failure, and b) at the cost of leaving out too many useful
things.

chrisq

2024-08-20 12:29:18 UTC

Absolutely, must have come from an assembler background, where the
use of signed branches and arithmetic, can get you into serious trouble.
The standard C library, of course, tends to use signed variables for
everything, a gross error that has never been fixed...

At least the C people can define an unsigned variable.
Java does not have unsigned data types at all. OK - higher level
language and all that. But still a PITA.
Arne

I guess another complication is that some functions return
-1, which implies a signed variable. To fix all that would require a
complete rewrite of the library and probably most of the os and
applications as well, so it will never happen. Just have to write
unsigned equivalents, or slip functions with casts, but it's a lot
of additional work.

Chris

Simon Clubley

2024-08-20 12:36:51 UTC

Post by chrisq
I guess another complication is that some functions return
-1, which implies a signed variable. To fix all that would require a
complete rewrite of the library and probably most of the os and
applications as well, so it will never happen. Just have to write
unsigned equivalents, or slip functions with casts, but it's a lot
of additional work.

One thing I wish was available in all languages is the ability to return
multiple values from a function call so you can return both a status and
the value(s) in one assignment. Ie: "a, b, c = demo_function(param1, param2);".

In languages with dynamic associative arrays (such as PHP), I simulate
this by returning an associative array from a function call with both
status and value fields. Makes coding _so_ much cleaner and robust.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

chrisq

2024-08-20 13:11:04 UTC

The way to get round that here, for many functions
with multiple parameters, is to declare a structure,
with the args, status and even status qualifier.
Can include buffer pointers and lengths as well.
Fill in the args, then pass a pointer to that
for the call. Not only is it efficient, as it
can be passed using single register, but it's
also easy to add structure elements without affecting
other code that calls it. It can help to
make code fully rentrant and is a way to get some
abstraction for little effort. Also seems like good
practice, as one of the key design tasks should
be to accurately define and encapsulate the
interfaces to the code.

Quite a bit of unix code that uses such techniques,
as does vms with descriptors, if that'a the
right name for it.

Chris

Post by Simon Clubley
In languages with dynamic associative arrays (such as PHP), I simulate
this by returning an associative array from a function call with both
status and value fields. Makes coding _so_ much cleaner and robust.
Simon.

Lawrence D'Oliveiro

2024-08-21 01:19:45 UTC

Quite a bit of unix code that uses such techniques, as does vms with
descriptors, if that'a the right name for it.

Umm, you might be thinking of item lists?

Wonderful things ... you could tell the terminal driver was getting
complex in VMS V4, I think it was, when they introduced QIO calls done
with item lists ...

Arne Vajhøj

2024-08-21 01:31:33 UTC

Quite a bit of unix code that uses such techniques, as does vms with
descriptors, if that'a the right name for it.

Umm, you might be thinking of item lists?
Wonderful things ... you could tell the terminal driver was getting
complex in VMS V4, I think it was, when they introduced QIO calls done
with item lists ...

Where are SYS$QIO(W) using item lists?

Arne

Lawrence D'Oliveiro

2024-08-21 01:48:32 UTC

Quite a bit of unix code that uses such techniques, as does vms with
descriptors, if that'a the right name for it.

Umm, you might be thinking of item lists?
Wonderful things ... you could tell the terminal driver was getting
complex in VMS V4, I think it was, when they introduced QIO calls done
with item lists ...

Where are SYS$QIO(W) using item lists?

OpenVMS v8.4 I/O User’s Reference, section 5.3.1.3, “Itemlist Read
Operations”.

<https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c04622349>

Arne Vajhøj

2024-08-20 13:47:36 UTC

One thing I wish was available in all languages is the ability to return
multiple values from a function call so you can return both a status and
the value(s) in one assignment. Ie: "a, b, c = demo_function(param1, param2);".
In languages with dynamic associative arrays (such as PHP), I simulate
this by returning an associative array from a function call with both
status and value fields. Makes coding _so_ much cleaner and robust.

Few languages support multiple return values.

And a few other languages support tuples with named fields
or anonymous classes with named properties, which is almost as good.

And almost all newer high level languages support
map/dictionary/associative array.

Arne

Lawrence D'Oliveiro

2024-08-21 01:25:20 UTC

Post by Arne VajhÃ¸j
Few languages support multiple return values.

Even in C and Fortran, a function can return a struct.

Arne Vajhøj

2024-08-21 01:35:44 UTC

Post by Arne VajhÃ¸j
Few languages support multiple return values.

Even in C and Fortran, a function can return a struct.

Yes. But that is returning a single value - just a composite value.

It works fine, but it requires a custom type.

Arne

Lawrence D'Oliveiro

2024-08-21 01:51:46 UTC

Post by Arne VajhÃ¸j
Few languages support multiple return values.

Even in C and Fortran, a function can return a struct.

Yes. But that is returning a single value - just a composite value.

The distinction between “multiple value” versus “single composite value”
is an artificial one specific to languages like Lisp. Python, for example,
is quite happy with constructs like

a, b = struct.unpack("hh", b"\x00\x00\xff\xff")

And I think also JavaScript works that way.

Arne Vajhøj

2024-08-21 02:14:31 UTC

Post by Arne VajhÃ¸j
Few languages support multiple return values.

Even in C and Fortran, a function can return a struct.

Yes. But that is returning a single value - just a composite value.

If the language supports tuples or has a generic tuple class
or an other way to avoid creating a type for each
type combo of return values, then it is pretty much the same.

But with languages like C and Fortran there is a big difference.

Arne

Single Stage to Orbit

2024-08-20 14:47:00 UTC

Post by Simon Clubley
One thing I wish was available in all languages is the ability to
return multiple values from a function call so you can return both a
status and the value(s) in one assignment. Ie: "a, b, c =
demo_function(param1, param2);".
In languages with dynamic associative arrays (such as PHP), I
simulate this by returning an associative array from a function call
with both status and value fields. Makes coding _so_ much cleaner and
robust.

Rust does this very well:

pub fn swap(a: u32, b: u32) -> (u32, u32)
{
(b, a)
}

--
Tactical Nuclear Kittens

bill

2024-08-20 17:34:29 UTC

One thing I wish was available in all languages is the ability to return
multiple values from a function call so you can return both a status and
the value(s) in one assignment. Ie: "a, b, c = demo_function(param1, param2);".
In languages with dynamic associative arrays (such as PHP), I simulate
this by returning an associative array from a function call with both
status and value fields. Makes coding _so_ much cleaner and robust.

And probably much harder to understand in anything but the most
trivial usage.

bill

Simon Clubley

2024-08-20 17:47:56 UTC

One thing I wish was available in all languages is the ability to return
multiple values from a function call so you can return both a status and
the value(s) in one assignment. Ie: "a, b, c = demo_function(param1, param2);".
In languages with dynamic associative arrays (such as PHP), I simulate
this by returning an associative array from a function call with both
status and value fields. Makes coding _so_ much cleaner and robust.

And probably much harder to understand in anything but the most
trivial usage.

Huh ? Well that shows you haven't done this kind of thing. :-)

If you are talking about PHP, you construct an associative array
in the return statement of the function and then access the keys
in the caller. Very clean.

If you are talking about some future thing based on C, you simply
extend the function prototype to include a list of return types
instead of the single type it is at the moment and you just return
the list in the function's return statement.

$ set response/mode=good_natured

Or are associative arrays and other higher-level data structures an alien
concept to you ? :-)

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Arne Vajhøj

2024-08-20 18:16:39 UTC

And probably much harder to understand in anything but the most
trivial usage.

It is easy to understand if reasonable descriptive key names are chosen.

Example:

$ type mr.php
<?php

function four_ops($a, $b) {
return array('plus' => $a + $b, 'minus' => $a - $b, 'multiply' =>
$a * $b, 'divide' => $a / $b);
}

$a = 3.0;
$b = 2.0;
$res = four_ops($a, $b);
echo sprintf("%f + %f = %f\r\n", $a, $b, $res['plus']);
echo sprintf("%f - %f = %f\r\n", $a, $b, $res['minus']);
echo sprintf("%f * %f = %f\r\n", $a, $b, $res['multiply']);
echo sprintf("%f / %f = %f\r\n", $a, $b, $res['divide']);

?>
$ php mr.php
3.000000 + 2.000000 = 5.000000
3.000000 - 2.000000 = 1.000000
3.000000 * 2.000000 = 6.000000
3.000000 / 2.000000 = 1.500000

Arne

Simon Clubley

2024-08-20 12:29:52 UTC

At least the C people can define an unsigned variable.
Java does not have unsigned data types at all. OK - higher level
language and all that. But still a PITA.

Don't get me bloody started on that. :-) Currently doing some Java
development as part of a personal non-work project on Android.

On the plus side, I do like the ease of been able to send messages in
a message queue between threads however and the clean integration of
threads into the language. See:

https://developer.android.com/reference/android/os/Handler

On the negative side, some things can be so bureaucratic in the Android
and Java world. For example, the Android documentation keeps trying to force
you into using Fragments (and the associated Activity) when simple Views
are a lot easier to handle.

At times, Java itself seems to "feel" like it has been designed by theorists
with little real-world experience. All the classes-upon-classes when doing
I/O come to mind here.

And BTW, Java, is it .size() or .length() ??? Pick one and stick with it
when you design your classes. :-(

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Arne Vajhøj

2024-08-20 14:15:03 UTC

Post by Simon Clubley
At times, Java itself seems to "feel" like it has been designed by theorists
with little real-world experience. All the classes-upon-classes when doing
I/O come to mind here.

JCP is just like ANSI, ISO and ECMA.

Java is literally designed by committee.

And there are some horror decisions. The compiler API comes
to my mind - it takes 200 lines to do what you can do in 5 lines
in C#.

The java.io package may seem a bit complex, but it makes perfect
sense when you learn the structure.

The basics is:

InputStream - read bytes from anything
FileInputStream - read bytes from file
ByteArrayInputStream - read bytes from byte array
...
OutputStream - write bytes to anything
FileOutputStream - write bytes to file
ByteArrayOutputStream - write bytes to byte array
...
Reader - read chars according to encoding from anything
FileReader - read chars according to encoding from file
CharArrayReader - read chars according to encoding from char array
...
Writer - write chars according to encoding to anything
FileWriter - write chars according to encoding to file
CharArrayWriter - write chars according to encoding to char array
...

All very systematic.

On top of that there are two convenience classes to work with text
files:
* BufferedReader that wraps any Reader and provides a readLine method
* PrintWriter that wraps any Writer and provides print, println and
printf methods

Remember that and you can handle 98% of cases.

For the last 2% reading the docs will be needed.

Arne

Simon Clubley

2024-08-20 17:38:44 UTC

Post by Simon Clubley
At times, Java itself seems to "feel" like it has been designed by theorists
with little real-world experience. All the classes-upon-classes when doing
I/O come to mind here.

JCP is just like ANSI, ISO and ECMA.
Java is literally designed by committee.

It shows. :-)

Post by Arne VajhÃ¸j
And there are some horror decisions. The compiler API comes
to my mind - it takes 200 lines to do what you can do in 5 lines
in C#.

Also, no dynamic arrays built into the language itself. You need ArrayList()
to implement them or things like ByteArrayOutputStream().

Post by Arne VajhÃ¸j
The java.io package may seem a bit complex, but it makes perfect
sense when you learn the structure.
InputStream - read bytes from anything
FileInputStream - read bytes from file
ByteArrayInputStream - read bytes from byte array
...
OutputStream - write bytes to anything
FileOutputStream - write bytes to file
ByteArrayOutputStream - write bytes to byte array
...
Reader - read chars according to encoding from anything
FileReader - read chars according to encoding from file
CharArrayReader - read chars according to encoding from char array
...
Writer - write chars according to encoding to anything
FileWriter - write chars according to encoding to file
CharArrayWriter - write chars according to encoding to char array
...
All very systematic.
On top of that there are two convenience classes to work with text
* BufferedReader that wraps any Reader and provides a readLine method
* PrintWriter that wraps any Writer and provides print, println and
printf methods
Remember that and you can handle 98% of cases.
For the last 2% reading the docs will be needed.

You forgot about InputStreamReader() to turn an InputStream into a Reader. :-)
After all, why miss the opportunity to have two parallel sets of APIs
(byte versus character) instead of just the one API ? :-)

Goodness knows why they didn't just add something like String's getBytes()
method to the character APIs or add character support to the byte APIs...

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Arne Vajhøj

2024-08-20 18:37:26 UTC

Post by Simon Clubley
Also, no dynamic arrays built into the language itself. You need ArrayList()
to implement them or things like ByteArrayOutputStream().

At the level of Java then I think that is to be expected. A
dynamic data structure requires a collection type. In C#
List<T> and T[] are different. In C++ vector<T> and T[] are
different.

But Java developers should consider ArrayList<T> to be their
default choice instead of T[].

You forgot about InputStreamReader() to turn an InputStream into a Reader. :-)

There are InputStreamReader to convert from InputStream to Reader and
OutputStreamWriter to convert from OutputStream to Writer.

And they are actually used, because some API's has classes that only has
getInputStream()/getOutputStream() methods and not
getReader()/getWriter() methods.

All follow the model.

Post by Simon Clubley
After all, why miss the opportunity to have two parallel sets of APIs
(byte versus character) instead of just the one API ? :-)
Goodness knows why they didn't just add something like String's getBytes()
method to the character APIs or add character support to the byte APIs...

Because InputStream/OutputStream and Reader/Writer are fundamentally
different.

The first transfer between an in memory sequence of bytes
(-128..127 values) to an external form of same sequence of
bytes (-128..127 values).

The second transfer between an in memory sequence of
sequence of chars aka Unicode code points (0..65536 values)
usually in the form of String objects to an external form
of sequence of bytes (-128..127) values often of a different
length according to some encoding (UTF-8 is most common but
there are hundreds of possibilities: UTF-16, UTF-32, ISO-8859-x,
ASCII, EBCDIC, various non-latin).

In C then wprintf/wscanf are not the same as printf/scanf either.

The difference is that very few use wide in C while everybody is
more or less forced to use wide in Java.

Arne

Arne Vajhøj

2024-08-20 18:45:41 UTC

Post by Arne VajhÃ¸j
The second transfer between an in memory sequence of
sequence of chars aka Unicode code points (0..65536 values)
usually in the form of String objects

Correction.

That was how it was when it was designed.

Today it is:

... UTF-16 code units (0..65536 values) ...

Arne

Craig A. Berry

2024-08-20 21:12:56 UTC

Post by Arne VajhÃ¸j
The second transfer between an in memory sequence of
sequence of chars aka Unicode code points (0..65536 values)
usually in the form of String objects

Correction.
That was how it was when it was designed.
... UTF-16 code units (0..65536 values) ...

That was UCS-2, which was fixed width. UTF-16 can encode all the code
points in Unicode because it is varying width.

Arne Vajhøj

2024-08-20 22:39:17 UTC

Post by Arne VajhÃ¸j
The second transfer between an in memory sequence of
sequence of chars aka Unicode code points (0..65536 values)
usually in the form of String objects

Correction.
That was how it was when it was designed.
... UTF-16 code units (0..65536 values) ...

That was UCS-2, which was fixed width. UTF-16 can encode all the code
points in Unicode because it is varying width.

The distinction I was trying to make is between
(Unicode) code points and (UTF-16) code units.

A code point can be encoded in a variable number of code units.

Arne

Arne Vajhøj

2024-08-20 19:10:51 UTC

Post by Arne VajhÃ¸j
Because InputStream/OutputStream and Reader/Writer are fundamentally
different.
The first transfer between an in memory sequence of bytes
(-128..127 values) to an external form of same sequence of
bytes (-128..127 values).
The second transfer between an in memory sequence of
sequence of chars aka Unicode code points (0..65536 values)
usually in the form of String objects to an external form
of sequence of bytes (-128..127) values often of a different
length according to some encoding (UTF-8 is most common but
there are hundreds of possibilities: UTF-16, UTF-32, ISO-8859-x,
ASCII, EBCDIC, various non-latin).

Demo:

$ type OSDemo.java
import java.io.*;

public class OSDemo {
public static void main(String[] args) throws Exception {
try(OutputStream os = new FileOutputStream("os.dat")) {
os.write(1);
os.write(2);
os.write(3);
}
}
}
$ javac OSDemo.java
$ java OSDemo
$ dump os.dat

Dump of file DKA0:[arne]os.dat;2 on 20-AUG-2024 15:05:50.22
File ID (52122,13,0) End of file block 1 / Allocated 16

Virtual block number 1 (00000001), 512 (0200) bytes

00000000 00000000 00000000 00000000 00000000 00000000 00000000
00030201 ................................ 000000

$ type WrtDemo.java
import java.io.*;

public class WrtDemo {
public static void main(String[] args) throws Exception {
try(PrintWriter pw = new PrintWriter("pw_" +
args[0].toLowerCase() + ".txt", args[0])) {
pw.printf("%d %d %d\n", 1, 2, 3);
}
}
}
$ javac WrtDemo.java
$ java WrtDemo "UTF-8"
$ dump pw_utf-8.txt

Dump of file DKA0:[arne]pw_utf-8.txt;2 on 20-AUG-2024 15:06:00.26
File ID (52124,20,0) End of file block 1 / Allocated 16

Virtual block number 1 (00000001), 512 (0200) bytes

00000000 00000000 00000000 00000000 00000000 00000000 00000A33
20322031 1 2 3........................... 000000

$ java WrtDemo "UTF-16"
$ dump pw_utf-16.txt

Dump of file DKA0:[arne]pw_utf-16.txt;2 on 20-AUG-2024 15:06:02.38
File ID (52126,11,0) End of file block 1 / Allocated 16

Virtual block number 1 (00000001), 512 (0200) bytes

00000000 00000000 00000000 00000000 00000A00 33002000 32002000
3100FFFE þ..1. .2. .3.................... 000000

Arne

Simon Clubley

2024-08-21 12:18:46 UTC

Post by Simon Clubley
You forgot about InputStreamReader() to turn an InputStream into a Reader. :-)

There are InputStreamReader to convert from InputStream to Reader and
OutputStreamWriter to convert from OutputStream to Writer.
And they are actually used, because some API's has classes that only has
getInputStream()/getOutputStream() methods and not
getReader()/getWriter() methods.
All follow the model.

Because InputStream/OutputStream and Reader/Writer are fundamentally
different.

I may not have stated that clearly enough.

The character model is built in top of a byte model, with character-specific
knowledge in the character classes.

The traditional Java way to add this additional functionality is to extend
a class in a subclass and implement the additional functionality in the
subclass.

I am having a hard time seeing why they didn't just extend the byte I/O
classes in this way to implement additional character functionality so
that both character and byte I/O directly uses an InputStream (and likewise
for an OutputStream). There should be no need for a character-specific
Reader concept or an InputStreamReader() converter.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Lawrence D'Oliveiro

2024-08-21 01:18:07 UTC

And there are some horror decisions. The compiler API comes to my mind -
it takes 200 lines to do what you can do in 5 lines in C#.

Java is full of stuff like that.

The java.io package may seem a bit complex, but it makes perfect sense
when you learn the structure.

Until you try to include niceties like select/poll. Then you get into a
whole mess of extra classes/methods.

I suppose, given its origin in the 1990s, the Java designers thought all
nonblocking I/O should be handled through threads ...

Arne Vajhøj

2024-08-21 01:29:13 UTC

The java.io package may seem a bit complex, but it makes perfect sense
when you learn the structure.

Until you try to include niceties like select/poll. Then you get into a
whole mess of extra classes/methods.
I suppose, given its origin in the 1990s, the Java designers thought all
nonblocking I/O should be handled through threads ...

That stuff is not in java.io but in java.nio and added
in Java 1.4 (2002).

Not that many classes, but a totally different set of classes.

Arne

Lawrence D'Oliveiro

2024-08-21 01:52:29 UTC

The java.io package may seem a bit complex, but it makes perfect sense
when you learn the structure.

Until you try to include niceties like select/poll. Then you get into a
whole mess of extra classes/methods.
I suppose, given its origin in the 1990s, the Java designers thought
all nonblocking I/O should be handled through threads ...

That stuff is not in java.io but in java.nio and added in Java 1.4
(2002).
Not that many classes, but a totally different set of classes.

Even worse.

bill

2024-08-20 17:43:45 UTC

On 8/20/2024 8:29 AM, Simon Clubley wrote:
I stopped working with Java almost a decade ago. (it coincided with
my retirement when I no longer had to do work for others!)
But, here goes....

Post by Simon Clubley
At times, Java itself seems to "feel" like it has been designed by theorists
with little real-world experience.

What makes you think it wasn't? Kinda like Ada. The USAF came up
with an idea because they needed it for their jets. Others got
involved resulting in a product that no longer met their needs.
DOD mandated Ada usage. The USAF said no thank you and went back
to Jovial. :-)

Post by Simon Clubley
All the classes-upon-classes when doing
I/O come to mind here.
And BTW, Java, is it .size() or .length() ??? Pick one and stick with it
when you design your classes. :-(

To me size and length are not the same thing. Strings have length.
Data types, pointers and the like have size. Anything trying to
make the two interchangeable is just wrong. :-)

bill

Simon Clubley

2024-08-20 18:23:29 UTC

Post by bill
I stopped working with Java almost a decade ago. (it coincided with
my retirement when I no longer had to do work for others!)
But, here goes....

Post by Simon Clubley
At times, Java itself seems to "feel" like it has been designed by theorists
with little real-world experience.

Huh ? Ada has seen a _lot_ of use in safety-critical applications,
including in areas where there is no government mandate.

I can't speak to going back to Jovial (assuming you have not got
the details wrong), but the other choices such as C++ seemed to be
more political in nature once the mandate was dropped.

Post by Simon Clubley
All the classes-upon-classes when doing
I/O come to mind here.
And BTW, Java, is it .size() or .length() ??? Pick one and stick with it
when you design your classes. :-(

To me size and length are not the same thing. Strings have length.
Data types, pointers and the like have size. Anything trying to
make the two interchangeable is just wrong. :-)

And to confuse this further, in Java an array has a .length variable
(not method), while ArrayList has a .size() method. :-)

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

bill

2024-08-20 19:56:13 UTC

Post by bill
I stopped working with Java almost a decade ago. (it coincided with
my retirement when I no longer had to do work for others!)
But, here goes....

Post by Simon Clubley
At times, Java itself seems to "feel" like it has been designed by theorists
with little real-world experience.

Huh ? Ada has seen a _lot_ of use in safety-critical applications,
including in areas where there is no government mandate.

Of course it has. And there is no doubt it is a pretty good
language. But the point was it ended up being nothing like
the original requestor asked for. The usual result of design
by committee.

Post by Simon Clubley
I can't speak to going back to Jovial (assuming you have not got
the details wrong), but the other choices such as C++ seemed to be
more political in nature once the mandate was dropped.

That comment was a little tongue in cheek. Jovial isn't and to
the best of my knowledge never was used for embedded programming.
But the USAF used it a lot for a lot of other things. Their
intent was for Ada to become their standard language. Never happened
and they did continue using Jovial.

bill

Stephen Hoffman

2024-08-19 20:05:59 UTC

Post by chrisq

Post by Simon Clubley
That works great until you need to interface to the OS unfortunately.
BTW, I've been writing my own code with explicit sizing for many years.
To extend this, I also know the difference between signed and unsigned
variables and I have a default-unsigned approach unless I absolutely
_need_ a signed variable.
Unfortunately, a lot of the material out there doesn't seem to
understand that designing a program is about modelling a real-world
problem and that it isn't OK to just use a signed integer to store an
unsigned value.

Unfortunately a lot of apps are implemented in C or C++ when they
probably shouldn't, too.

Package management is another area where C, C++, and OpenVMS itself all
get into trouble.

Same for concurrency, strings, and various other topics.

Post by chrisq
Absolutely, must have come from an assembler background, where the use
of signed branches and arithmetic, can get you into serious trouble.
The standard C library, of course, tends to use signed variables for
everything, a gross error that has never been fixed...

The C compiler promotes unsigned to signed, as well. And this promotion
"fun" includes uint*_t variables quite possibly getting promoted to
signed.

q.v.: C11 6.3.1.1: "If an int can represent all values of the original
type (as restricted by the width, for a bit-field), the value is
converted to an int; otherwise, it is converted to an unsigned int.
These are called the integer promotions."
Also q.v.: C11 6.3.18: "Usual arithmetic conversions"

strings and character encoding are more "fun":
https://thephd.dev/the-c-c++-rust-string-text-encoding-api-landscape

apropos of nothing, OpenVMS has a whole pile of tooling to avoid
changing constants:
https://devblogs.microsoft.com/cppblog/how-we-used-cpp20-to-eliminate-an-entire-class-of-runtime-bugs/

Porting is hard: https://github.com/ziglang/zig/pull/13560 (And
sometimes creative.)

And if you're coexisting with C and C++ (incrementally or otherwise):
https://kristoff.it/blog/maintain-it-with-zig/

And if you're deep into C++, the following might interest (Apache 2.0):
https://github.com/abseil/abseil-cpp

Swift as a replacement for issues with C and C++ (and deterministic
testing, and cross-language optimization):

This won't be happening anytime soon if ever of course, as VSI has
beyond more than enough work in their pending queue.

--
Pure Personal Opinion | HoffmanLabs LLC

Lawrence D'Oliveiro

2024-08-19 23:33:46 UTC

If a system/library call is going to return a dynamic amount of data, it
is good if it can give some indication of how much data it is going to
return first.

The best calls are the ones that, if you pass NULL for the buffer, they
will return the number of bytes they would have put in the buffer. So you
allocate that size of buffer and do a second call, and get back the actual
buffer data.

I did a Python wrapper for Fribidi, and unfortunately its text-encoding
conversion calls didn’t work that way. But then, they probably
couldn’t ...

chrisq

2024-08-20 12:36:43 UTC

Post by Lawrence D'Oliveiro
If a system/library call is going to return a dynamic amount of data, it
is good if it can give some indication of how much data it is going to
return first.
The best calls are the ones that, if you pass NULL for the buffer, they
will return the number of bytes they would have put in the buffer. So you
allocate that size of buffer and do a second call, and get back the actual
buffer data.
I did a Python wrapper for Fribidi, and unfortunately its text-encoding
conversion calls didn’t work that way. But then, they probably
couldn’t ...

For work here, all functions that return data have a parameter that
limits the byte count. Usually pass a pointer to a buffer, with the size
parameter equal to or less than the buffer size. Some C library
functions are just not safe to use in that respect.

Local spun string copy and other functions use the same sort of size
limiting.

Chris

Simon Clubley

2024-08-20 12:13:56 UTC

Post by chrisq

From both ends of the scale actually. :-)

In my early days, I had a _lot_ of assembly language experience.

That was then followed by Wirth language and then Ada experience.

The Wirth languages and then Ada was where my experience to date turned
into a preference for strict data types and the importance of modelling
as accurately as possible the real-world problem you are implementing.

BTW, I still consider classic ARM to be the most elegant assembly language
I have encountered (although those with M68K and similar experience tend
say they are somewhat better).

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

chrisq

2024-08-19 18:51:07 UTC

Post by Arne VajhÃ¸j
And it has different size of long and pointers. Causing problems
* code that make implicit assumptions that those are 32 bit
* mixing C and C++

For years in embedded work here, there is always a header file,
wordsize.h which aliases such as U8, U16, U32 etc, to the bit
sizes of the types related to the cpu variant and tools in
use. Pretty foolproof, and important for embedded work, where
you often need to know the width of hardware registers, and
the variables and pointers that interact with them...

Arne Vajhøj

2024-08-14 20:23:47 UTC

Post by Arne VajhÃ¸j
And it has different size of long and pointers. Causing problems
* code that make implicit assumptions that those are 32 bit
* mixing C and C++

And in case someone has not seen it:

$ type long.h
#ifdef __cplusplus
extern "C" {
#endif

struct data
{
long a;
long b;
long c;
long d;
};

#ifdef __cplusplus
}
#endif
$ type long1.cxx
#include "long.h"

extern "C" {
void f(struct data *d);
}

int main()
{
struct data o;
o.a = 1;
o.b = 2;
o.c = 3;
o.d = 4;
f(&o);
return 0;
}
$ type long2.c
#include <stdio.h>

#include "long.h"

void f(struct data *o)
{
printf("%ld %ld %ld %ld\n", o->a, o->b, o->c, o->d);
}
$ cxx/name=upper long1
$ cc long2
$ link/exe=long long1 + long2
$ run long
1 0 2 0

Arne

Arne Vajhøj

2024-08-14 23:18:11 UTC

Post by Arne VajhÃ¸j
And it has different size of long and pointers. Causing problems
* code that make implicit assumptions that those are 32 bit
* mixing C and C++

$ type long.h

And the same with pointers:

$ type ptr.h
#ifdef __cplusplus
extern "C" {
#endif

struct data
{
void* a;
void* b;
void* c;
void* d;
};

#ifdef __cplusplus
}
#endif
$ type ptr1.cxx
#include "ptr.h"

extern "C" {
void f(struct data *d);
}

int main()
{
struct data o;
o.a = (void *)1;
o.b = (void *)2;
o.c = (void *)3;
o.d = (void *)4;
f(&o);
return 0;
}
$ type ptr2.c
#include <stdio.h>

#include "ptr.h"

void f(struct data *o)
{
printf("%p %p %p %p\n", o->a, o->b, o->c, o->d);
}
$ cxx/name=upper ptr1
$ cc ptr2
$ link/exe=ptr ptr1 + ptr2
$ run ptr
1 0 2 0
$ cxx/name=upper/pointer=32 ptr1
$ cc ptr2
$ link/exe=ptr ptr1 + ptr2
$ run ptr
1 2 3 4
$ cxx/name=upper ptr1
$ cc/pointer=64 ptr2
$ link/exe=ptr ptr1 + ptr2
$ run ptr
1 2 3 4

Arne

Lawrence D'Oliveiro

2024-08-14 23:47:06 UTC

Post by Arne VajhÃ¸j
And it has different size of long and pointers.

If you wanted an integer type that is compatible with pointers, that was
always intptr_t and uintptr_t, surely

Arne Vajhøj

2024-08-14 23:58:30 UTC

Post by Arne VajhÃ¸j
And it has different size of long and pointers.

If you wanted an integer type that is compatible with pointers, that was
always intptr_t and uintptr_t, surely

I am not being particular clear.

I am not saying that:

default sizeof long C++ x64 <> default sizeof pointer C++ x64

I am saying that:

default sizeof long C++ x64 <> default sizeof long C++ Itanium & Alpha
default sizeof pointer C++ x64 <> default sizeof pointer C++ Itanium & Alpha

and later:

default sizeof long C++ x64 <> default sizeof long C x64
default sizeof pointer C++ x64 <> default sizeof pointer C x64

Arne

Lawrence D'Oliveiro

2024-08-15 00:07:41 UTC

Post by Arne VajhÃ¸j
default sizeof long C++ x64 <> default sizeof long C++ Itanium & Alpha
default sizeof pointer C++ x64 <> default sizeof pointer C++ Itanium & Alpha
default sizeof long C++ x64 <> default sizeof long C x64

This is why you have stdint.h.

Post by Arne VajhÃ¸j
default sizeof pointer C++ x64 <> default sizeof pointer C x64

Interesting ... is C++ always supposed to be ABI-compatible with C?

Arne Vajhøj

2024-08-15 00:24:04 UTC

This is why you have stdint.h.

Yes.

But short/int/long/long long are unfortunately very common in C/C++
code probably an order of magnitude larger than
int8_t/int16_t/int32_t/int64_t.

Post by Arne VajhÃ¸j
default sizeof pointer C++ x64 <> default sizeof pointer C x64

Interesting ... is C++ always supposed to be ABI-compatible with C?

I don't think there is any guarantee for such compatibility. Two
different compilers are free to behave differently.

But they were compatible on Alpha and Itanium.

And I think C++ and C compilers of same origin are usually compatible
on other platforms as well.

It is practical. C++ code calling C code is quite common.

Arne

John Reagan

2024-08-21 08:21:17 UTC

Post by Arne VajhÃ¸j
And it has different size of long and pointers.

If you wanted an integer type that is compatible with pointers, that was
always intptr_t and uintptr_t, surely

I am not being particular clear.
default sizeof long C++ x64 <> default sizeof pointer C++ x64
default sizeof long C++ x64 <> default sizeof long C++ Itanium & Alpha
default sizeof pointer C++ x64 <> default sizeof pointer C++ Itanium & Alpha
default sizeof long C++ x64 <> default sizeof long C x64
default sizeof pointer C++ x64 <> default sizeof pointer C x64
Arne

Yes, all good points. The size_t and offset_t = 32-bits and ptrdiff_t =
32-bits on Alpha/Itanium started the mess years ago.

Personally, I would have kept all the defaults the same as Itanium but
got "convinced" to go wider. The first attempt was ONLY 64-bit pointers
on x86 with C++ but things like those pesky descriptors and itemlists
got in the way.

I did suggest an LP64, ILP32, etc qualifier but mostly got blank stares
from other engineers as "too nerdy"

long == 64-bits has caused us to make changes as prior header writers
assumed that long was 32-bits. They should have all followed Arne's
advice and used int32_t and int64_t when specifying their ABIs.

I'll can take some ownership on the changes, but I suffered with years
of "John, why is size_t 32-bits? Why does subtracting two 64-bit
pointers only give me a 32-bit result?"

Arne Vajhøj

2024-08-21 11:08:07 UTC

Yes, all good points. The size_t and offset_t = 32-bits and ptrdiff_t =
32-bits on Alpha/Itanium started the mess years ago.
Personally, I would have kept all the defaults the same as Itanium but
got "convinced" to go wider. The first attempt was ONLY 64-bit pointers
on x86 with C++ but things like those pesky descriptors and itemlists
got in the way.
I did suggest an LP64, ILP32, etc qualifier but mostly got blank stares
from other engineers as "too nerdy"
long == 64-bits has caused us to make changes as prior header writers
assumed that long was 32-bits. They should have all followed Arne's
advice and used int32_t and int64_t when specifying their ABIs.
I'll can take some ownership on the changes, but I suffered with years
of "John, why is size_t 32-bits? Why does subtracting two 64-bit
pointers only give me a 32-bit result?"

Hindsight is always easy.

:-)

Knowing what we know now then I think that:
* an option to change size of long
* having CXX command default to 32 bit pointers and 32 bit long
with two options to go 64 bit (pointer do already have it)
* having clang command go more pure 64 bit
may have been the right path.

But too late.

Well - not too late for /LONG=32 and /LONG=64 !

Arne

John Dallman

2024-08-15 08:41:00 UTC

Post by Robert A. Brooks
I don't know specifically, but with my very limited experience with
C++, the X86_64 compiler is much less accepting of the syntax that
the Alpha and IA64 compilers accepted.

C++ compilers have been getting pickier over the last couple of decades
gradually. Programmers who have been using a succession of Microsoft or
GCC versions over that time have made the changes incrementally, but
doing them all at once would be a bit of a shock.

John

Arne Vajhøj

2024-08-15 12:24:39 UTC

Why do I think of:

VAX C 3.x -> DEC C 4.x -> DEC C 5.x

back in the 90's?

:-)

Arne

Simon Clubley

2024-08-15 12:38:28 UTC

VAX C 3.x -> DEC C 4.x -> DEC C 5.x
back in the 90's?
:-)

Why do I think of John having to support /STANDARD=VAXC in 2024 ? :-)

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Arne Vajhøj

2024-08-14 18:07:31 UTC

Did this get lost in all the spam filters?
I guess a YouTube link does look like spam, but ...

I 100% agree.

There is a link to the slide decks on Youtube.

Post by Simon Clubley
Based on the above, I would guess/hope early next year for them to be ready,
which would put them a year behind schedule. It would be interesting to
know the reasons for the failures however and what is different about the
x86-64 environment that resulted in test differences that ended up being
classified as failures.
In total, there's about 10% of the tests which have not been done or have
failed, but as we all know the first 90% of a project takes 90% of the
time and the last 10% takes the other 90% of the time. :-)

Slide 39 says H1CY2025 so "early next year".

The slides list some of the challenges they had.

In my poor wording:
* like everybody else they had to start with cross compilers
and then switch to native compilers
* they need to generate native code, so they needed to get
GEM2LLVM and LLVM backends from VSI and integrate them
* like everybody else they got problems with C++ code because
clang is not compatible with traditional VMS C++
* they relied on some tools build with VAX SCAN and first
VESTed and later AESTed - since no IEST exist they had to
rewrite those tools (in Java)

The slides does not say so, but it is probably a huge code base
and given that some of it is 4 decades old, then there may be some
hacks in the code.

Oracle DB - what is known as Oracle Classic in the VMS world:
https://news.ycombinator.com/item?id=18442941

:-)

Arne

Lawrence D'Oliveiro

2024-08-15 23:57:42 UTC

Post by Simon Clubley
However, since you ask, I prefer a writeup rather than a 40 minute
video for this kind of update ...

I 100% agree.

Have you tried playing the video at a higher speed, to get through it
quicker?

Simon Clubley

2024-08-16 12:07:02 UTC

Post by Simon Clubley
However, since you ask, I prefer a writeup rather than a 40 minute
video for this kind of update ...

I 100% agree.

Have you tried playing the video at a higher speed, to get through it
quicker?

That's a hack, not a solution (and there are severe limits to how much
incremental time you can save with this approach).

Written material is a far better solution in this situation.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Dave Froble

2024-08-16 17:16:00 UTC

Post by Simon Clubley
However, since you ask, I prefer a writeup rather than a 40 minute
video for this kind of update ...

I 100% agree.

Have you tried playing the video at a higher speed, to get through it
quicker?

That's a hack, not a solution (and there are severe limits to how much
incremental time you can save with this approach).
Written material is a far better solution in this situation.
Simon.

People can process written material at their own chosen speed ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

bill

2024-08-16 18:52:07 UTC

Post by Simon Clubley
However, since you ask, I prefer a writeup rather than a 40 minute
video for this kind of update ...

I 100% agree.

Have you tried playing the video at a higher speed, to get through it
quicker?

That's a hack, not a solution (and there are severe limits to how much
incremental time you can save with this approach).
Written material is a far better solution in this situation.
Simon.

People can process written material at their own chosen speed ...

More importantly, how are all you people accessing YouTube under VMS?

bill

Arne Vajhøj

2024-08-16 18:56:56 UTC

Post by Simon Clubley
However, since you ask, I prefer a writeup rather than a 40 minute
video for this kind of update ...

I 100% agree.

Have you tried playing the video at a higher speed, to get through it
quicker?

That's a hack, not a solution (and there are severe limits to how much
incremental time you can save with this approach).
Written material is a far better solution in this situation.

People can process written material at their own chosen speed ...

More importantly, how are all you people accessing YouTube under VMS?

I doubt that any of the very old browsers available for VMS support
the required JavaScript and video format.

But the common PC with Windows/Linux/macOS should be able to do it.

Arne

bill

2024-08-17 21:09:53 UTC

Post by Simon Clubley
However, since you ask, I prefer a writeup rather than a 40 minute
video for this kind of update ...

I 100% agree.

Have you tried playing the video at a higher speed, to get through it
quicker?

That's a hack, not a solution (and there are severe limits to how much
incremental time you can save with this approach).
Written material is a far better solution in this situation.

People can process written material at their own chosen speed ...

More importantly, how are all you people accessing YouTube under VMS?

I doubt that any of the very old browsers available for VMS support
the required JavaScript and video format.
But the common PC with Windows/Linux/macOS should be able to do it.

But that's not VMS.... :-)

bill

Dave Froble

2024-08-18 01:59:26 UTC

Post by Simon Clubley
However, since you ask, I prefer a writeup rather than a 40 minute
video for this kind of update ...

I 100% agree.

Have you tried playing the video at a higher speed, to get through it
quicker?

That's a hack, not a solution (and there are severe limits to how much
incremental time you can save with this approach).
Written material is a far better solution in this situation.

People can process written material at their own chosen speed ...

More importantly, how are all you people accessing YouTube under VMS?

I doubt that any of the very old browsers available for VMS support
the required JavaScript and video format.
But the common PC with Windows/Linux/macOS should be able to do it.

But that's not VMS.... :-)
bill

Well, one could argue that paper and ink are also "not VMS" ...

VMS is the OS ...
Documentation is, well, whatever it is ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Michael Kraemer

2024-08-18 10:05:56 UTC

Post by Dave Froble
Well, one could argue that paper and ink are also "not VMS" ...
VMS is the OS ...
Documentation is, well, whatever it is ...

well, one could argue that a real OS should not depend on another one to
be fully functional.
At least it should be able to present its own documentation.
In this context, paper and ink are agnostic.

Arne Vajhøj

2024-08-18 13:03:37 UTC

Post by Dave Froble
Well, one could argue that paper and ink are also "not VMS" ...
VMS is the OS ...
Documentation is, well, whatever it is ...

well, one could argue that a real OS should not depend on another one to
be fully functional.
At least it should be able to present its own documentation.
In this context, paper and ink are agnostic.

Maybe the concept "OS" is too general here.

I would expect a "client OS" to be able to display
HTML, PDF, video etc..

I would expect a "server OS" to be able to serve
that content to clients.

Arne

Lawrence D'Oliveiro

2024-08-18 21:35:03 UTC

I would expect a "client OS" to be able to display HTML, PDF, video
etc..
I would expect a "server OS" to be able to serve that content to
clients.

What kind of OS is it that has both “client” and “server” capabilities in
one?

We call that a “workstation”.

Arne Vajhøj

2024-08-19 00:30:59 UTC

I would expect a "client OS" to be able to display HTML, PDF, video
etc..
I would expect a "server OS" to be able to serve that content to
clients.

What kind of OS is it that has both “client” and “server” capabilities in
one?
We call that a “workstation”.

I think it would be more accurate to say "We called that a ...".

25-40 years ago there were workstations running VMS, SunOS, Solaris,
HP-UX, AIX, Ultrix, Tru64 etc..

Today a workstations is just a marketing term for a high-end
PC running Windows or Linux.

Arne

Lawrence D'Oliveiro

2024-08-19 00:46:30 UTC

I would expect a "client OS" to be able to display HTML, PDF, video
etc..
I would expect a "server OS" to be able to serve that content to
clients.

What kind of OS is it that has both “client” and “server” capabilities
in one?
We call that a “workstation”.

I think it would be more accurate to say "We called that a ...".
25-40 years ago there were workstations running VMS, SunOS, Solaris,
HP-UX, AIX, Ultrix, Tru64 etc..
Today a workstations is just a marketing term for a high-end PC running
Windows or Linux.

Linux is the one that still offers the full “workstation” capabilities.
Microsoft called their desktop version of NT “Workstation”, but all its
server-like capabilities were carefully crippled to avoid cannibalizing
sales of its actual servers.

Arne Vajhøj

2024-08-19 01:17:00 UTC

Post by Arne VajhÃ¸j
25-40 years ago there were workstations running VMS, SunOS, Solaris,
HP-UX, AIX, Ultrix, Tru64 etc..
Today a workstations is just a marketing term for a high-end PC running
Windows or Linux.

Most (commercial) Linux distros comes with a "server" version and a
"desktop" version.

Redhat has a "workstation" version, but it is really a desktop version.

I don't think there is much difference in how Linux vendors and
Microsoft position server and desktop products.

There probably is a difference in how server applications
act. Some Windows server application will actually require a
Windows server edition. I don't think many Linux server
applications will actually check if it is running on
a server edition or desktop edition of RHEL/SUSE/Ubuntu/whatever.
For many reasons (it would be very non-Linux'ish, it would
be lot of work to maintain a list of all Linux distro editions,
a lot of it is open source so it would be easy to remove a check
and rebuild).

Arne

Lawrence D'Oliveiro

2024-08-19 01:50:24 UTC

Most (commercial) Linux distros comes with a "server" version and a
"desktop" version.

Same software, just choose different packages to install. And you can
change your mind later and just install/remove different packages, without
a reinstall. (Unlike Windows -- see below.)

Post by Arne VajhÃ¸j
I don't think there is much difference in how Linux vendors and
Microsoft position server and desktop products.

Like I said, Microsoft carefully cripples its NT “Workstation” line to
avoid encroaching on “Server” territory. That way it gets to charge a
whole lot more for the latter.

Around the time of NT 3.51, I think it was, somebody discovered that you
could turn the “Workstation” version into the “Server” version just by
editing a Registry key or two. Microsoft plugged that hole in the next
release.

chrisq

2024-08-20 21:56:45 UTC

Post by Dave Froble
Well, one could argue that paper and ink are also "not VMS" ...
VMS is the OS ...
Documentation is, well, whatever it is ...

well, one could argue that a real OS should not depend on another one
to be fully functional.
At least it should be able to present its own documentation.
In this context, paper and ink are agnostic.

Maybe the concept "OS" is too general here.
I would expect a "client OS" to be able to display
HTML, PDF, video etc..
I would expect a "server OS" to be able to serve
that content to clients.
Arne

A properly sorted os should be able to do any of those things,
with the appropriate packages. The os is merely there to provide
services to applications...

Chris

Arne Vajhøj

2024-08-20 22:33:01 UTC

Post by chrisq

Post by Dave Froble
Well, one could argue that paper and ink are also "not VMS" ...
VMS is the OS ...
Documentation is, well, whatever it is ...

well, one could argue that a real OS should not depend on another one
to be fully functional.
At least it should be able to present its own documentation.
In this context, paper and ink are agnostic.

Maybe the concept "OS" is too general here.
I would expect a "client OS" to be able to display
HTML, PDF, video etc..
I would expect a "server OS" to be able to serve
that content to clients.

A properly sorted os should be able to do any of those things,
with the appropriate packages. The os is merely there to provide
services to applications...

True.

But packages does not get ported to an OS by magic - someone
needs to do the work.

VSI see VMS as a server OS and spend money on server stuff
not client stuff.

Given that a large part of the client stuff is open source,
then VMS users could in theory add the client stuff. But
we all know that is not going to happen.

Arne

Simon Clubley

2024-08-19 12:40:01 UTC

Post by Dave Froble
Well, one could argue that paper and ink are also "not VMS" ...
VMS is the OS ...
Documentation is, well, whatever it is ...

well, one could argue that a real OS should not depend on another one to
be fully functional.

That has not been true for VMS since physical terminals were replaced
with terminal emulators.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Michael Kraemer @ home

2024-08-19 16:19:59 UTC

Post by Dave Froble
Well, one could argue that paper and ink are also "not VMS" ...
VMS is the OS ...
Documentation is, well, whatever it is ...

well, one could argue that a real OS should not depend on another one to
be fully functional.

That has not been true for VMS since physical terminals were replaced
with terminal emulators.
Simon.

mmh, no.
VMS was most popular when "everybody" had a VMS workstation on the desktop,
connected to a few VMS servers somewhere in a basement.
No need for a stinking PC anywhere.

babydr DBA James W. Laferriere

2024-08-20 20:07:16 UTC

Hello All ,

Post by Dave Froble
Well, one could argue that paper and ink are also "not VMS" ...
VMS is the OS ...
Documentation is, well, whatever it is ...

well, one could argue that a real OS should not depend on another one to
be fully functional.

That has not been true for VMS since physical terminals were replaced
with terminal emulators.
Simon.

Heck , Even then , the terminals were software driven .
eeproms on some of them & even some of those not promed had ariable
fonts ...

Twyl , JimL

Simon Clubley

2024-08-19 12:31:57 UTC