| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 42 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 01:44:15 |
| Calls: | 220 |
| Calls today: | 1 |
| Files: | 824 |
| Messages: | 121,543 |
| Posted today: | 6 |
Oracle and VMS Software on Application Development and Migration to x86:
https://www.youtube.com/watch?v=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.
On 8/12/2024 10:53 PM, Arne Vajh°j wrote:
Oracle and VMS Software on Application Development and Migration to x86:
https://www.youtube.com/watch?v=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 ...
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.
On 2024-08-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/12/2024 10:53 PM, Arne Vajhøj wrote:
Oracle and VMS Software on Application Development and Migration to x86: >>>
https://www.youtube.com/watch?v=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 ...
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. :-)
On 8/14/2024 2:07 PM, Robert A. Brooks wrote:
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
On 8/14/2024 1:48 PM, Simon Clubley wrote:
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.
On 8/14/2024 2:33 PM, Arne Vajhøj wrote:
And it has different size of long and pointers. Causing problems
for two cases:
* 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.
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++
compile/POINTER_SIZE=32, LINK/SEG=CODE=P0 etc. can all help get stuff working.
But it is not the right long term solution.
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++
On 8/14/2024 2:57 PM, Arne Vajhøj wrote:
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.
On 8/14/2024 2:33 PM, Arne Vajhøj wrote:
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++
And in case someone has not seen it:
$ type long.h
On Wed, 14 Aug 2024 14:33:27 -0400, Arne Vajhøj wrote:
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 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
And it has different size of long and pointers.
On Wed, 14 Aug 2024 19:58:30 -0400, Arne Vajhøj wrote:
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
This is why you have stdint.h.
default sizeof pointer C++ x64 <> default sizeof pointer C x64
Interesting ... is C++ always supposed to be ABI-compatible with C?
On 8/14/2024 2:57 PM, Arne Vajh°j wrote:
compile/POINTER_SIZE=32, LINK/SEG=CODE=P0 etc. can all help get stuff working.For C++, the default pointer size should have remained 32.
But it is not the right long term solution.
It was a mistake to change the default from what it was on Alpha and IA64.
On 8/14/2024 2:33 PM, Arne Vajh°j wrote:
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++
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
On 2024-08-14 19:49:28 +0000, Robert A. Brooks said:
On 8/14/2024 2:57 PM, Arne Vajhøj wrote:
compile/POINTER_SIZE=32, LINK/SEG=CODE=P0 etc. can all help get stuffFor C++, the default pointer size should have remained 32.
working.
But it is not the right long term solution.
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.
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.
On 8/20/2024 1:38 PM, Simon Clubley wrote:
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.
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.
On Tue, 20 Aug 2024 09:47:36 -0400, Arne Vajhøj wrote:
Few languages support multiple return values.
Even in C and Fortran, a function can return a struct.
On 2024-08-20, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/20/2024 1:38 PM, Simon Clubley wrote:
After all, why miss the opportunity to have two parallel sets of APIsBecause InputStream/OutputStream and Reader/Writer are fundamentally
(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... >>
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.
On 8/21/24 02:25, Lawrence D'Oliveiro wrote:
On Tue, 20 Aug 2024 09:47:36 -0400, Arne Vajhøj wrote:
Few languages support multiple return values.
Even in C and Fortran, a function can return a struct.
Better to declare the struct externally, then pass a pointer
to it. Much tidier.
On 8/21/2024 8:26 AM, chrisq wrote:
On 8/21/24 02:25, Lawrence D'Oliveiro wrote:
On Tue, 20 Aug 2024 09:47:36 -0400, Arne Vajhøj wrote:
Few languages support multiple return values.
Even in C and Fortran, a function can return a struct.
Better to declare the struct externally, then pass a pointer
to it. Much tidier.
In C one should definitely return a pointer to struct and not
a struct.
It looks like VSI Fortran cannot return a structure as function
result, but VSI Pascal can return a record as function result.
And it is returned as a pointer argument under the hood.
On 8/21/24 02:25, Lawrence D'Oliveiro wrote:
On Tue, 20 Aug 2024 09:47:36 -0400, Arne Vajhøj wrote:
Few languages support multiple return values.
Even in C and Fortran, a function can return a struct.
Better to declare the struct externally, then pass a pointer to it. Much tidier.
On 8/21/2024 8:26 AM, chrisq wrote:
On 8/21/24 02:25, Lawrence D'Oliveiro wrote:
On Tue, 20 Aug 2024 09:47:36 -0400, Arne Vajhøj wrote:
Few languages support multiple return values.
Even in C and Fortran, a function can return a struct.
Better to declare the struct externally, then pass a pointer
to it. Much tidier.
In C one should definitely return a pointer to struct and not
a struct.
It looks like VSI Fortran cannot return a structure as function
result, but VSI Pascal can return a record as function result.
And it is returned as a pointer argument under the hood.
$ type s.pas
module s;
type
iiituple = record
a : integer;
b : integer;
c : integer;
end;
[global]
function get : iiituple;
void get(struct iiituple *res);
int main()
{
struct iiituple res;
get(&res);
On 2024-08-20, chrisq <devzero@nospam.com> wrote:
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.
On 8/20/2024 9:25 PM, Lawrence D'Oliveiro wrote:
On Tue, 20 Aug 2024 09:47:36 -0400, Arne Vajhøj wrote:
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
On Tue, 20 Aug 2024 21:35:44 -0400, Arne Vajhøj wrote:
On 8/20/2024 9:25 PM, Lawrence D'Oliveiro wrote:
On Tue, 20 Aug 2024 09:47:36 -0400, Arne Vajhøj wrote:
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")
On 8/20/2024 8:36 AM, Simon Clubley wrote:
On 2024-08-20, chrisq <devzero@nospam.com> wrote:
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.
And probably much harder to understand in anything but the most
trivial usage.
bill
On 8/20/2024 9:35 PM, Arne Vajhøj wrote:
On 8/20/2024 9:25 PM, Lawrence D'Oliveiro wrote:
On Tue, 20 Aug 2024 09:47:36 -0400, Arne Vajhøj wrote:
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.
Hmmm ... what is wrong with a "custom type", or what I'd call a structure?
On 2024-08-20, bill <bill.gunshannon@gmail.com> wrote:
On 8/20/2024 8:36 AM, Simon Clubley wrote:
On 2024-08-20, chrisq <devzero@nospam.com> wrote:
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.
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 ? :-)
On 8/20/2024 1:47 PM, Simon Clubley wrote:
$ set response/mode=good_natured
Or are associative arrays and other higher-level data structures an alien
concept to you ? :-)
Uh ... sometimes ...
:-)
Perl actually has a vast range of builtins.
Python is actually a fairly small language. Its core language spec
is less than 20% the size of the core Java language spec.
The Python spec only lists 35 keywords <https://docs.python.org/3/reference/lexical_analysis.html#keywords>
. Is that a lot to you?
You never had functions and classes as first-class objects in BASIC
or COBOL; you do in Python. You never had metaclasses in those
languages; you do in Python. You never had custom operator
overloads in those languages; you do in Python.
In article <valhi8$34s18$4@dont-email.me>, ldo@nz.invalid (Lawrence D'Oliveiro) wrote:
Perl actually has a vast range of builtins.
True, but they are at least all in one list. The problem I've had with
Python is finding what the word is to do a thing.
Python is actually a fairly small language. Its core language spec is
less than 20% the size of the core Java language spec.
This does not really help your case: Java is another example of an
overblown language.
The file handling library functions are a prime
example. The list rapidly grows larger than the Perl builtins, and is
less well organised.
You never had functions and classes as first-class objects in BASIC or
COBOL; you do in Python. You never had metaclasses in those languages;
you do in Python. You never had custom operator overloads in those
languages; you do in Python.
You've missed my point. BASIC and COBOL are languages where you have to
learn specific words to do specific things; Python has that in common
with them.
Several younger people at work came to us as determined advocates of
Python. They're written some useful tools in it, but the core of the development environment remains Perl.
On 8/14/2024 2:33 PM, Arne Vajh°j wrote:
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++
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?
In article <v9iro6$fql6$1@dont-email.me>, FIRST.LAST@vmssoftware.com
(Robert A. Brooks) wrote:
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.
On 8/15/2024 4:41 AM, John Dallman wrote:
In article <v9iro6$fql6$1@dont-email.me>, FIRST.LAST@vmssoftware.com
(Robert A. Brooks) wrote:
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.
Why do I think of:
VAX C 3.x -> DEC C 4.x -> DEC C 5.x
back in the 90's?
:-)
On 2024-08-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/14/2024 2:33 PM, Arne Vajhøj wrote:
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++
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.
On 2024-08-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/14/2024 2:33 PM, Arne Vajhøj wrote:
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++
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.
However, since you ask, I prefer a writeup rather than a 40 minute
video for this kind of update ...
I 100% agree.
On 8/20/2024 1:34 PM, bill wrote:
On 8/20/2024 8:36 AM, Simon Clubley wrote:
On 2024-08-20, chrisq <devzero@nospam.com> wrote:
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.
And probably much harder to understand in anything but the most
trivial usage.
Would that not be rather clear with adequate comments about what is being done?
On 8/20/2024 8:36 AM, Simon Clubley wrote:
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.
Is there any real difference between your practice, and including a completion
status parameter in the function call?
On 2024-08-21, Dave Froble <davef@tsoft-inc.com> wrote:
On 8/20/2024 1:34 PM, bill wrote:
On 8/20/2024 8:36 AM, Simon Clubley wrote:
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.
Would that not be rather clear with adequate comments about what is being done?
Look at the example Arne posted. Very clean and very easy to understand without having to use comments (and I am actually a fan of the liberal
use of comments. :-) ).
On 8/21/2024 8:26 AM, chrisq wrote:
On 8/21/24 02:25, Lawrence D'Oliveiro wrote:
On Tue, 20 Aug 2024 09:47:36 -0400, Arne Vajhøj wrote:
Few languages support multiple return values.
Even in C and Fortran, a function can return a struct.
Better to declare the struct externally, then pass a pointer
to it. Much tidier.
In C one should definitely return a pointer to struct and not
a struct.
It looks like VSI Fortran cannot return a structure as function
result, but VSI Pascal can return a record as function result.
And it is returned as a pointer argument under the hood.
$ type s.pas
module s;
type
iiituple = record
a : integer;
b : integer;
c : integer;
end;
[global]
function get : iiituple;
var
res : iiituple;
begin
res.a := 123;
res.b := 456;
res.c := 789;
get := res;
end;
end.
$ pas s
$ type m.c
#include <stdio.h>
struct iiituple
{
int a;
int b;
int c;
};
void get(struct iiituple *res);
int main()
{
struct iiituple res;
get(&res);
printf("%d %d %d\n", res.a, res.b, res.c);
return 0;
}
$ cc m
$ link m + s
$ run m
123 456 789
Arne
On 8/21/24 19:13, Arne Vajhøj wrote:
On 8/21/2024 8:26 AM, chrisq wrote:
On 8/21/24 02:25, Lawrence D'Oliveiro wrote:
On Tue, 20 Aug 2024 09:47:36 -0400, Arne Vajhøj wrote:
Few languages support multiple return values.
Even in C and Fortran, a function can return a struct.
Better to declare the struct externally, then pass a pointer
to it. Much tidier.
In C one should definitely return a pointer to struct and not
Problem is that of you return a pointer, that suggests that the
struct has been declared static inside the called function. That
would be a fail for reentant code that might be called from
elsewhere, say, from an interrupt handler, or another thread.
The struct would typically be on the stack or heap, and would
disappear on return from the call, making the return value
invalid. Ideally, in a multitasking os, all code should be
designed to be fully reentrant, to make it safe in all
situations.
Problem is that of you return a pointer, that suggests that the struct
has been declared static inside the called function. That would be a
fail for reentant code that might be called from elsewhere, say, from an interrupt handler, or another thread. The struct would typically be on
the stack or heap, and would disappear on return from the call, making
the return value invalid. Ideally, in a multitasking os, all code should
be designed to be fully reentrant, to make it safe in all situations.
On 2024-08-21, Dave Froble <davef@tsoft-inc.com> wrote:
On 8/20/2024 1:34 PM, bill wrote:
On 8/20/2024 8:36 AM, Simon Clubley wrote:
On 2024-08-20, chrisq <devzero@nospam.com> wrote:
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.
And probably much harder to understand in anything but the most
trivial usage.
Would that not be rather clear with adequate comments about what is being done?
Look at the example Arne posted. Very clean and very easy to understand without having to use comments (and I am actually a fan of the liberal
use of comments. :-) ).
Simon.
On 8/22/2024 7:12 PM, chrisq wrote:
On 8/21/24 19:13, Arne Vajh°j wrote:
On 8/21/2024 8:26 AM, chrisq wrote:
On 8/21/24 02:25, Lawrence D'Oliveiro wrote:
On Tue, 20 Aug 2024 09:47:36 -0400, Arne Vajh°j wrote:
Few languages support multiple return values.
Even in C and Fortran, a function can return a struct.
Better to declare the struct externally, then pass a pointer
to it. Much tidier.
In C one should definitely return a pointer to struct and not
Problem is that of you return a pointer, that suggests that the
struct has been declared static inside the called function. That
would be a fail for reentant code that might be called from
elsewhere, say, from an interrupt handler, or another thread.
The struct wouldá typically be on the stack or heap, and would
disappear on return from the call, making the return value
invalid. Ideally, in a multitasking os, all code should be
designed to be fully reentrant, to make it safe in all
situations.
My assumption would be that the struct was malloc'ed in
the function.
That obvious also has its problem. One can write in
72 point bold red blinking font that it is the callers
responsibility to call free and it will still be
forgotten in some cases.
Arne
On Wed, 28 Aug 2024 16:35 +0100 (BST), John Dallman wrote:
In article <valhi8$34s18$4@dont-email.me>, ldo@nz.invalid (Lawrence
D'Oliveiro) wrote:
Perl actually has a vast range of builtins.
True, but they are at least all in one list. The problem I've had with
Python is finding what the word is to do a thing.
I’m not sure I understand that. Python does things by “constructs” rather
than individual “words”. Do you mean function and class names?
On 8/28/24 8:49 PM, Lawrence D'Oliveiro wrote:
On Wed, 28 Aug 2024 16:35 +0100 (BST), John Dallman wrote:
In article <valhi8$34s18$4@dont-email.me>, ldo@nz.invalid (Lawrence
D'Oliveiro) wrote:
Perl actually has a vast range of builtins.
True, but they are at least all in one list. The problem I've had with
Python is finding what the word is to do a thing.
I’m not sure I understand that. Python does things by “constructs” rather
than individual “words”. Do you mean function and class names?
The extra things you import if you don't have a builtin that does what
you want are called modules in both Perl and Python. As far as I can
tell he's just saying that with Perl, the operations he uses most (e.g.
I/O and regular expressions) are already there as builtins and there are
no "use" statements necessary to import modules to do those things.
There are 150+ modules that ship with Perl and thousands more on CPAN,
and you do need some of them to do some things. But John is right; Perl
is quite a capable language, sort of an awk on steroids, without those things.
Python also ships with a ton of modules and has many more available via pip. But it has moved in the direction of fewer builtins and needing modules to do pretty much anything. I think Python 2 had an "open"
builtin but in Python 3 you have to "import io" and use "io.open." I'm
sure I will get a lecture on all the computer sciency reasons that's a superior way of doing things. But for someone trying to get work done,
having the tools you use most already out on the workbench without
having to remember which tool chest they're in can be an advantage.
Python also ships with a ton of modules and has many more available via
pip. But it has moved in the direction of fewer builtins and needing
modules to do pretty much anything. I think Python 2 had an "open"
builtin but in Python 3 you have to "import io" and use "io.open."
On Wed, 14 Aug 2024 14:07:31 -0400, Arne Vajh°j wrote:
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?
On 8/14/24 7:35 PM, Stephen Hoffman wrote:
On 2024-08-14 19:49:28 +0000, Robert A. Brooks said:
On 8/14/2024 2:57 PM, Arne Vajh°j wrote:It was a mistake to use 32 and not 64 on Alpha and Itanium, but that
compile/POINTER_SIZE=32, LINK/SEG=CODE=P0 etc. can all help get stuff working.á For C++, the default pointer size should have remained 32.
But it is not the right long term solution.
It was a mistake to change the default from what it was on Alpha and IA64. >>
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.
On 2024-08-15, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Wed, 14 Aug 2024 14:07:31 -0400, Arne Vajhøj wrote:
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.
On 8/16/2024 1:16 PM, Dave Froble wrote:
On 8/16/2024 8:07 AM, Simon Clubley wrote:
On 2024-08-15, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Wed, 14 Aug 2024 14:07:31 -0400, Arne Vajhøj wrote:
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?
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.
In article <v9j1o8$fql6$3@dont-email.me>, FIRST.LAST@vmssoftware.com
(Robert A. Brooks) wrote:
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?
My guess would be that most C++ open source comes from the Linux world
and is mostly tested with 64 bit pointers.
Yes, that means dragging some apps forward. And dragging systen APIs forward.
In article <v9j1o8$fql6$3@dont-email.me>, FIRST.LAST@vmssoftware.com
(Robert A. Brooks) wrote:
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?
On Fri, 16 Aug 2024 12:11:16 -0400, Stephen Hoffman wrote:
Yes, that means dragging some apps forward. And dragging systen APIs
forward.
Reinventing POSIX?
On 8/16/24 8:06 PM, Lawrence D'Oliveiro wrote:
On Fri, 16 Aug 2024 12:11:16 -0400, Stephen Hoffman wrote:
Yes, that means dragging some apps forward. And dragging systen APIs
forward.
Reinventing POSIX?
POSIX is just an API.
On Thu, 22 Aug 2024 19:21:07 -0400
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/22/2024 7:12 PM, chrisq wrote:
On 8/21/24 19:13, Arne Vajhøj wrote:
On 8/21/2024 8:26 AM, chrisq wrote:
On 8/21/24 02:25, Lawrence D'Oliveiro wrote:
On Tue, 20 Aug 2024 09:47:36 -0400, Arne Vajhøj wrote:
Few languages support multiple return values.
Even in C and Fortran, a function can return a struct.
Better to declare the struct externally, then pass a pointer
to it. Much tidier.
In C one should definitely return a pointer to struct and not
Problem is that of you return a pointer, that suggests that the
struct has been declared static inside the called function. That
would be a fail for reentant code that might be called from
elsewhere, say, from an interrupt handler, or another thread.
The struct would typically be on the stack or heap, and would
disappear on return from the call, making the return value
invalid. Ideally, in a multitasking os, all code should be
designed to be fully reentrant, to make it safe in all
situations.
My assumption would be that the struct was malloc'ed in
the function.
That obvious also has its problem. One can write in
72 point bold red blinking font that it is the callers
responsibility to call free and it will still be
forgotten in some cases.
Just admit that you was wrong
and that the best option in C is the same
as in many other languages - return the structure itself.
On 2024-08-19, Arne Vajh°j <arne@vajhoej.dk> wrote:
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...
On 8/23/2024 4:14 AM, Michael S wrote:
and that the best option in C is the same
as in many other languages - return the structure itself.
Returning the struct itself result in a copy of the struct. The
time to do the copy is probably insignificant though.
I am not quite convinced yet.
On 2024-08-20 12:04:13 +0000, Simon Clubley said:
On 2024-08-19, Arne Vajhøj <arne@vajhoej.dk> wrote:
Of course, that is what ABIs are _supposed_ to be for...
Or if the application is passing pointers between code compiled with
different languages/compilers/compiler settings.
Or Swift and C/C++, or Zig and C/C++, which are intended to
interoperate.