[Info-vax] Device locked by non existing process.

[John Reagan]

On Thursday, May 3, 2018 at 11:51:27 AM UTC-4, seasoned_geek wrote:
> On Wednesday, May 2, 2018 at 9:51:24 PM UTC-5, John Reagan wrote:
> > On Wednesday, May 2, 2018 at 5:37:55 PM UTC-4, seasoned_geek wrote:
> > > On Sunday, April 29, 2018 at 7:56:12 PM UTC-5, Arne Vajhøj wrote:
> > > > On 4/23/2018 11:43 AM, seasoned_geek wrote:
> > > > > char *ptr2 = NULL;
> > > > > 
> > > > > For a very long time we _had_ to do this. Now it is bad practice and later C standards introduced nullptr.
> > > > 
> > > > The later C standard called C++ 11?
> > > > 
> > > > :-)
> > > > 
> > > 
> > > Obviously you haven't written C on OpenVMS lately. The current C compiler is a downgrade to what I had installed. This version has pieces of C99 stubbed out, without reserving words which were stubbed. Other segments aren't touched at all while a token few portions of the standard were actually implemented.
> > > 
> > > Had the current C compiler been placed in a charred oak barrel upon its release, it would be some mighty fine sipping whiskey by now.
> > > 
> > > Not that I read every message in here, but the last blurb I read about the C compiler for the x86 port is that it "might" finish off the C99 standard, leaving C11 __still__ a later standard which means the new style for() loop which mimics the Qt foreach() loop [sans the object copy] will be out of reach for years to come.
> > 
> > Can you tell me what parts that the compiler is missing?  My understanding is that the compiler conforms.  The RTL on the other hand is missing some headers (stdint.h in particular), a bunch of things are missing from inttypes.h, and there are missing printf/scanf options.  Plus a bunch of bugs...
> > 
> > Since we're using clang as the C++ compiler on x86, you should be able to run clang in C11 mode to get yourself a nice C11 compiler.  We'll have to do further work on the RTLs of course.
> 
> When you read through the header files and find the comments of all the things which are stubbed and missing it is really difficult to say the compiler is complete. At a minimum it should be throwing compilation warnings rather than just merrily NOP the missing stuff leaving it for a developer to debug _into_ the RTL to find out what is wrong.
> 
> At this point I wish I had kept a list because I ran into at least half a dozen things which compiled clean and successfully linked to a pile of nothing needlessly extending development time.
> 
> If the same approach is being taken with clang on the x86, it too will be a downgrade. It is far better to have a __complete__ compiler at a lower level than have something with lots of stuff stubbed out introducing errors in the program. In short your clang compiler has to know about everything which isn't actually implemented and throw warnings/errors if used.

This is news to me.  You will easily notice the lack of <stdint.h> or any of the C99 macros missing from <inttypes.h> like INT32_C, PRI prefix macros, etc at compile-time.  The only things I know if are the missing printf/scanf modifiers that will be unrecognized by the RTL and ignored/flagged.  I've slogged through most of the CRTL in the past several years looking at things for planning.  I don't remember anything stubbed out (doesn't mean things aren't totally missing).

Our internal tables have a "is_C99" flag the RTL knows which routines (like many floating routines) were "Digital extensions to C89 but turned into standard for C99".  Depending on the setting of /STANDARD=C89 vs /STANDARD=C99, the headers will define them as appropriate.

Besides a whole raft of bugs in the RTL (not adhering to POSIX or other defacto standards, filename issues, missing interfaces, more versions of stat() can you can count, etc), I don't know of many C99-related issues beyond the ones I mentioned.

So if you ever find your notes, I'd appreciate seeing them.