Urgent question: malloc and ada...

Urgent question: malloc and ada...

[Guido Tesch]

High there.

I have a serious problem with interfacing between Ada and C. In a C
program, I allocate a lot of memory via malloc (more than one MB). When
I run the Ada program that interfaces with the C stuff, I get a
segmentation fault exactly at a point, where a subprocedure is called,
before even the first code line of this procedure is touched. My guess
is that the memory management from C and Ada do not work together when
doing big mallocs, and that some portion of my Ada program code had been
overwritten by C's mallocs.

Do you have experiences with this kind of stuff? Could you tell me if
I'm right and how to solve this ugly problem?

Thanks in advance.


Guido

P.S.: Answers please via mailto:guido.tesch@gmd.de  Thank you.
-- 
      ////
    0(o o)0
-oOO--(_)--OOo--------------------------------------------------------
                 University of Bonn, Germany
   Guido         E-Mail: tesch@informatik.uni-bonn.de
        Tesch    URL:    http://titan.informatik.uni-bonn.de/~tesch
   oooO          Presently working at GMD, Sankt Augustin, Germany
  (   )  Oooo    http://www.gmd.de/             Tel.: +49-2241-14-2714
---\ (---(   )--------------------------------------------------------
    \_)   ) /
         (_/

Re: Urgent question: malloc and ada...

[Joe Gwinn]

In article <352A79C2.15FB7483@nathan.gmd.de>, Guido Tesch
<tesch@nathan.gmd.de> wrote:

> Hi there.
> 
> I have a serious problem with interfacing between Ada and C. In a C
> program, I allocate a lot of memory via malloc (more than one MB). When
> I run the Ada program that interfaces with the C stuff, I get a
> segmentation fault exactly at a point, where a subprocedure is called,
> before even the first code line of this procedure is touched. My guess
> is that the memory management from C and Ada do not work together when
> doing big mallocs, and that some portion of my Ada program code had been
> overwritten by C's mallocs.
> 
> Do you have experiences with this kind of stuff? Could you tell me if
> I'm right and how to solve this ugly problem?

You don't have any reason to believe that this is a malloc versus Ada
question, based on your description.  In my experience, the fastest way to
resolve such a problem is to debug the Ada and C programs with an
assembly-level debugger, which can see things as they truely are.  Put a
breakpoint just before the fatal subroutine jump, and single-step into the
subroutine.  The cause should become  blindingly obvious at that point.  

Don't assume that the Ada and C compilers have generated correct assembly
code, or that they agree on how C-Ada subroutine interfaces work, in exact
detail.  It sounds like you are calling Ada from C; this is difficult to
impossible with Ada83, and better with Ada95, but is often tricky.  Ada83
really expected to be on top, to be the main(), and it was often easier to
call C from an Ada main than to call Ada from a C main.  

C may well not be setting the stack and registers up to Ada's liking.  Or
vica versa. 

In Ada83, some compilers allowed one to declare Ada procedures as
interrupt routines, with minimal expectations of the environment from
which they will be called, and one can in fact call such routines from C,
although passing parameters is difficult.  Some compilers also allowed one
to say that an Ada procedure would be called from some foreign language;
this is like the ISR case, except one could have parameters.  And so on.


Joe Gwinn

Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[Larry Kilgallen]

In article <gwinn-0904982253200001@d183.dial-5.cmb.ma.ultra.net>, gwinn@ma.ultranet.com (Joe Gwinn) writes:

> detail.  It sounds like you are calling Ada from C; this is difficult to
> impossible with Ada83, and better with Ada95, but is often tricky.  Ada83
> really expected to be on top, to be the main(), and it was often easier to
> call C from an Ada main than to call Ada from a C main.  

Those limitations regarding which language was used for the main program
may be true for some particular Ada83 implementation with which you are
familiar, but they are not a characteristic of the Ada83 language itself.
One problem I have heard discussed here is "elaboration", and DEC Ada for
VMS has always done that via the LIB$INITIALIZE mechanism of the operating
system, without requiring the main program be written in Ada. (There was
a bug 10 years ago when sharable images (DLLs) were used, but bugs are bugs.)
Since LIB$INITIALIZE is an "obvious" capability of the operating system,
presumably GNAT for VMS either does the same obvious thing with LIB$INITIALIZE
or does something different which also works, but at any rate does not ignore
the issue.

> C may well not be setting the stack and registers up to Ada's liking.  Or
> vica versa. 

This also should be a non-problem if the operating system (like VMS) mandates
a calling standard.  On less organized operating systems you may survive
by buying all your compilers from the same source.  Perhaps the main
advantage of Ada95 is that it forces compiler developers to do the right
thing, rather than trusting them :-).

Larry Kilgallen

Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[Joe Gwinn]

In article <1998Apr10.073110.1@eisner>, Kilgallen@eisner.decus.org.nospam wrote:

> In article <gwinn-0904982253200001@d183.dial-5.cmb.ma.ultra.net>,
gwinn@ma.ultranet.com (Joe Gwinn) writes:
> 
> > detail.  It sounds like you are calling Ada from C; this is difficult to
> > impossible with Ada83, and better with Ada95, but is often tricky.  Ada83
> > really expected to be on top, to be the main(), and it was often easier to
> > call C from an Ada main than to call Ada from a C main.  
> 
> Those limitations regarding which language was used for the main program
> may be true for some particular Ada83 implementation with which you are
> familiar, but they are not a characteristic of the Ada83 language itself.
> One problem I have heard discussed here is "elaboration", and DEC Ada for
> VMS has always done that via the LIB$INITIALIZE mechanism of the operating
> system, without requiring the main program be written in Ada. (There was
> a bug 10 years ago when sharable images (DLLs) were used, but bugs are bugs.)
> Since LIB$INITIALIZE is an "obvious" capability of the operating system,
> presumably GNAT for VMS either does the same obvious thing with LIB$INITIALIZE
> or does something different which also works, but at any rate does not ignore
> the issue.

Even under VAX/VMS in the 1980s, it wasn't so easy to call Ada from C.  I
know because we did just that.  There was a way to declare an Ada function
as being called from non-Ada; this worked and we used it, but you lost
much of the Ada environment.  

Actually, we were implementing an object-oriented communications 
system able to handle the full bandwidth of a large intelligence radar in
Ada83 on VAX 8600s, and we used these non-Ada Ada functions as the OO
methods, using a special assembly-coded invoker to call them by address
(vice name).  To get Ada83 and VMS to run that fast on the hardware of the
day was quite the trick, requiring special kernel calls plus a
shared-memory message passing infrastructure.  DEC Ada83 didn't handle
shared memory at all well, so we did an elaborate fan-dance so she never
saw memory she didn't completely own - her eyes were covered whenever we
needed to violate the closely-held assumptions of her upbringing. Sort of
like when your mother covered your eyes so you wouldn't see something on
the TV, because she didn't want to deal with the nightmares.

Ada95 should allow one to do without such hacks, but it still isn't
totally smooth, but the multiple-language problem isn't restricted to Ada,
and never was.



> > C may well not be setting the stack and registers up to Ada's liking.  Or
> > vica versa. 
> 
> This also should be a non-problem if the operating system (like VMS) mandates
> a calling standard.  On less organized operating systems you may survive
> by buying all your compilers from the same source.  Perhaps the main
> advantage of Ada95 is that it forces compiler developers to do the right
> thing, rather than trusting them :-).

This was one clear advantage of VAX/VMS in its day, but few other vendors
did any such thing.  Under VMS, there was one common subroutine calling
convention, so calling one language from another was much easier than
normal.  

That said, we used to call all manner of languages one from another,
sometimes directly, and sometimes by means of little assembly-coded
wrappers ("bindings" in modern jargon), on all manner of computers.  Ugly,
but effective, so one didn't choose platforms just for the ability to call
one language from another.


Joe Gwinn

Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[Robert Dewar]

iJoe said

<<Ada95 should allow one to do without such hacks, but it still isn't
totally smooth, but the multiple-language problem isn't restricted to Ada,
and never was.
>>

Please give us some details as to what is not smooth. I find it hard to
find any specific information in your message. What Ada 95 compiler have
you used? What specific difficulties have you had in interfacing to other
languages (in particular to C, Fortran or COBOL using the defined features
in Ada 95).

Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[Joe Gwinn]

In article <dewar.892603771@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> Joe said
> 
> <<Ada95 should allow one to do without such hacks, but it still isn't
> totally smooth, but the multiple-language problem isn't restricted to Ada,
> and never was.
> >>
> 
> Please give us some details as to what is not smooth. I find it hard to
> find any specific information in your message. What Ada 95 compiler have
> you used? What specific difficulties have you had in interfacing to other
> languages (in particular to C, Fortran or COBOL using the defined features
> in Ada 95).

It's a lot of little things, too many to really list in any detail. 
Alignment and padding of and between various size fields is a big issue,
especially if the processor hardware in the various participating machines
have different data alignment requirements.  All the gritty details needed
to ensure that data structures defined in two unrelated languages and
compilers are absolutely congruent, to the bit, always and forever.  I
have never seen any real pattern implicating any one language or compiler,
although one's chances are better if all involved compilers came from one
source, and simpler languages tend to cause less trouble.  No high-order
language really allows one to fully control the representation of complex
data structures in memory, although some give it more lip service than
others.  Assembly code will never die; it may be ugly, but it always
works, and it's unlikely to try to outsmart you.

If you are trying to verify or improve GNAT's interface to C and/or UDP
messages from other machines of different manufacture via communications,
I would try to implement something that handles complex UDP messages sent
between these three worlds, and see how it goes.  I bet you will find lots
to fix; we always do, but are forced to evade rather than really fix
things, not having command of the Ada compiler.  Then, when it all seems
to work, add a field to the beginning of a message format, upgrade a
compiler or two, and change a machine type or two.  

One thing that has improved noticably over the last decade is that
hardware floating point formats are now pretty much standardized under
IEEE Std 754.  In the old days, you only rarely could afford to have
floating point variables in messages sent between different kinds of
machine as no two floating point formats were the same.  Now, if the
machines are of the same endian persuasion, 32-bit and 64-bit floats in
messages work just fine.  The other IEEE float formats aren't universally
supported.

Joe Gwinn

Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[Robert Dewar]

Joe said

<<It's a lot of little things, too many to really list in any detail.
>>

OK, so please list ONE specific case!

We seem to get from you this general diatribe on how difficult things are,
but it seems hard to get a specific example. In my experience many of the
"problems" that people have are not language problems at all, but simply
cases of people not knowing the language well enough. Yes, these features
are quite tricky to learn, but if you want to be successful in using Ada 95
for handling low level interfacing, then you have to learn and understand
the features in Ada 95 that accomplish this.

So, please give ONE example from your "lot of little things", we will settle
for not having the complete list if it is so long!

Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[Joe Gwinn]

In article <dewar.892815844@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> Joe said
> 
> <<It's a lot of little things, too many to really list in any detail.
> >>
> 
> OK, so please list ONE specific case!

We have lists.  I'll see what I can publish when I return in a week.

 
> We seem to get from you this general diatribe on how difficult things are,
> but it seems hard to get a specific example. In my experience many of the
> "problems" that people have are not language problems at all, but simply
> cases of people not knowing the language well enough. Yes, these features
> are quite tricky to learn, but if you want to be successful in using Ada 95
> for handling low level interfacing, then you have to learn and understand
> the features in Ada 95 that accomplish this.

Umm.  Here we go again.  No, not all developers have doctorates in
anything, let alone computer science, but the problems of interfacing code
written in different languages, or even same language but different
compilers, have been with us for decades.  This is an area where details
are excruciatingly important.  

I am perplexed.  Why do you think Ada, a capable but complex language, is
any different?  Why do you express surprise that people have problems
here, and demand the evidence, as if to prepare for a federal court case?

Also, I don't know that having the enitire list in detail would help
people, because they will have a different combination of languages and
compilers.  What's more useful is the advice to focus on the interface
details in your particular setup, because history has shown this area to
be a rich source of trouble.


> So, please give ONE example from your "lot of little things", we will settle
> for not having the complete list if it is so long!

I have to wonder if I will ever be able to provide enough details to
satisfy you.  Past history isn't encouraging.  


Joe Gwinn

Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[Robert Dewar]

Joe says

<<Umm.  Here we go again.  No, not all developers have doctorates in
  anything, let alone computer science, but the problems of interfacing code
  written in different languages, or even same language but different
  compilers, have been with us for decades.  This is an area where details
  are excruciatingly important.>>

The idea that you need a doctorate in computer science to understand a
programming language like Ada is peculiar. I certainly have not found
this a necessity myself! In fact anyone with a reasonable practical
understanding of programming language semantics can perfectly well learn
Ada in general, and these aspects in particular. I talk by email nearly
every day to competent application programmers who have nothing like the
formal credentials that Joe seems to imagine as necessary. Many of them
understand these language aspects as well as I do. The idea that you
need special qualification to do this is definitely odd and does not
correspond to my experience at all.

<<I am perplexed.  Why do you think Ada, a capable but complex language, is
  any different?  Why do you express surprise that people have problems
  here, and demand the evidence, as if to prepare for a federal court case?>>

I don't know why you should be perplexed. Perhaps you simply don't know Ada 95
well enough to know that it is unique in being designed to interface with other
languages. For example, there is no other language of which I am aware which
has the capability of specifying that a particular type is to be represented
in a manner compatible with some other specific language.

It hardly needs a federal court case to be dissatisfied with your completely
unsubstantiated claim of difficulties in Ada 95 without a single example.
The reason an example is useful is we want to see whether it is genuinely
a gap or problem in Ada 95, or whether it is a matter of you not knowing
the language well enough (a possibility since you regard Ada as complex and
impossible to learn without a PhD in computer science :-)

<<Also, I don't know that having the enitire list in detail would help
  people, because they will have a different combination of languages and
  compilers.  What's more useful is the advice to focus on the interface
  details in your particular setup, because history has shown this area to
  be a rich source of trouble.>>

Absolutely, that is why the design of Ada 95 goes to such considerable
extents to provide specific features to solve these problems.

<<I have to wonder if I will ever be able to provide enough details to
  satisfy you.  Past history isn't encouraging.>>

I agree, it has been VERY hard to get you to discuss specific language
issues in the past. You have always been more comfortable at the general
"there are lots of problems, I know, I have been there" level. Fine, but
that deadends the conversation if we don't have a specific example. So
please contradict past history and cough up an example. Since you are now
trying to find the single example that most supports your case from a
supposedly long list, this should not be an unreasonable request!

Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[Joe Gwinn]

In article <dewar.892953117@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> Joe says
> 
> <<Umm.  Here we go again.  No, not all developers have doctorates in
>   anything, let alone computer science, but the problems of interfacing code
>   written in different languages, or even same language but different
>   compilers, have been with us for decades.  This is an area where details
>   are excruciatingly important.>>
> 
> The idea that you need a doctorate in computer science to understand a
> programming language like Ada is peculiar. I certainly have not found
> this a necessity myself! In fact anyone with a reasonable practical
> understanding of programming language semantics can perfectly well learn
> Ada in general, and these aspects in particular. I talk by email nearly
> every day to competent application programmers who have nothing like the
> formal credentials that Joe seems to imagine as necessary. Many of them
> understand these language aspects as well as I do. The idea that you
> need special qualification to do this is definitely odd and does not
> correspond to my experience at all.

I guess I have yet to meet anybody who knows Ada well enough, and probably
never will, but life goes on.


> <<I am perplexed.  Why do you think Ada, a capable but complex language, is
>   any different?  Why do you express surprise that people have problems
>   here, and demand the evidence, as if to prepare for a federal court case?>>
> 
> I don't know why you should be perplexed. Perhaps you simply don't know Ada 95
> well enough to know that it is unique in being designed to interface
with other
> languages. For example, there is no other language of which I am aware which
> has the capability of specifying that a particular type is to be represented
> in a manner compatible with some other specific language.

You know, no language is perfect, not even Ada.  Somehow, I doubt that a
statement that people had lots of trouble interfacing C to fortran 77
would have been challenged.


> It hardly needs a federal court case to be dissatisfied with your completely
> unsubstantiated claim of difficulties in Ada 95 without a single example.
> The reason an example is useful is we want to see whether it is genuinely
> a gap or problem in Ada 95, or whether it is a matter of you not knowing
> the language well enough (a possibility since you regard Ada as complex and
> impossible to learn without a PhD in computer science :-)

You know, just listening to the newsgroup traffic for a year would give
one the idea that there might be an issue or two here.  I recall lots of
C/C++ to Ada interface questions.  Do you think there might be a pattern
in all those unsubstantiated postings?


> <<Also, I don't know that having the entire list in detail would help
>   people, because they will have a different combination of languages and
>   compilers.  What's more useful is the advice to focus on the interface
>   details in your particular setup, because history has shown this area to
>   be a rich source of trouble.>>
> 
> Absolutely, that is why the design of Ada 95 goes to such considerable
> extents to provide specific features to solve these problems.

It takes two to tango.  One could have the problem even if Ada were
perfect in every way, which it's not, no more than any other language of
similar complexity.  Anyway, one has at least two languages involved in
such interfaces.

 
> <<I have to wonder if I will ever be able to provide enough details to
>   satisfy you.  Past history isn't encouraging.>>
> 
> I agree, it has been VERY hard to get you to discuss specific language
> issues in the past. You have always been more comfortable at the general
> "there are lots of problems, I know, I have been there" level. Fine, but
> that deadends the conversation if we don't have a specific example. So
> please contradict past history and cough up an example. Since you are now
> trying to find the single example that most supports your case from a
> supposedly long list, this should not be an unreasonable request!

As I said, I will dig up a list, probably next week.

It should by now be obvious that I am a system architect and manager, and
no longer write much code, so I don't usually know the details of problems
to the level I did when I wrote all the code, which seems to be the level
you wish.  Just because I report problems that others in my shop have
experienced, and so do not myself know all details, does not mean that the
problems didn't happen, or that they aren't serious.  In fact, I only hear
of the serious problems.  

Nor does it mean that certain patterns don't become obvious after decades
in the business.  It's time emough to see thinks rise up and then go to
smoke and ashes a few times over.

By the way, coders don't choose languages, managers do.


Joe Gwinn

Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[Robert Dewar]

Joe said

<<I guess I have yet to meet anybody who knows Ada well enough, and probably
  never will, but life goes on.>>

At the level we are talking about here, which is programmers who have a
reasonable working understanding of the issues in interfacing to other
languages, there are lots of Ada programmers who qualify. Indeed this is
the kind of knowledge that every Ada programmer should have, and the great
majority of Ada programmers are, in my experience, quite knowledgable in
this area. I judge this from the kind of questions we get in our support
activities. Sure there are some tricky points and good programmers are
always working to improve their knowledge in all areas of the language.

I suspect the fact that you can make this statement means you are trying
to use Ada with insufficient expertise. Your continued problems in the
interfacing area are additional evidence that this may be the case. Perhaps
you should arrange for some appropriate training activities for your
Ada programmers. We are not talking about needing a PhD in programming
languages here, just the level of knowledge that any Ada programmer working
on a serious Ada project should have.

<<You know, no language is perfect, not even Ada.  Somehow, I doubt that a
  statement that people had lots of trouble interfacing C to fortran 77
  would have been challenged.>>

Of course not, since neither C nor Fortran 77 have any provisions for
interfacing to other languages, so it is indeed the case that there are
problems in interfacing in a portable manner from C to Fortran 77.

Note that problems in interfacing using other languages than Ada, languages
that pay no attention to the difficult problems of interfacing, are unlikely
to be indicative of the performance of Ada 95 in this area, a language which
uniquely among commonly used languages *does* worry about the issue of 
interfacing to other languages. An interesting indication of this is that
the validation suite for Ada contains C, Fortran, and COBOL code, to be used
in tests of the interfacing capability. The interfacing tests involved here
are 100% portable, and expected to run without modification to either the
Ada or the C/Fortran/COBOL code in any tested environment supporting the
relevant languages.

<<It takes two to tango.  One could have the problem even if Ada were
  perfect in every way, which it's not, no more than any other language of
  similar complexity.  Anyway, one has at least two languages involved in
  such interfaces.>>

This probably indicates a lack of knowledge about how Ada handles this problem
(Joe indicates later that he is not familiar with the technical details). The
approach in Ada is that the entire responsibility of correct interface is
placed on the Ada compiler system. For example, when we write:

      type x is record
         a : Interfaces.C.int;
         b : Interfaces.C.char;
      end record;

      pragma Convention (C, x);

the Ada compiler is responsible for laying out the type x identically to the
corresponding C record in the particular environment in which the Ada
compiler operates. Yes, this is a huge pain, but it is a pain for the
Ada compiler implementor, who has to find out how to do this, *not* for
the Ada programmer.

<<It should by now be obvious that I am a system architect and manager, and
  no longer write much code, so I don't usually know the details of problems
  to the level I did when I wrote all the code, which seems to be the level
  you wish.  Just because I report problems that others in my shop have
  experienced, and so do not myself know all details, does not mean that the
  problems didn't happen, or that they aren't serious.  In fact, I only hear
  of the serious problems.>>

The level at which I would like a report is indeed more detailed than your
"we have problems" general claim. We want to see a specific instance of the
kind of interfacing problems you are having to see which category it is in:

   1. Lack of knowledge of Ada programmers involved
   2. Incorrect Ada 95 implementation
   3. Genuine problem in Ada 95 language definition

You tend to assume 3, partly because of the strange logic that says "since
I have had problems in the past with other languages, I am sure I will have
problems with Ada 95 in the future." This is, as noted above, indeed strange
logic, since one of the important design features in Ada 95 is precisely to
recognize the kind of problems you have had in the past, and fix them. On
one occasion in comp.lang.cobol, someone asked how to interface COBOL to C.
This cannot be done portably in a direct manner, since neither C nor COBOL
has anything to say about portable language interfacing, but I pointed out
that an interesting and completely portable approach was to use an Ada 95
layer as glue, since Ada 95 can portably interface to both languages. I
suspect 1 or perhaps 2 may be more likely to be the source of problems.

<<By the way, coders don't choose languages, managers do.>>

That's perfectly reasonable. Indeed "coders" often don't have the perspective
to make a choice. What is important is that whoever makes the decision,
no matter what their title be, have the kind of technical knowledge that
is needed to make a sound decision. All too often managers don't know enough
of the details to make sensible decisions. I have seen managers choose a
programming language when they knew absolutely nothing about the language
at all.

By the way "coders" is a rather contemptous term for a manager to use. I
trust you are not operating in an environment where you really have people
coding who understand nothing in the programming process other than actual
coding. That was a model used by many COBOL shops in the 60's and 70's (the
very ones who give us the Y2K headaches today), and is largely discredited.
Certainly in the kind of technical area for which Ada is used, I would look
for programmers with excellent knowledge of both Ada and the entire programming
process to be involved.

<<You know, just listening to the newsgroup traffic for a year would give
  one the idea that there might be an issue or two here.  I recall lots of
  C/C++ to Ada interface questions.  Do you think there might be a pattern
  in all those unsubstantiated postings?>>

I am always suspicious of people lumping C/C++ together in one breath as though
they are one language. They are most definitely NOT one language. If you look
at these posts, you will find the following clear pattern.

  In the case of C, the Ada 95 definition is adequate. The one remaining
  glitch of which I am aware, namely the issue of passing structs' by value
  (not such a common occurrence) is handled by the pragma C_Pass_By_Copy,
  implemented compatibly in GNAT and Intermetrics (i.e. including Green Hills).

  In the case of C++, no C++ standard was in effect at the time that Ada was
  standardized (indeed as I assume you know, the C++ standard is very recent).
  So there is no standardized method in the Ada 95 RM for interfacing directly
  to C++. In practice there is no problem because C and C++ can interoperate,
  and Ada and C can interoperate, so a portable solution can be created by 
  using a C interface layer (this is the sort of knowledge that should be
  at hand in any work you do in this area).

  GNAT does provide a set of pragmas for direct interfacing to C++, but
  these are not a standard part of the language. The ARA technical committee
  has made some progress towards a common set of interfaces for C++, but
  this work is not yet complete.

  Quite a few of the posts you are talking about have to do with using these
  special GNAT features. This is an area that you cannot expect Ada
  programmers to be familiar with, and indeed we definitely spend time
  helping our supported customers use these GNAT-specific problems.

  But for most purposes the use of an intermediate C layer solves the
  problems. Whether this is true in your case (or whether your case 
  involves C++ at all) remains to be seen pending some more technical
  details on the problems that you actually face.

<<As I said, I will dig up a list, probably next week.>>

We look forward to it. A list would be very instructive, but even ONE
clear technical answer would help get this conversation out of the rather
uninformative philosophical level onto a technical level.

Robert Dewar

Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[Jonathan Guthrie]

In comp.lang.ada Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> This probably indicates a lack of knowledge about how Ada handles this problem
> (Joe indicates later that he is not familiar with the technical details). The
> approach in Ada is that the entire responsibility of correct interface is
> placed on the Ada compiler system. For example, when we write:

>       type x is record
>          a : Interfaces.C.int;
>          b : Interfaces.C.char;
>       end record;

>       pragma Convention (C, x);

> the Ada compiler is responsible for laying out the type x identically to the
> corresponding C record in the particular environment in which the Ada
> compiler operates.

How does the Ada compiler implemetor know what C compiler is used in
that "particular environment in which the compiler operates"?
Telepathy?  I realize that, in the case of GNAT, (you assume) that
compiler is going to be GCC and that the way that code is generated by
that compiler is necessarily well understood by the GNAT team, but that
information simply isn't available to the implementor in the general case.
In fact, for those situations where the foreign language facility is most
useful (that is, you have to use a pre-built library that somebody got
from somewhere) the use of the foreign language facility may require
information (what compiler options/pragmas were used) that is unavailable
by any means.

In particular, what happens if they're using GNAT under Linux and some C
compiler other than GCC that organizes things differently than GCC does?
I suspect that the case isn't handled particularly well.  (Don't believe
that such compilers exist?  Well, as it happens I feel like writing a
C compiler today...B-))  Or do you have pragma's for specifying which
C compiler you need to interface with?  (If that's true, how do you pass
the validation suite without changing the pragma?)

Note that I am not claiming this to be a deficiency in the Ada language
specification.  I believe that the problem simply isn't solvable in the
general case.  (Well, it IS solvable, but the effort isn't anything like
worthwhile.  I would expect that you have to provide a mechanism to
allow the programmer to specify the layouts of structs, arrays, and so
forth.  Since figuring out the way things are laid out is the hard part,
why bother?)

Just out of curiousity, how DO you handle "pragma pack"?  Do you provide
equivalent pragmas for all the possible cases?

-- 
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.

Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[Simon Wright]

Jonathan Guthrie <jguthrie@brokersys.com> writes:

> How does the Ada compiler implemetor know what C compiler is used in
> that "particular environment in which the compiler operates"?
> Telepathy?

Well, one solution would be for the Ada vendor to specify it! In fact,
given the need to match the C representations, I think the Ada vendor
would have to.

Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[Larry Kilgallen]

In article <x7vson01poa.fsf@pogner.demon.co.uk>, Simon Wright <simon@pogner.demon.co.uk> writes:
> Jonathan Guthrie <jguthrie@brokersys.com> writes:
> 
>> How does the Ada compiler implemetor know what C compiler is used in
>> that "particular environment in which the compiler operates"?
>> Telepathy?
> 
> Well, one solution would be for the Ada vendor to specify it! In fact,
> given the need to match the C representations, I think the Ada vendor
> would have to.

And, depending on the compiler one might have to specify particular
compilation modes for which the alignment characteristics will be
matched.  I don't remember the details, but DEC C for Alpha allows
one to generate code which naturally aligns elements on quadword
boundaries or longword boundaries, depending on application needs.

Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[Stephen Leake]

Larry Kilgallen wrote:
> 
> In article <x7vson01poa.fsf@pogner.demon.co.uk>, Simon Wright <simon@pogner.demon.co.uk> writes:
> > Jonathan Guthrie <jguthrie@brokersys.com> writes:
> >
> >> How does the Ada compiler implemetor know what C compiler is used in
> >> that "particular environment in which the compiler operates"?
> >> Telepathy?
> >
> > Well, one solution would be for the Ada vendor to specify it! In fact,
> > given the need to match the C representations, I think the Ada vendor
> > would have to.
> 
> And, depending on the compiler one might have to specify particular
> compilation modes for which the alignment characteristics will be
> matched.  I don't remember the details, but DEC C for Alpha allows
> one to generate code which naturally aligns elements on quadword
> boundaries or longword boundaries, depending on application needs.

Borland C on Windows/Intel has a similar option, and it bit me once. I
compiled my code with longword alignment (for floating point speed), but
the Borland libraries were compiled with byte alignment. Bingo; system
crash. So you don't even need inter-language complications to get bugs
like this!

It would be nice if the object files included this kind of information,
so it could be checked at link time; anyone know if any object formats
do?

On the original topic, the Ada vendor must specify which C compiler(s)
they support on the target of interest. This was true for Ada 83, and is
still true for Ada 95. On the other hand, most CPUs I've used have a
standard calling convention, so there isn't that much variation between
compilers. Intel seems to be an exception; are there really other CPUs
that have incompatible C compilers?

-- Stephe

Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[Robert Dewar]

Jonathan says

<<How does the Ada compiler implemetor know what C compiler is used in
that "particular environment in which the compiler operates"?
Telepathy?  I realize that, in the case of GNAT, (you assume) that
compiler is going to be GCC and that the way that code is generated by
that compiler is necessarily well understood by the GNAT team, but that
information simply isn't available to the implementor in the general case.
>>

First of all, multiple C compilers per se is not a problem unless they
use incompatible data layouts or calling sequences. On most machines the
data layout and calling sequence is pretty much fixed, with more or less
official help from the official ABI.

If there is more than one C compiler, then the Ada compiler implementor
is expected to either specify what particular C compiler is to be used
or to provide multiple possible selections (e.g. by using diffent convention
names, as perhaps in 

	pragma Convention (Borland_C, ...);

In practice this has not proved necessary in any environment we have seen.
You make an assumption in the quoted paragraph above which is quite 
incorrect, namely that GNAT is tailored to what GCC does. This is the
wrong way of looking at things. In fact GNU C (that's actually what you
really mean by GCC here) goes to great efforts to be 100% compatible in
data layouts and calling sequences with whatever is the "standard" C
compiler in a given environment. Indeed it is regarded as a bug if GNU C
is not 100% compatible with the "standard" vendor compiler.

Thus the right way to look at things is that both GNU C, and GNAT (with
respect to pragma Convention C) make sure to be compatible with the standard
C compiler conventions.

As to the information not being available to the implementor, it can indeed
be tricky to find out what needs to be known, but it is not as difficult
as you might think, since on many machines the official ABI settles many
problems. In the case of GNU C, bug reports over the years have corrected
all the remaining minor discrepancies that have been discovered (remember
I said it was considered a bug if there are any discrepancies). This indeed
means that a lot of the critical work was already in place to meet the
GNAT requirement, but the requirement for GNAT is very definitely that it
must be compatible with the standard vendor C compiler (as well as GNU C).

Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[Robert I. Eachus]

In article <6hvm8k$t3l$1@news.hal-pc.org> Jonathan Guthrie <jguthrie@brokersys.com> writes:

  > How does the Ada compiler implemetor know what C compiler is used in
  > that "particular environment in which the compiler operates"?
  > Telepathy?

    No, by the name used in the pragma.  The conventions Ada, Intrinsic,
Fortran, C, and COBOL are defined in the RM, as are the packages
Interfaces.C, Interfaces.COBOL, and Interfaces.Fortran. Compilers are
allowed to add support for other languages, and in the particular case
mentioned above, they would choose one C compiler to correspond to the
convention C, and others could be named Gcc, VisualC, etc.  In practice,
the compiler that corresponds to C is the one used to compile the OS.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Urgent question: malloc and ada...

[Larry Kilgallen]

In article <EACHUS.98Apr30171942@spectre.mitre.org>, eachus@spectre.mitre.org (Robert I. Eachus) writes:

>     No, by the name used in the pragma.  The conventions Ada, Intrinsic,
> Fortran, C, and COBOL are defined in the RM, as are the packages
> Interfaces.C, Interfaces.COBOL, and Interfaces.Fortran. Compilers are
> allowed to add support for other languages, and in the particular case
> mentioned above, they would choose one C compiler to correspond to the
> convention C, and others could be named Gcc, VisualC, etc.  In practice,
> the compiler that corresponds to C is the one used to compile the OS.

I find it strange that even in comp.lang.ada a distinguished contributor
would express the assumption that the operating system was written in C.

Larry Kilgallen

Re: Urgent question: malloc and ada...

[Robert Dewar]

Larry said

<<I find it strange that even in comp.lang.ada a distinguished contributor
would express the assumption that the operating system was written in C.
>>

Perhaps that is because the distinguished contributor lives in the real
world, and not a wishful-thinking world! In practice the definition
expressed here is a useful one, since of course it is almost always
the case that the operating system involved will have substantial
chunks written in C (probably it won't be 100% C, there will be C++,
and perhaps assembly .....)

It would be a nice excercise to rewrite the Linux kernel in Ada, and indeed
the comparison of the effort involved, and the final results would make
an interesting student research paper. This is by no means an out of scope
effort. The core of the kernel is not a gigantic program.

But until such a thing is done, I am afraid that Larry will continue
to find the real world strange :-)

Re: Urgent question: malloc and ada...

[Charles Hixson]

Actually, if someone were to rewrite the Linux kernel in Ada, it might
be VERY useful.  Ada is supposed to catch errors MUCH more readily, and
an OS without internal errors would be extremely popular (at least with
some people [like me]).

I haven't checked the actual scope of the proposal, but if Linux were
being maintained in Ada rather than in C, there would be a large
increase in the number of interested (in Ada) people.

Robert Dewar wrote:
> 
> Larry said
> 
> <<I find it strange that even in comp.lang.ada a distinguished contributor
> would express the assumption that the operating system was written in C.
> >>
> 
> Perhaps that is because the distinguished contributor lives in the real
> world, and not a wishful-thinking world! In practice the definition
> expressed here is a useful one, since of course it is almost always
> the case that the operating system involved will have substantial
> chunks written in C (probably it won't be 100% C, there will be C++,
> and perhaps assembly .....)
> 
> It would be a nice excercise to rewrite the Linux kernel in Ada, and indeed
> the comparison of the effort involved, and the final results would make
> an interesting student research paper. This is by no means an out of scope
> effort. The core of the kernel is not a gigantic program.
> 
> But until such a thing is done, I am afraid that Larry will continue
> to find the real world strange :-)

-- 
Charles Hixson	charleshixson@earthling.net
(510) 464-7733	or chixso@mtc.dst.ca.us

Re: Urgent question: malloc and ada...

[Jonathan Guthrie]

In comp.lang.ada Charles Hixson <charleshixson@earthling.net> wrote:
> Actually, if someone were to rewrite the Linux kernel in Ada, it might
> be VERY useful.  Ada is supposed to catch errors MUCH more readily, and
> an OS without internal errors would be extremely popular (at least with
> some people [like me]).

Ada might catch some errors more readily than C, but that doesn't
necessarily translate into a kernel that works better if it's coded
in Ada than if it's coded in C.  As I pointed out in a previous
message, my experience is that most errors that I make aren't those
that can be found by the compiler.

I would, however, like to switch to only languages that do GC internally.
I do run into memory leaks and it's a pain managimng my own memory.

For what it's worth, I have found the Linux kernel to be quite stable and
reliable.  (I wish I could say the same about sendmail and net3.)

> I haven't checked the actual scope of the proposal, but if Linux were
> being maintained in Ada rather than in C, there would be a large
> increase in the number of interested (in Ada) people.

Do I hear a volunteer?  Of course, you won't get the "real" Linux
converted to Ada until you convert Linus, but there's nothing stopping
you from doing it to turn yourself into a building.  If you restrict
yourself to only those drivers you're interested in, it isn't even
that big a job.

Myself, if I were going to try to organize a net.project to promote Ada,
it would be a RADIUS daemon.  I happen to need a modular RADIUS daemon.

While I'm on the subject, I've been reading this NG for a while because
I've been interested in learning Ada.  The only book I have is
INTRODUCTION TO PROGRAMMING USING ADA by Dennis Volper and Martin D. Katz.
(I got it from a publisher's overstock bookstore for $3.)  This book
seems to match my approach to learning new languages, but it has two
problems:  It's based on Ada 8x, and its exercises assume the availability
of a library I don't have.

I don't know where I could get the library, (it doesn't appear to be
available except from the author, bummer) and I'd like to get a 
Ada 95 book, but I don't want to go out and blow $70 on a stinker.
(As the saying goes, been there, done that.)  If anyone feels the
urge to send suggestions, by all means.  (I've got the FAQ, so
there's no need to send me that.)

-- 
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.

Re: Urgent question: malloc and ada...

[Corey Minyard]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> 
> Perhaps that is because the distinguished contributor lives in the real
> world, and not a wishful-thinking world! In practice the definition
> expressed here is a useful one, since of course it is almost always
> the case that the operating system involved will have substantial
> chunks written in C (probably it won't be 100% C, there will be C++,
> and perhaps assembly .....)

The Linux kernel is almost all C with some assembly (mostly in inline
asm statements, startup code, and kernel trap code).  Linus tried to
convert to compiling with C++, but he got so much flak he changed it
back.  For real-time Linux, there is some support for loading C++
modules.

> 
> It would be a nice excercise to rewrite the Linux kernel in Ada, and indeed
> the comparison of the effort involved, and the final results would make
> an interesting student research paper. This is by no means an out of scope
> effort. The core of the kernel is not a gigantic program.

The core of the kernel is not itself gigantic, but add networking code
and device drivers and it gets pretty big.  The Linux 2.1.98 sources
are about 11MB compressed.  It would be a big job to rewrite the whole
thing.  Although we can always hope :-).  In reality, the Linux kernel
is finely tuned and very robust; so much optimization effort has gone
into it that reproducing it in Ada would likely produce bad results
that would make Ada look bad.

It would be nice to be able to support Ada for real-time Linux
modules, though.  Maybe someday I'll look at that...

-- 
Corey Minyard               Internet:  minyard@acm.org
  Work: minyard@nortel.ca       UUCP:  minyard@wf-rch.cirr.com

Re: Urgent question: malloc and ada...

[Robert I. Eachus]

In article <dewar.894029184@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

 > Perhaps that is because the distinguished contributor lives in the real
 > world, and not a wishful-thinking world! In practice the definition
 > expressed here is a useful one, since of course it is almost always
 > the case that the operating system involved will have substantial
 > chunks written in C (probably it won't be 100% C, there will be C++,
 > and perhaps assembly .....)

   Nice to be referred to as "the distinguished contributor," But
note, that in the real world I live in, I have worked on operating
systems written for the most part in PL/I (Stratus VOS and Multics),
and Assembler.  But I have never worked on an OS written in C.
(Worked on in the sense of "wrote or maintained part of the OS.")
However, any modern expert who writes an operating system is going to
use a C compiler for some purposes, such as device drivers.  If
nothing else there will be a "least common denominator" call interface
to the OS that is expressed in C.  That is the C compiler I had in
mind, the one used to define the OS call interface.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Urgent question: malloc and ada...

[Craig T. Spannring]

In article <EACHUS.98May6153727@spectre.mitre.org>,
Robert I. Eachus <eachus@spectre.mitre.org> wrote:
>In article <dewar.894029184@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>
>   Nice to be referred to as "the distinguished contributor," But
>note, that in the real world I live in, I have worked on operating
>systems written for the most part in PL/I (Stratus VOS and Multics),
>and Assembler.  But I have never worked on an OS written in C.
>(Worked on in the sense of "wrote or maintained part of the OS.")
>However, any modern expert who writes an operating system is going to
>use a C compiler for some purposes, such as device drivers.  If
>nothing else there will be a "least common denominator" call interface
>to the OS that is expressed in C.  That is the C compiler I had in
>mind, the one used to define the OS call interface.


I'm a bit confused as to why you would say that any OS expert would
use C for some purposes.  

My experiences with various operating systems has been that the
OS's implementation language leaks up through the API's.  Calling
system functions in C on the Stratus made it clear that VOS was
written in PL/I.  Calling system functions in AmigaDOS made it
clear that the OS was a BCPL program.  Windows seems like a mix
between Pascal and C.  Unix is obviously written in C.

I believe that C/C++ makes it more difficult to write robust code
than languages such as Ada and Modula-2.  (Please, no 'my language
i s better than your language' debates.  Been there, done that.
I just find them boring now.)  If a company with deep pockets and
a vertical market were to start building a new machine with that
premise that writing applications in C is unnecessarily difficult
and they have a goal of making applications easy to write it seems
logical that they would want to distance the application programmer
as far from C as possible.  Having no C in the OS is as far as
possible.

If you tried to limit your use of C to just the device drivers then
you would just introduce large amounts of tedious details to manage in
the interface between the device drivers and the rest of the OS.

As far as defining the OS call interface with C, this seems like a very poor
idea.  The C compiler can make arbitrary and capricious choices on how it 
lays out data structures in memory.  The C standard makes no indications
of how a structure is laid out.

BTW-  Anyone that had a hand in VOS has to qualify as "distinguished".

Re: Urgent question: malloc and ada...

[Robert Dewar]

Craig says

<<As far as defining the OS call interface with C, this seems like a very poor
idea.  The C compiler can make arbitrary and capricious choices on how it
lays out data structures in memory.  The C standard makes no indications
of how a structure is laid out.
>>

The C standard goes as far as it possibly could in defining how data
structures are laid out by default. No other language standard could say
more unless it restricted itself to a subset of available architectures.

As for the statement that any OS is likely to contain some C code at this
stage, that is simply an empirical observation, not a moral judgment!

Re: Urgent question: malloc and ada...

[Robert Dewar]

<<You mean there's a pragma Convention for BLISS?
>>

Well certainly there is in GNAT! And of course it is perfectly reasonable
in a VMS environment, where indeed there is quite a bit of BLISS around
(even in the operating system :-)

Re: Urgent question: malloc and ada...

[Larry Kilgallen]

In article <dewar.894029393@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> <<You mean there's a pragma Convention for BLISS?
>>>
> 
> Well certainly there is in GNAT! And of course it is perfectly reasonable
> in a VMS environment, where indeed there is quite a bit of BLISS around
> (even in the operating system :-)

Certainly more than C.  On Alpha only, C is being used for some of the
innards, particular for brand new modules.  As far as _calls_ to the
operating system are concerned, however, the System Service Dispatcher
is written in VAX assembly language, on both VAX and Alpha, so that is
the language to which one interfaces system service calls.  Since there
is a tight calling standard, however, it really does not cause trouble.
I find it hard to understand the tower of babble some other operating
systems have constructed through a lack of system-specific standards.

Larry Kilgallen

Re: Urgent question: malloc and ada...

[Robert Dewar]

Larry said

<<Certainly more than C.  On Alpha only, C is being used for some of the
innards, particular for brand new modules.  As far as _calls_ to the
operating system are concerned, however, the System Service Dispatcher
is written in VAX assembly language, on both VAX and Alpha, so that is
the language to which one interfaces system service calls.  Since there
is a tight calling standard, however, it really does not cause trouble.
I find it hard to understand the tower of babble some other operating
systems have constructed through a lack of system-specific standards.
>>


Note here that Larry is agreeing with the proposed criterion for defining
the standard C compiler *even* in the case of VMS, which is the one case
in which you might have thought that C was not used in the operating system.

So, just to recapture the interesting point (I forget who made it). The
proposal is that in practice, a working definition of what the standard
C compiler means is that it is the C compiler used for wrting the operating
system.

However, I don't see any analogous way of getting a feel for what the
standard Fortran or COBOL compiler may be, and here you definitely need
to find out from the vendor which Fortran compiler(s) or COBOL compiler(s)
their Ada compiler interfaces to.

Of course, as noted elsewhere in this thread, it is perfectly reasonable
(and indeed expected) for an Ada compiler to have multiple calling 
conventions if there are incompatible other-language compilers.

Re: Urgent question: malloc and ada...

[Jonathan Guthrie]

In comp.lang.ada Robert Dewar <dewar@merv.cs.nyu.edu> wrote:

> Of course, as noted elsewhere in this thread, it is perfectly reasonable
> (and indeed expected) for an Ada compiler to have multiple calling 
> conventions if there are incompatible other-language compilers.

Actually, I was commenting more on the alignment of structs (which, as
far as I know, can vary even on those systems with a single calling
convention) than the calling convention.  Calling conventions are usually
reasonably well standardized, the alignment of structs is not.  Yet your 
post implied that both are covered (as they would have to be) by the
requirements.

-- 
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.

Re: Urgent question: malloc and ada...

[Richard Kenner]

In article <6ifdou$io3$1@news.hal-pc.org> Jonathan Guthrie <jguthrie@brokersys.com> writes:
>Actually, I was commenting more on the alignment of structs (which, as
>far as I know, can vary even on those systems with a single calling
>convention) than the calling convention.  Calling conventions are usually
>reasonably well standardized, the alignment of structs is not.  Yet your 
>post implied that both are covered (as they would have to be) by the
>requirements.

On most modern systems, details of how structures are supposed to be aligned
are discussed in the same document that discusses the calling sequence.

On older systems, there is often *no* documentation on this and so the
appropriate thing to do is to follow whatever the specific compiler being
interfaced with does, just like you would do with calling conventions.

I see no difference between the two issues.

Re: Urgent question: malloc and ada...

[Jonathan Guthrie]

In comp.lang.ada Richard Kenner <kenner@lab.ultra.nyu.edu> wrote:
> >Actually, I was commenting more on the alignment of structs (which, as
> >far as I know, can vary even on those systems with a single calling
> >convention) than the calling convention.  Calling conventions are usually
> >reasonably well standardized, the alignment of structs is not.  Yet your 
> >post implied that both are covered (as they would have to be) by the
> >requirements.

> On most modern systems, details of how structures are supposed to be aligned
> are discussed in the same document that discusses the calling sequence.

<snippage>

> I see no difference between the two issues.

On many systems, the calling convention is carved in stone.  Unfortunately,
on every C compiler that I know well, it is possible to adjust the
alignment of the fields in structs on a case-by-case basis.  Those alignments
do not have to correspond to any system convention or even make any 
sense.  Of course, most of the compilers I know well are for Intel
processors, but it's in the GCC documentation.  In fact GNU C allows a
lot more leeway in how you specify the alignment of the fields in a struct
than the MS-DOS/Windows compilers I've used.

I, for one, am a lot more likely to muck about with the struct alignment
than I am to attempt to change the calling convention.

In any case, that sounds pretty different to me.  The statement has been
made that the Ada compiler is required to deal with all the complexities
of the Ada/C interface, I'm just trying to probe the limits and find out
what they are.

-- 
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.

Re: Urgent question: malloc and ada...

[Richard Kenner]

In article <6ihtmc$nf9$1@news.hal-pc.org> Jonathan Guthrie <jguthrie@brokersys.com> writes:
>Unfortunately, on every C compiler that I know well, it is possible to
>adjust the alignment of the fields in structs on a case-by-case basis. 
>Those alignments do not have to correspond to any system convention or even
>make any sense.

Right, but the same is true for Ada.  If you are overriding the defaults
in a structure layout, you do so the same way for C and Ada and need not
bother with Convention, which basically tells the compiler what to do
*by default*.

>In any case, that sounds pretty different to me.  The statement has been
>made that the Ada compiler is required to deal with all the complexities
>of the Ada/C interface, I'm just trying to probe the limits and find out
>what they are.

But when you explicitly specify a layout on either side, you are no
longer taking about the Ada/C interface.

Re: Urgent question: malloc and ada...

[Robert Dewar]

Jonathan said

<<On many systems, the calling convention is carved in stone.  Unfortunately,
on every C compiler that I know well, it is possible to adjust the
alignment of the fields in structs on a case-by-case basis.  Those alignments
do not have to correspond to any system convention or even make any
sense.  Of course, most of the compilers I know well are for Intel
processors, but it's in the GCC documentation.  In fact GNU C allows a
lot more leeway in how you specify the alignment of the fields in a struct
than the MS-DOS/Windows compilers I've used.
>>

Following up on my previous message .... the above makes no sense. The
calling sequence includes the specifications for how structs are passed
by reference, and thus how they are layed out and aligned. A calling
sequence that is "carved in stone" must include these issues in the carving!

Obviously if you use other than the default layout, by the use of the
equiavelnt of pragmas or rep clauses, then no Ada compiler can 
telephaythically guess what you have done. 

However, every Ada compiler wlil implement sufficient flexibility so that
you can use analogous statements in your Ada program to align and lay out
your data in a compatible manner.

Jonathan, I don't see any problem here at all. If you see one, let me make
the same request I make of Joe, please give us an example of what you
think is a problem case.

Re: Urgent question: malloc and ada...

[Robert Dewar]

Jonathan says

<<Actually, I was commenting more on the alignment of structs (which, as
far as I know, can vary even on those systems with a single calling
convention) than the calling convention.  Calling conventions are usually
reasonably well standardized, the alignment of structs is not.  Yet your
post implied that both are covered (as they would have to be) by the
requirements.
>>

I was using calling sequence quite generally here. The alignment of structs
is most CERTAINLY included, since part of what one does on a call is to pass
references to various kinds of data, and of course the alignment and layout of this
data must be clearly understood between callee and caller.

So most definitely the convention in the ADa sense *does* cover alignment
of structs. If two compilers differed in this respect, and an Ada compiler
wished to interface to both, then it would have to provide for this, either
by using separate calling conventions, or by using special pragmas.
THe use of separate calling conventions is preferable, since it avoids the
use of potentially non-portable pragmas. 

We still have not managed to coax out of Joe even one example of problems
in interfacing in a portable manner, but clearly if this is a goal (and it
was indeed a goal of the Ada 95 design), then it is better to stick to
the mechanisms provided in the RM. We deviated from this in GNAT/VMS
(providing the pragma Component_Alignment) since in this case, compatibility
with DEC Ada 83 is much more of an issue than compatibility with other
Ada 95 compilers, and indeed one would expect other Ada 985 compilers
for VMS to be driven by the same considerations in any case.

Re: Urgent question: malloc and ada...

[Larry Kilgallen]

In article <dewar.894114612@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Larry said
> 
> <<Certainly more than C.  On Alpha only, C is being used for some of the
> innards, particular for brand new modules.  As far as _calls_ to the
> operating system are concerned, however, the System Service Dispatcher
> is written in VAX assembly language, on both VAX and Alpha, so that is
> the language to which one interfaces system service calls.  Since there
> is a tight calling standard, however, it really does not cause trouble.
> I find it hard to understand the tower of babble some other operating
> systems have constructed through a lack of system-specific standards.
>>>
> 
> 
> Note here that Larry is agreeing with the proposed criterion for defining
> the standard C compiler *even* in the case of VMS, which is the one case
> in which you might have thought that C was not used in the operating system.

Not exactly, since in the case of VAX/VMS _no_ C compiler is used in
the operating system.

> So, just to recapture the interesting point (I forget who made it). The
> proposal is that in practice, a working definition of what the standard
> C compiler means is that it is the C compiler used for wrting the operating
> system.

Certainly "the standard C compiler endorsed by the manufacturer of
the operating system" makes sense, because DEC sells a C compiler
to use with VAX/VMS, even if they don't use it in the writing of
the operating system.

> However, I don't see any analogous way of getting a feel for what the
> standard Fortran or COBOL compiler may be, and here you definitely need
> to find out from the vendor which Fortran compiler(s) or COBOL compiler(s)
> their Ada compiler interfaces to.

That "endorsement" wording should work for Fortran and COBOL in a lot of
cases.

Larry Kilgallen

Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[Fergus Henderson]

eachus@spectre.mitre.org (Robert I. Eachus) writes:

>In article <6hvm8k$t3l$1@news.hal-pc.org> Jonathan Guthrie <jguthrie@brokersys.com> writes:
>
>  > How does the Ada compiler implemetor know what C compiler is used in
>  > that "particular environment in which the compiler operates"?
>  > Telepathy?
>
>    No, by the name used in the pragma.  The conventions Ada, Intrinsic,
>Fortran, C, and COBOL are defined in the RM, as are the packages
>Interfaces.C, Interfaces.COBOL, and Interfaces.Fortran. Compilers are
>allowed to add support for other languages, and in the particular case
>mentioned above, they would choose one C compiler to correspond to the
>convention C, and others could be named Gcc, VisualC, etc.  In practice,
>the compiler that corresponds to C is the one used to compile the OS.

It would also be easy to implement a command-line option or configuration
pragma to override the default meaning for the "C" convention
(e.g. by default "C" might mean "VisualC", but the user could
override it so that "C" would mean "gcc").

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[Joe Gwinn]

In article <dewar.893595400@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> Joe said
[snip]
> <<By the way, coders don't choose languages, managers do.>>
> 
> That's perfectly reasonable. Indeed "coders" often don't have the perspective
> to make a choice. What is important is that whoever makes the decision,
> no matter what their title be, have the kind of technical knowledge that
> is needed to make a sound decision. All too often managers don't know enough
> of the details to make sensible decisions. I have seen managers choose a
> programming language when they knew absolutely nothing about the language
> at all.

So have I.  Choice of language is only rarely a technical issue.  Nor are
managers likely to become more technical.  Sorry.


> By the way "coders" is a rather contemptous term for a manager to use. I
> trust you are not operating in an environment where you really have people
> coding who understand nothing in the programming process other than actual
> coding. That was a model used by many COBOL shops in the 60's and 70's (the
> very ones who give us the Y2K headaches today), and is largely discredited.
> Certainly in the kind of technical area for which Ada is used, I would look
> for programmers with excellent knowledge of both Ada and the entire
programming
> process to be involved.

Call "coders" programmers if you like, or even software engineers; it
makes little difference, and I've been called all of these, and worse.

 
> <<You know, just listening to the newsgroup traffic for a year would give
>   one the idea that there might be an issue or two here.  I recall lots of
>   C/C++ to Ada interface questions.  Do you think there might be a pattern
>   in all those unsubstantiated postings?>>
> 
> I am always suspicious of people lumping C/C++ together in one breath as
though
> they are one language. They are most definitely NOT one language. 

Of course not, but close enough for my purposes.  There is after all a
more than passing relationship between C and C++, and Ada95 is close to
neither.


> ... If you look
> at these posts, you will find the following clear pattern.
> 
>   In the case of C, the Ada 95 definition is adequate. The one remaining
>   glitch of which I am aware, namely the issue of passing structs' by value
>   (not such a common occurrence) is handled by the pragma C_Pass_By_Copy,
>   implemented compatibly in GNAT and Intermetrics (i.e. including Green
Hills).
> 
>   In the case of C++, no C++ standard was in effect at the time that Ada was
>   standardized (indeed as I assume you know, the C++ standard is very recent).
>   So there is no standardized method in the Ada 95 RM for interfacing directly
>   to C++. In practice there is no problem because C and C++ can interoperate,
>   and Ada and C can interoperate, so a portable solution can be created by 
>   using a C interface layer (this is the sort of knowledge that should be
>   at hand in any work you do in this area).
> 
>   GNAT does provide a set of pragmas for direct interfacing to C++, but
>   these are not a standard part of the language. The ARA technical committee
>   has made some progress towards a common set of interfaces for C++, but
>   this work is not yet complete.
> 
>   Quite a few of the posts you are talking about have to do with using these
>   special GNAT features. This is an area that you cannot expect Ada
>   programmers to be familiar with, and indeed we definitely spend time
>   helping our supported customers use these GNAT-specific problems.
> 
>   But for most purposes the use of an intermediate C layer solves the
>   problems. Whether this is true in your case (or whether your case 
>   involves C++ at all) remains to be seen pending some more technical
>   details on the problems that you actually face.

I would have to point out that we need *portable* but *bulletproof* 
Ada95-C/C++ interfaces.  With any chosen fixed set of compilers, one can
usually get things to work well enough.  If portability is required,
things get much harder.  In any case, it doesn't much matter what
theoretical portability features are claimed, as this is a particularly
difficult and bug-ridden area.

There are two Ada-C/C++ issues here:  Direct subroutine calling, and also
passage of messages back and forth.


> <<As I said, I will dig up a list, probably next week.>>
> 
> We look forward to it. A list would be very instructive, but even ONE
> clear technical answer would help get this conversation out of the rather
> uninformative philosophical level onto a technical level.

Doesn't seem too promising, does it? 


Joe Gwinn

Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[Larry Kilgallen]

In article <gwinn-0105982329270001@d153.dial-2.cmb.ma.ultra.net>, gwinn@ma.ultranet.com (Joe Gwinn) writes:
> In article <dewar.893595400@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>> I am always suspicious of people lumping C/C++ together in one breath as
> though
>> they are one language. They are most definitely NOT one language. 
> 
> Of course not, but close enough for my purposes.  There is after all a
> more than passing relationship between C and C++, and Ada95 is close to
> neither.

In a discussion of managers who don't know anything about choosing a
language, C and C++ decisions are equivalent in the vast majority of
cases.  The manager thinks the language being used is C++ because that
is the compiler which was purchased.  The worst defect of C++ may be
the ability to code in C.  Cultural difference make this less of a
problem for Ada compilers that have the ability to drop into assembly
language.

Larry Kilgallen

Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP

[Robert Dewar]

Joe says

<<I would have to point out that we need *portable* but *bulletproof*
  Ada95-C/C++ interfaces.  With any chosen fixed set of compilers, one can
  usually get things to work well enough.  If portability is required,
  things get much harder.  In any case, it doesn't much matter what
  theoretical portability features are claimed, as this is a particularly
  difficult and bug-ridden area.>>

Obviously the RM does not try to address C++ directly (how could it,
there was no such standard language in 1995). However, in practice you
can almost always create a C wrapper to solve this problem in a completely
portable manner.

You keep claiming that this is impossible, but it does not add to the
convincing nature of your argument to simply repeat this claim without
any proof or details. We need an example to understand what you are
talking about!

<<> We look forward to it. A list would be very instructive, but even ONE
  > clear technical answer would help get this conversation out of the rather
  > uninformative philosophical level onto a technical level.

  Doesn't seem too promising, does it?>>

Not until you cough up your promised example! We are still waiting.

Re: Urgent question: malloc and ada...

[Robert Dewar]

Joe says

(of interfacing C and Ada)

<<and better with Ada95, but is often tricky
>>

It would be interesting to know in more detail what "tricky" things you
have run in to.

Re: Urgent question: malloc and ada...

[Joe Gwinn]

In article <dewar.892208692@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> Joe says
> 
> (of interfacing C and Ada)
> 
> <<and better with Ada95, but is often tricky
> >>
> 
> It would be interesting to know in more detail what "tricky" things you
> have run in to.

Most of the trouble has been in passing data structures (records in Ada,
structs in C/C++) from one world to the other.  Pragma interface C has
worked mostly as expected, but getting the data across the divide
undamaged has not.  This was where the rep spec on an enumeration type
problem first surfaced.  These data structures are most often used for
message handling, which is how the three worlds of our system talk to each
other.  One world is Ada95, and the other two are different flavors of
C/C++ in different boxes under different operating systems.  One kind of
box and operating system houses Ada95 and one kind of C, and the other
kind of box and operating system houses the other kind of C/C++.

I don't know how much of the details of what has caused recent trouble is
universal, but I do know that passing data between languages and compilers
has always been a rich source of trouble, for all languages and compilers,
for my entire career, so I don't expect that it will ever change.

Joe Gwinn

Enumeration Types (was: Urgent question: malloc and ada)

[Matthew Heaney]

In article <gwinn-1204981927580001@d13.dial-1.cmb.ma.ultra.net>,
gwinn@ma.ultranet.com (Joe Gwinn) wrote:

>Most of the trouble has been in passing data structures (records in Ada,
>structs in C/C++) from one world to the other.  Pragma interface C has
>worked mostly as expected, but getting the data across the divide
>undamaged has not.  This was where the rep spec on an enumeration type
>problem first surfaced.

One "solution" is to not use enumeration types with rep clauses at all -
just use an integer.  It seems that the ability to put a representation
clause on an enumeration type was a feature only included in the langauge
to make it consistant; after all, you can choose the representation of
other types, so why not enumeration types too?  But it causes all kinds of
problems.

You'll have lots o' problems if you have a value with a bit pattern not
among the legal values (possible because you moved the data over an
external interface, and there was some noise during transmission).  I find
it simpler to avoid that mess altogether and use just integer types across
an interface, and writing my own mapping function (array) from integer
value to enumeration literal.

In practice, using an integer type instead of an enumeration is only
marginally less safe.  Consider this:

type ET is (Red, Green, Blue);
for ET use (Red => 1, Green => 3, Blue => 7);
for ET'Size use 8;

procedure Op (O : ET);

Now consider this:

type IT is new Interfaces.Unsigned_8;

Red : constant IT := 1;
Green : constant IT := 3;
Blue : constant IT := 7;

procedure Op (O : IT);

From a client's point of view, there is no difference between these types
(though a case statement now requires an others branch).  You call
procedure Op the same way in both cases.

You can make the argument, "But with the integer version, the client can
pass the value 2."  But this can only happen because of deliberate misuse,
ie

Op (2);

Here, he's being naughty, and using an integer literal.  What he should do is

Op (Red);

just like he'd do using the enumeration literal.

And no, you can't even accidently mix this type up with other integer
types, because IT is its own type.  You'd have to deliberately convert one
integer type into the other.

All told, I feel the ability to give an enumeration type a rep clause is an
unnecessary, error-prone feature of the Ada language.  An enumeration type
is at too high a level of abstraction to accomodate such a low-level
feature.  Giving a rep clause to an enumeration type causes all kinds of
other headaches for users and compiler-writers alike, such as using the
type to index an array, or taking the successor or predecessor of a value,
when type rep clause has holes.

Tuck wrote a thoughtful post on this topic a few weeks back.  I've included
it below.

Also, note that there is no such thing as rep "spec."  The proper term is
rep "clause."

>Joe Gwinn (gwinn@res.ray.com) wrote:
>: In article <EKrsrr.LD7.0.-s@inmet.camb.inmet.com>,
>: stt@houdini.camb.inmet.com (Tucker Taft) wrote:
>
>: ...
>: > As far as enumeration types, as others have pointed out, the Ada 95
>: > standard requires that the internal codes for enumeration types are
>: > contiguous and start at zero, so you are not in any danger if you leave
>: > out your "confirming" representation clauses.  It would be nice if
>: > our front end recognized "confirming" enumeration representation 
>: > clauses, but as usual, there are many possible "optimizations" 
>: > and this one never made it to the top of the list.
>: > One might argue that this is not really an optimization, but 
>: > it does require special code to recognize, and so represents
>: > yet another "special case" that you have to decide the priority
>: > of recognizing.
>
>: The key issue was that we had no way of knowing the dire consequences of
>: this innocent looking bit of standard Ada, until we had gone a fair
>: distance down that wrong road.  
>
>If you ask anyone who knows me well, you will know that I consider
>the enumeration representation clause anything but "innocent looking" ;-).
>For what it is worth, we will soon be releasing a new front end
>that recognizes the special case of a confirming enumeration
>representation clause.
>
>[ASIDE:
>
>Although the ability to specify the representation of an enumeration
>type initially sounds perfectly reasonable, the fundamental problem is that
>Ada also allows such "holey" enumeration types to be used as the
>type for a for-loop index, an array index, an entry family index,
>or the 'Succ/'Pred attributes.  This results in surprising implicit
>inefficiencies, something that violates one of the general Ada 
>language design principles.  Your enumeration rep clause simply reconfirmed
>the default representation, but suppose it didn't?  You would be
>stuck with the overhead you managed to eliminate by simply commenting
>out the rep clause.  Of course, the compiler could recognize various
>other specials cases, such as contiguous representation starting at
>something other than zero, or evenly distributed "holey" representation
>(e.g., even numbers only), or simply not "too" sparse, or ...  
>
>Pretty soon handling these enumeration representation clauses
>the way the "innocent" user would "expect" becomes a major artificial 
>intelligence challenge.  During the Ada 9X design process, when we
>found one of our new language ideas evoving into this kind of complex
>AI pattern matching problem for the compiler, we knew we were on the
>wrong track.  The user should be designing the algorithms, using
>the basic primitives of the language.  The primitives shouldn't themselves
>be at such a level that the compiler is effectively trying to take over
>part of the programming problem.
>
>Note that in C and C++, allowing the user to specify the values for
>enumeration literals creates no similar problem, because there is
>no operation that depends on the logical "position" of an enumeration
>literal.  All semantics of enumeration values in C/C++ depends on the
>underlying "code," not the position.  
>
>So in retrospect, I believe enumeration representation 
>clauses in Ada are a mistake.  If a user wants to name 
>particular values, they should simply use named integer
>constants, or perhaps better, named private-type constants.  They can build 
>up various maps of their own if they want to translate to/from some kind
>of "holey" representation from/to a contiguous representation.
>
>END OF ASIDE]
>
>: ... One wonders what other surprises lay in
>: wait.
>
>In general, the Ada language design philosophy eschewed "innocent"
>looking features that were in fact expensive at run-time.
>However, in the specific case of enumeration representation clauses,
>this useful language design philosophy was not completely followed.
>Other cases I know of are interactions between finalization, 
>exception handling, and abort, where the combination of features
>forces some or all of these three to incur more run-time overhead
>than you might expect.
>
>One "innocent" looking construct I once found was:
>
>   (others => Default_Value(Segment))
>
>used to initialize a segment of a load module to some default value.
>This called the function Default_Value once for each byte of the
>segment, and the segment was often 100K bytes or more.
>
>: ...
>
>: Joe Gwinn
>
>--
>-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
>Intermetrics, Inc.  Burlington, MA  USA




























Extra 



text



needed








because






of





my




stupid





newsreader.







Sorry.

Re: Enumeration Types (was: Urgent question: malloc and ada)

[Mark A Biggar]

Matthew Heaney wrote:
> In practice, using an integer type instead of an enumeration is only
> marginally less safe.  Consider this:
> 
> type ET is (Red, Green, Blue);
> for ET use (Red => 1, Green => 3, Blue => 7);
> for ET'Size use 8;
> 
> procedure Op (O : ET);
> 
> Now consider this:
> 
> type IT is new Interfaces.Unsigned_8;
> 
> Red : constant IT := 1;
> Green : constant IT := 3;
> Blue : constant IT := 7;
> 
> procedure Op (O : IT);
> 
> From a client's point of view, there is no difference between these types
> (though a case statement now requires an others branch).  You call
> procedure Op the same way in both cases.
> 
> You can make the argument, "But with the integer version, the client can
> pass the value 2."  But this can only happen because of deliberate misuse,
> ie
> 
> Op (2);
> 
> Here, he's being naughty, and using an integer literal.  What he should do is
> 
> Op (Red);
> 
> just like he'd do using the enumeration literal.
> 
> And no, you can't even accidently mix this type up with other integer
> types, because IT is its own type.  You'd have to deliberately convert one
> integer type into the other.

Actually you can do even better as follows:

package SomePackage is
 
 type IT is private;
 
 Red : constant IT;
 Green : constant IT;
 Blue : constant IT;
 
 procedure Op (O : IT);

private
 
 type IT is new Interfaces.Unsigned_8;
 
 Red : constant IT := 1;
 Green : constant IT := 3;
 Blue : constant IT := 7;

end SomePackage;

This eliminates the Op(2) problem while keeping all the properties of your
example.

--
Mark Biggar
mark.a.biggar@lmco.com