Mailing List Archive

On Mon, 28 Sep 2020 14:41:01 -0600, Karl Williamson
<public@khwilliamson.com> wrote:

> We had a discussion a while back on whether we should move away from
> supporting pure C89 compilers. We had made workarounds for some
> things in C99 not in C89. Such as we have Ptrdiff_t that emulates
> that type on systems where it isn't native, and we have various
> numeric limits that are in C99 but not C89.
>
> Since that discussion, I'm finding more things in C99 that would be
> nice to have. And I have found some things where we already are in
> violation of strict C89, without complaints from the field
>
> A compiler is not required to support infinite numbers of values in
> an enum or cases in a switch, or the number of macros you can define.
> C89 says that a compiler needs to support at least 127, 257, and
> 1024 respectively. C99 raises those to 1023, 1023, 4095
> respectively. Other limits are similarly increased. (5.2.4.1)
>
> It turns out that we already are in violation of the C89 number of
> enums, and my guess, macros too. That means perl is not being used
> on systems with these bare minimums. I would like to increase the
> number of cases in some switches to beyond the C89 required minimum.
> This would make some hot code cleaner, and with fewer conditionals.
>
> C99 also allows you to have a variable length array at the end of a
> struct declared as foo[]. (called flexible array members.) C89
> works if it is foo[1], but it makes sizeof harder.
>
> There are other features that C99 offers that would be useful.
>
> My question is can we start using some C99 features beyond what we
> already have without running afoul of compilers we work on today?
>
> If so what features are feasible? I am particularly concerned about
> using more cases in a switch. Can we relax that C89 constraint?
>
> What C89 things are we stuck with? (I'm guessing we can't assume 754
> floating point)?
>
> Can we use other C99 enhancements, like
>
> Flexible array members?

I doubt it

> Intermixed declarations and code?

No. I think the HP C-ANSI-C implementation of the C99 mode still do not
allow this.

> Variadic macros?

I don't know

> // comments?

I'd recommend against that. I see no added value at all. Consistency,
even in comments, is a good thing.

> restrict keyword? (though we could just define this to be nothing if
> not already available)

I don't know

> Others?

As I had to power-off the HP-UX 11.23, that compiler is now
unavailable. I powered the HP-UX 11.31 on instead, so that might give
you an idea of how recent(er) C-ANSI-C HP-UX compilers behave.

I also have the oldish AIX available, and that xlc compiler is
relatively strict.

I could also drive to the building to power-off the 11.31 and start up
the 11.11, which has the oldest available compiler

--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.33 porting perl5 on HP-UX, AIX, and Linux
https://useplaintext.email https://www.test-smoke.org
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

On Mon, Sep 28, 2020 at 3:41 PM Karl Williamson <public@khwilliamson.com> wrote:

> My question is can we start using some C99 features beyond what we
> already have without running afoul of compilers we work on today?
>
> If so what features are feasible? I am particularly concerned about
> using more cases in a switch. Can we relax that C89 constraint?

I doubt anyone building Perl knows the answers to all your specific
questions, though obviously if anyone aware of a compiler in current
use where -std means c89 should speak up.

But the overall question is certainly a reasonable one to raise 20+
years after the C99 standard came along. A different way of asking
might be to figure out how long after 1989 was K & R support dropped,
in case precedent helps set the boundaries for what we should do to
make old systems able to build current Perl.

My suggestion would be to pick your favorite switch statement, add
more branches to it in a smoke-me branch, and merge to blead if no one
complains. Lather, rinse, repeat with other features at a moderate
pace and see what turns up. I would also recommend choosing features
piece-meal where the value is high. Comments starting with "//" do
not have high value because the alternative is trivial. But some of
the other features you mention do sound like things that could help
with maintainability.

On 2020-09-29 3:45 p.m., Craig A. Berry wrote:
> Comments starting with "//" do
> not have high value because the alternative is trivial.

I would also argue against "//" comments because the "/* */" form is invariant
to linebreaks like most of the rest of the code, rather than being a special
exception, so substituting linebreaks from or to any other kind of whitespace
doesn't change the meaning of the code (outside of string literals).

Also, good code design is that comments are always on their own lines rather
than being at the ends of code lines, regardless of whether "//" style is used
or not, eg, put the comment for a line just above that line.

-- Darren Duncan

Four of five years ago my team at Booking.com needed to wrap some C99 code.
Of course we knew that it would be fine for our own use in our own
environment, yet we had some concerns about whether or not it would work
well for everyone else.

Cpan Testers may not represent all important platforms, so take this with a
grain of salt, but these tiny modules gave us confidence that the two
elements of C99 that the code we wrapped used (Flexible array members and
Intermixed declarations and code) would likely be acceptable to use
generally:

* http://www.cpantesters.org/distro/D/Devel-CCompat-C99-ScopedVariables.html
*
http://www.cpantesters.org/distro/D/Devel-CCompat-C99-VariableLengthArrays.html

I find that some elements of modern C, especially struct initialization,
much nicer to work with.

That said, it is certainly wise to avoid parts of C99 made optional in C11:

https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29#Optional_features

Cheers,
-Eric


On Wed, 30 Sep 2020 at 14:47, Karl Williamson <public@khwilliamson.com>
wrote:

> We had a discussion a while back on whether we should move away from
> supporting pure C89 compilers. We had made workarounds for some things
> in C99 not in C89. Such as we have Ptrdiff_t that emulates that type on
> systems where it isn't native, and we have various numeric limits that
> are in C99 but not C89.
>
> Since that discussion, I'm finding more things in C99 that would be nice
> to have. And I have found some things where we already are in violation
> of strict C89, without complaints from the field
>
> A compiler is not required to support infinite numbers of values in an
> enum or cases in a switch, or the number of macros you can define. C89
> says that a compiler needs to support at least 127, 257, and 1024
> respectively. C99 raises those to 1023, 1023, 4095 respectively. Other
> limits are similarly increased. (5.2.4.1)
>
> It turns out that we already are in violation of the C89 number of
> enums, and my guess, macros too. That means perl is not being used on
> systems with these bare minimums. I would like to increase the number
> of cases in some switches to beyond the C89 required minimum. This
> would make some hot code cleaner, and with fewer conditionals.
>
> C99 also allows you to have a variable length array at the end of a
> struct declared as foo[]. (called flexible array members.) C89 works
> if it is foo[1], but it makes sizeof harder.
>
> There are other features that C99 offers that would be useful.
>
> My question is can we start using some C99 features beyond what we
> already have without running afoul of compilers we work on today?
>
> If so what features are feasible? I am particularly concerned about
> using more cases in a switch. Can we relax that C89 constraint?
>
> What C89 things are we stuck with? (I'm guessing we can't assume 754
> floating point)?
>
> Can we use other C99 enhancements, like
>
> Flexible array members?
>
> Intermixed declarations and code?
>
> Variadic macros?
>
> // comments?
>
> restrict keyword? (though we could just define this to be nothing if
> not already available)
>
> Others?
>

On Wed, Sep 30, 2020 at 3:04 PM Eric Herman <eric.herman@gmail.com> wrote:
>
>
> Four of five years ago my team at Booking.com needed to wrap some C99 code. Of course we knew that it would be fine for our own use in our own environment, yet we had some concerns about whether or not it would work well for everyone else.
>
> Cpan Testers may not represent all important platforms, so take this with a grain of salt, but these tiny modules gave us confidence that the two elements of C99 that the code we wrapped used (Flexible array members and Intermixed declarations and code) would likely be acceptable to use generally:
>
> * http://www.cpantesters.org/distro/D/Devel-CCompat-C99-ScopedVariables.html
> * http://www.cpantesters.org/distro/D/Devel-CCompat-C99-VariableLengthArrays.html
>
> I find that some elements of modern C, especially struct initialization, much nicer to work with.
>
> That said, it is certainly wise to avoid parts of C99 made optional in C11:
>
> https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29#Optional_features

Agreed. Most of C99 is widely supported, but a few pieces aren't.
Fortunately for us, the things we want the most are most widely
supported because everyone wants things like mixed declarations and
variable length arrays.

That does mean we should probably specify more specifically than we do
now what we depend on and what not.


Leon

> Can we use other C99 enhancements, like
>
> Flexible array members?
>
> Intermixed declarations and code?
>
> Variadic macros?
>
> // comments?
>
> restrict keyword? (though we could just define this to be nothing if
> not already available)
>
> Others?
>

As mentioned on irc, I should send link here: quick googling provided
https://github.com/libav/c99-to-c89

I didn't use neither investigate it, just opening alternative to develop
using C99 (or even newer) and "release" downgraded sources (as well)

On Tue, Sep 29, 2020 at 04:08:20PM +0200, H.Merijn Brand wrote:
> On Mon, 28 Sep 2020 14:41:01 -0600, Karl Williamson
> <public@khwilliamson.com> wrote:

> > C99 also allows you to have a variable length array at the end of a
> > struct declared as foo[]. (called flexible array members.) C89
> > works if it is foo[1], but it makes sizeof harder.

But, IIRC not inside a union. This might not matter to us.

(There was a specific case in some work code where I had to back to relying
on gcc-isms because of unions. This is fine for the work code.)

> > There are other features that C99 offers that would be useful.
> >
> > My question is can we start using some C99 features beyond what we
> > already have without running afoul of compilers we work on today?

IIRC even getting bool to work was a right pain, because we hit some
C compiler bugs with casting pointers to bools.

We have suitably working (possibly faked up) bool and static inline.

> > If so what features are feasible? I am particularly concerned about
> > using more cases in a switch. Can we relax that C89 constraint?
> >
> > What C89 things are we stuck with? (I'm guessing we can't assume 754
> > floating point)?

Not all the world is(n't) a VAX :-)

I was trying to think of things that I knew that had strange floating point.
IRIX long doubles probably don't matter any more as IRIX is properly dead.
No idea what K series Crays did with floating point - their integer divide
was more part of the fun.
Some systems VMS ran on, but again, long gone?

I'm sure we did encounter some system that was capable of returning
positive NaNs and negative NaNs. (To my mind, this is insane. It's clearly
not Not-a-Number enough if it still has a sign)

BUT

Don't some IBM mainframes use base 16 floating point?

> > Can we use other C99 enhancements, like
> >
> > Flexible array members?
>
> I doubt it
>
> > Intermixed declarations and code?
>
> No. I think the HP C-ANSI-C implementation of the C99 mode still do not
> allow this.

If so, that's really $*&%ing annoying, because they are one of the most
useful things
(limiting scope of declarations, and now being able to make them const
because they happen after code that calculates the value)

*and*

inappropriate laziness from the compiler implementer, because the compiler
*internals* must be able to do it, because (as I understand it) a
declaration in the middle of code is equivalent to starting a new block at
that point, and C89 compilers support blocks in blocks in blocks...

> > Variadic macros?
>
> I don't know

When did these reach C++?

> > Others?

To quote ilmari:

designated struct initialisers
i.e. struct foo bar = { .baz = 42, .bat = 37 };


those and inline variable declarations, those are the two things that I'd
like.


BUT

C++ didn't get designated struct initialisers until far too recently, so we
can't put them in any header files, else we'd prevent C++ XS extensions from
compiling.

So if we use them, we'd likely need to figure out some kind of portability
test to make sure that headers didn't have them. Until now, our portability
test as been to build the entire core source with a C++ compiler.

Nicholas Clark

On Thu, 1 Oct 2020 10:00:44 +0100, Nicholas Clark <nick@ccl4.org> wrote:

> > > Intermixed declarations and code?
> >
> > No. I think the HP C-ANSI-C implementation of the C99 mode still do
> > not allow this.
>
> If so, that's really $*&%ing annoying, because they are one of the
> most useful things
> (limiting scope of declarations, and now being able to make them const
> because they happen after code that calculates the value)
>
> *and*
>
> inappropriate laziness from the compiler implementer, because the
> compiler *internals* must be able to do it, because (as I understand
> it) a declaration in the middle of code is equivalent to starting a
> new block at that point, and C89 compilers support blocks in blocks
> in blocks...

Reasons might be out of control:

• License expired, so no (free) compiler updates available
• Early C99 implementation was not complete
• Early implementation was buggy
• OS lifetime expired, no compiler updates available
• …

For HP-UX, that adds a new "problem", as newer GNU gcc cannot be built.
(Even the porting center gave up).

Last time I tried, I noticed that GNU gcc cannot be built in 64bit mode
due to assembler problems, and cannot be built in 32bit mode, because
the new memory usage exceeds the 32bit range, so you are in a deadlock

Add to that, that gcc now depends on gmp, mpfr, and mpc, and your
changes get close to zero to build a recent GNU gcc.

So, to support HP-UX, you will have to live with either HP C-ANSI-C
with probable incomplete C99 (and different options for different
releases of their compiler - yeah!) or with an old version of gcc.

On 11.31 I have gcc-4.7.2 as most recent *working* version

If you have a testcase that shows your requirements per C99 wished
feature, I can compile and show the results (but so can anyone that
has an account on that box. I you want one, mail me)


FWIW this completely stupid test program compiles and runs fine on
HP-UX 11.31 using C-ANSI-C without passing *any* options at all, but
that gives no guarantee it'll work on older HP compilers.

$ cat test.c
#include <stdio.h>

int main (int argc, char *argv[]) {

int i = 0; /* I = 0 */

(void)printf ("I just set i to %d\n", i);

int j = 1; // J = 1

(void)printf ("I just set j to %d\n", j);
return (0);
} /* main */

$ cc -o x test.c

$ ./x
I just set i to 0
I just set j to 1

--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.33 porting perl5 on HP-UX, AIX, and Linux
https://useplaintext.email https://www.test-smoke.org
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

On Thu, Oct 01, 2020 at 12:51:04PM +0200, H.Merijn Brand wrote:
> On Thu, 1 Oct 2020 10:00:44 +0100, Nicholas Clark <nick@ccl4.org> wrote:
>
> > > > Intermixed declarations and code?
> > >
> > > No. I think the HP C-ANSI-C implementation of the C99 mode still do
> > > not allow this.
> >
> > If so, that's really $*&%ing annoying, because they are one of the
> > most useful things
> > (limiting scope of declarations, and now being able to make them const
> > because they happen after code that calculates the value)
> >
> > *and*
> >
> > inappropriate laziness from the compiler implementer, because the
> > compiler *internals* must be able to do it, because (as I understand
> > it) a declaration in the middle of code is equivalent to starting a
> > new block at that point, and C89 compilers support blocks in blocks
> > in blocks...
>
> Reasons might be out of control:
>
> • License expired, so no (free) compiler updates available
> • Early C99 implementation was not complete
> • Early implementation was buggy
> • OS lifetime expired, no compiler updates available
> • …

Agree, but that wasn't what I meant with my grumble. It was that that
specific C99 feature, unlike most of them done not require any change to
the compiler internals after the parser, because it is equivalent to adding
" { " and " } " to the pre-processed source code stream

(at the correct points - and figuring out those correct points *does*
require a parser, not just a pre-processor - hence there is some work)

> For HP-UX, that adds a new "problem", as newer GNU gcc cannot be built.
> (Even the porting center gave up).

Oh my. Suggesting that for them, even "building an older gcc, then using
that to build a newer gcc" wasn't going to work...


> If you have a testcase that shows your requirements per C99 wished
> feature, I can compile and show the results (but so can anyone that
> has an account on that box. I you want one, mail me)

Your test case is excellent. It is pretty much the one feature I'd really
like - declarations mixed with code:

> #include <stdio.h>
>
> int main (int argc, char *argv[]) {
>
> int i = 0; /* I = 0 */
>
> (void)printf ("I just set i to %d\n", i);
>
> int j = 1; // J = 1
>
> (void)printf ("I just set j to %d\n", j);
> return (0);
> } /* main */

but I'd hope that the compiler is equally happy if you added const:

const int j = 1; // J = 1


(struct inititialisers would be nice, but as we can't use them in headers
thanks to older C++, they aren't as useful)

Nicholas Clark

On Thu, 1 Oct 2020 13:07:15 +0100, Nicholas Clark <nick@ccl4.org> wrote:

> On Thu, Oct 01, 2020 at 12:51:04PM +0200, H.Merijn Brand wrote:
> > On Thu, 1 Oct 2020 10:00:44 +0100, Nicholas Clark <nick@ccl4.org>
> > wrote:
> [...]
> [...]
> > >
> > > If so, that's really $*&%ing annoying, because they are one of the
> > > most useful things
> > > (limiting scope of declarations, and now being able to make them
> > > const because they happen after code that calculates the value)
> > >
> > > *and*
> > >
> > > inappropriate laziness from the compiler implementer, because the
> > > compiler *internals* must be able to do it, because (as I
> > > understand it) a declaration in the middle of code is equivalent
> > > to starting a new block at that point, and C89 compilers support
> > > blocks in blocks in blocks...
> >
> > Reasons might be out of control:
> >
> > • License expired, so no (free) compiler updates available
> > • Early C99 implementation was not complete
> > • Early implementation was buggy
> > • OS lifetime expired, no compiler updates available
> > • …
>
> Agree, but that wasn't what I meant with my grumble. It was that that
> specific C99 feature, unlike most of them done not require any change
> to the compiler internals after the parser, because it is equivalent
> to adding " { " and " } " to the pre-processed source code stream

Including the '{' on the correct position is easy. Determining the
position of '}' is harder (but doable).

> (at the correct points - and figuring out those correct points *does*
> require a parser, not just a pre-processor - hence there is some work)
>
> > For HP-UX, that adds a new "problem", as newer GNU gcc cannot be
> > built. (Even the porting center gave up).
>
> Oh my. Suggesting that for them, even "building an older gcc, then
> using that to build a newer gcc" wasn't going to work...

That was the path I tried, even in small increments, but alas.
Last few attempts were on 11.23, so I might go into that masochistic
process on 11.31 if I really feel bored.

> > If you have a testcase that shows your requirements per C99 wished
> > feature, I can compile and show the results (but so can anyone that
> > has an account on that box. I you want one, mail me)
>
> Your test case is excellent.

Thank you

> It is pretty much the one feature I'd really like - declarations
> mixed with code:
>
> > #include <stdio.h>
> >
> > int main (int argc, char *argv[]) {
> >
> > int i = 0; /* I = 0 */
> >
> > (void)printf ("I just set i to %d\n", i);
> >
> > int j = 1; // J = 1
> >
> > (void)printf ("I just set j to %d\n", j);
> > return (0);
> > } /* main */
>
> but I'd hope that the compiler is equally happy if you added const:
>
> const int j = 1; // J = 1

On HP-UX 11.31 with cc: HP C/aC++ B3910B A.06.28.02 [Mar 09 2016]
that is no problem.

> (struct inititialisers would be nice, but as we can't use them in
> headers thanks to older C++, they aren't as useful)

Do you have an example of the most complicated initializer you thing we
would want to support?

> Nicholas Clark

--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.33 porting perl5 on HP-UX, AIX, and Linux
https://useplaintext.email https://www.test-smoke.org
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

On Thu, Oct 1, 2020 at 4:43 AM Nicholas Clark <nick@ccl4.org> wrote:
>
> On Tue, Sep 29, 2020 at 04:08:20PM +0200, H.Merijn Brand wrote:
> > On Mon, 28 Sep 2020 14:41:01 -0600, Karl Williamson
> > <public@khwilliamson.com> wrote:

> > > What C89 things are we stuck with? (I'm guessing we can't assume 754
> > > floating point)?
>
> Not all the world is(n't) a VAX :-)
>
> I was trying to think of things that I knew that had strange floating point.

> Some systems VMS ran on, but again, long gone?

The VAX floating-point formats are mostly available, in most cases
emulated in software, on OpenVMS Alpha and OpenVMS I64, and probably
will be on OpenVMS x86, which supposedly arrives in field test next
year. But IEEE has been available for a long time, and also the
default for building Perl for a long time (even though, on Alpha, it's
not the compiler default).

I believe IEEE support is really a separate question from C99 support,
and it's not just a question of format, but of semantics. Don't we
have some secret Infinity sauce somewhere that emulates Infinity for
values outside a range? So the real question is how long do we need to
maintain the workarounds, and I think that's pretty hard to answer.
If you have to rescue some ancient data, there is nothing better than
Perl to do it. But if the maintenance cost is high, it might be
reasonable to say you can do that with anything up to Perl 5.3x.x and
don't need something later and thus we don't need those features in
future versions.

On 10/2/20 4:03 AM, Craig A. Berry wrote:
> On Thu, Oct 1, 2020 at 4:43 AM Nicholas Clark <nick@ccl4.org> wrote:

>>>> What C89 things are we stuck with? (I'm guessing we can't assume 754
>>>> floating point)?

> I believe IEEE support is really a separate question from C99 support,

That is a good insight.

> and it's not just a question of format, but of semantics. Don't we
> have some secret Infinity sauce somewhere that emulates Infinity for
> values outside a range? So the real question is how long do we need to
> maintain the workarounds, and I think that's pretty hard to answer.
> If you have to rescue some ancient data, there is nothing better than
> Perl to do it. But if the maintenance cost is high, it might be
> reasonable to say you can do that with anything up to Perl 5.3x.x and
> don't need something later and thus we don't need those features in
> future versions.

If documented, I think that saying "if you need this bit of backward
compatibility you can do so using Perl 5.3x.x" is a pretty defensible
stance.

That documentation could also explicitly state a minimal maintenance
burden, that this version will compile with common tool-chains for the
foreseeable future.

With that I believe it would be possible to, in good conscience, let go
of some of the more burdensome of the very old workarounds and
complexity which tries to maintain obscure/obsolete platforms and
decade-old deprecated behavior.

--
Eric Herman

On 10/1/20 11:00 AM, Nicholas Clark wrote:
> To quote ilmari:
>
> designated struct initialisers
> i.e. struct foo bar = { .baz = 42, .bat = 37 };
>
>
> those and inline variable declarations, those are the two things that I'd
> like.


Yes, these two seem like the biggest wins for code clarity.

I'd be interested to know which real-life platform+toolchain has trouble
with either of these, because they each make code less irritating to
read and understand.

Other stuff strikes me as less important:

* Variable-length array can be nice for reading the code, but usually
not that big of a gain, so that's not one I'd fight for -- even though I
believe it is essentially universally supported.

* Flexible array members are not something I think would make things
worlds better for the perl codebase, so again, even if widely supported
maybe stay clear of that for a while until everyone is more confident.

* Variadic macros I would like (and is in C++11) as that would probably
clean up some of the code, but is probably off the table for any public
header ... also we probably don't get to use __VA_OPT__(,) ... without
which a lot of the advantage of variadic macros is out of reach anyway.

So, are there any actual platforms which don't support intermingled
declarations and code or designated initialisers, and if so, can we get
it added to the Cpan Testers?

> BUT
>
> C++ didn't get designated struct initialisers until far too recently, so we
> can't put them in any header files, else we'd prevent C++ XS extensions from
> compiling.

It would still be very nice to have designated struct initialisers in .c
files, even if there are strict rules for not doing so in .h files.

> So if we use them, we'd likely need to figure out some kind of portability
> test to make sure that headers didn't have them. Until now, our portability
> test as been to build the entire core source with a C++ compiler.

Would it be enough to craft and test some "hello world" C++ XS module
which includes every header?


-Eric


P.S.: Also related to structs with flexible array members, we should
separately have a conversation about strict aliasing violations ...
something I'm probably guilty of making more of in the codebase with an
integer allocation patch which got merged a long time ago, but that's a
distraction from this subject.

--
Eric Herman

Yes, IEEE floating point vs. other implementations is managed primarily via
defines. Solaris and Cygwin, for example, are other OSes that have other
floating point implementations by default that we defaulted out to IEEE
well over a decade ago.

On Thu, Oct 1, 2020 at 9:04 PM Craig A. Berry <craig.a.berry@gmail.com>
wrote:

> On Thu, Oct 1, 2020 at 4:43 AM Nicholas Clark <nick@ccl4.org> wrote:
> >
> > On Tue, Sep 29, 2020 at 04:08:20PM +0200, H.Merijn Brand wrote:
> > > On Mon, 28 Sep 2020 14:41:01 -0600, Karl Williamson
> > > <public@khwilliamson.com> wrote:
>
> > > > What C89 things are we stuck with? (I'm guessing we can't assume 754
> > > > floating point)?
> >
> > Not all the world is(n't) a VAX :-)
> >
> > I was trying to think of things that I knew that had strange floating
> point.
>
> > Some systems VMS ran on, but again, long gone?
>
> The VAX floating-point formats are mostly available, in most cases
> emulated in software, on OpenVMS Alpha and OpenVMS I64, and probably
> will be on OpenVMS x86, which supposedly arrives in field test next
> year. But IEEE has been available for a long time, and also the
> default for building Perl for a long time (even though, on Alpha, it's
> not the compiler default).
>
> I believe IEEE support is really a separate question from C99 support,
> and it's not just a question of format, but of semantics. Don't we
> have some secret Infinity sauce somewhere that emulates Infinity for
> values outside a range? So the real question is how long do we need to
> maintain the workarounds, and I think that's pretty hard to answer.
> If you have to rescue some ancient data, there is nothing better than
> Perl to do it. But if the maintenance cost is high, it might be
> reasonable to say you can do that with anything up to Perl 5.3x.x and
> don't need something later and thus we don't need those features in
> future versions.
>

On 10/1/20 8:03 PM, Craig A. Berry wrote:
> On Thu, Oct 1, 2020 at 4:43 AM Nicholas Clark <nick@ccl4.org> wrote:
>>
>> On Tue, Sep 29, 2020 at 04:08:20PM +0200, H.Merijn Brand wrote:
>>> On Mon, 28 Sep 2020 14:41:01 -0600, Karl Williamson
>>> <public@khwilliamson.com> wrote:
>
>>>> What C89 things are we stuck with? (I'm guessing we can't assume 754
>>>> floating point)?
>>
>> Not all the world is(n't) a VAX :-)
>>
>> I was trying to think of things that I knew that had strange floating point.
>
>> Some systems VMS ran on, but again, long gone?
>
> The VAX floating-point formats are mostly available, in most cases
> emulated in software, on OpenVMS Alpha and OpenVMS I64, and probably
> will be on OpenVMS x86, which supposedly arrives in field test next
> year. But IEEE has been available for a long time, and also the
> default for building Perl for a long time (even though, on Alpha, it's
> not the compiler default).
>
> I believe IEEE support is really a separate question from C99 support,
> and it's not just a question of format, but of semantics. Don't we
> have some secret Infinity sauce somewhere that emulates Infinity for
> values outside a range? So the real question is how long do we need to
> maintain the workarounds, and I think that's pretty hard to answer.
> If you have to rescue some ancient data, there is nothing better than
> Perl to do it. But if the maintenance cost is high, it might be
> reasonable to say you can do that with anything up to Perl 5.3x.x and
> don't need something later and thus we don't need those features in
> future versions.
>

I think we have adequate substitutes for systems without 754 floating point.

As to other things, the branch smoke-me/khw-c99 contains several of the
C99 things that people have indicated they want. It would be helpful if
you were to try to compile it; and run tests if possible.

On Thu, Oct 8, 2020 at 11:46 PM Karl Williamson <public@khwilliamson.com> wrote:

> I think we have adequate substitutes for systems without 754 floating point.
>
> As to other things, the branch smoke-me/khw-c99 contains several of the
> C99 things that people have indicated they want. It would be helpful if
> you were to try to compile it; and run tests if possible.

There is a VMS smoke of that branch here:

<https://www.nntp.perl.org/group/perl.daily-build.reports/2020/10/msg258588.html>

Nothing new in compiler warnings or test failures compared to blead.