PR# 11151 Compiler accepts "C inline" routine with no alias but rejects one with alias ""

The compiler accepts a routine that is `external "C inline"' but has no Alias
clause.  I'm reporting this as a bug since the compiler rejects the apparently
semantically equivalent `external "C inline" alias ""'.  Both should be either
accepted or rejected.  My vote is for rejection but I don't feel strongly 
about it, as long as the two are consistent.

See attached files.

Added eweasel test valid230 for this bug.  It checks whether VZCC(2) is
enforced ("C inline" external must have an alias).  Currently, it is not
enforced.  Test should possibly be extended to handle other clauses of VZCC(2).

After further experimentation, it looks like none of the 3 clauses of VZCC is
enforced, not even as a warning.  Perhaps this is something you have deferred
until a later release but it doesn't seem that difficult.

After reading the Standard, I'm reopening this report.  An external "C inline"
routine with no Alias clause violates VZCC(2) (section 8.31.11, page 151).

I agree that this is an ECMA issue rather than an implementation issue.
I see a big difference between

    value: INTEGER
        external "C"
        end

and

    value: INTEGER
        external "C inline"
        end

In the former, there are least has to be a routine name `value' or the code
won't link and one is likely to find the mistake.  I cannot see any
possible utility in allowing the latter, since it can only be a mistake.
In the latter case, one is allowed to forget to specify the routine body
without any complaint from the compiler.  What's even worse is that it
may sometimes return the correct value by accident.  This does not seem like
a recipe for reliability to me.

Please present my point of view to EMCA committe when appropriate.

Closing this report.

The standard is pretty clear on the semantics. It is the semantics of the C program and I'm pretty sure it is correct to return garbage in C.

I would close this, since it is not per say a bug in our implementation but something we could address in the ECMA specification.

I think the Standard is very wrong.  What is the semantics of the following

   value: INTEGER_64
      external "C inline"
      end

Is it 0?  What if the type is BOOLEAN, CHARACTER_32, etc.  What if the
return type is a user defined expanded type?

In any case, even if this is the semantics (default value of that type)
then you have a bug in the compiler.  Compile attached program and
execute it.  REAL_64, INTEGER_64 and NATURAL_64 values are garbage,
not 0.

Reopening this report.

The standard allows for empty string, so I've updated our compiler to accept them too.

Attachments for problem report #11151