ACT announces availability of GNAT 3.14p

ACT announces availability of GNAT 3.14p

[Robert Dewar]

Ada Core Technologies (ACT) has made available at the NYU
site (ftp://cs.nyu.edu/pub/gnat) GNAT 3.14p builds for the
following targets:

MS Windows (NT/2K)
Sparc Solaris (2.5.1 through 2.8)
GNU Linux (Redhat 6.2)

The above are the official platforms, but in practice the
NT version works reasonable well on Win 98 and Win ME and
other versions of GNU Linux including Debian GNU/Linux are
known to be compatible with this version of GNAT.

These are the only public versions that ACT plans to build.
As always, the releases contain the full sources, and we
invite volunteers to create builds for other platforms.  We
also draw attention to the availability of source snapshots
for the current development version of GNAT (similar to the
3.15 release, but on GCC 3, rather than GCC 2).  The above
public versions are still based on ACT's 2.8.1 GCC version.

These versions are provided without any warranty or
guarantee of any kind, and no support of any kind is
available for these public versions from ACT.  They are
provided as a service for use by students, hobbyists and
researchers who need access to a high quality Ada 95
system.

If you need a supported commercial Ada 95 compiler, we
recommend the use of our GNAT Pro product.  In particular,
we do not recommend the use of the public version for
formal evaluation purposes. Contact sales@gnat.com
or sales@act-europe.fr for further details on GNAT Pro, 
including the availability of evaluation versions.

Robert Dewar
Ada Core Technologies


The following is a list of new features available in 3.14
as compared with 3.13.

GNAT 3.14p NEW FEATURES LIST
============================

Copyright (c) 2001, Ada Core Technologies

This file contains a complete list of new features in
version 3.14p of GNAT.  A full description of all GNAT
features can be found in the GNAT User Guide and GNAT
Reference Manual.

NF-314-5827-001 New -u switch for gnatmake

The command gnatmake -u only recompiles the main file when
needed.  Gnatmake can now be used as the main and only
interface to the compiler since a single compilation can be
launched with "gnatmake -u -f".

NF-314-6806-001 Source reference pragmas read by gnatchop

The gnatchop utility now recognizes and respects existing
source reference pragmas that it finds in the input file,
so that the output files always properly reflect the
original source file.

NF-314-6813-011 Asis queries to evaluate static expressions

A new set of queries is added to package Asis.Extensions.
These queries allows an ASIS application to evaluate the
value of a discrete static expressions and to get the low
and high bound of a static 'Range attribute.  The results
are returned as string images of expression values, The
'Pos value is returned for enumeration expressions.  See
specification of Asis.Extensions for more details.

NF-314-7001-006 Better messages on non-visible entities

The warnings for non-visible entities have been improved to
exclude implicit entities, and entities declared in the
private part of GNAT internal units.  This results in more
helpful error messages for undefined variables.

NF-314-7008-003 New package GNAT.Sockets

This package provides a high level interface to the sockets
API.  Most of the features are implemented.  This high
level and portable interface is based on the
GNAT.Sockets.Thin API which is a thin binding to the OS
sockets API.

NF-314-7110-008 New package GNAT.Most_Recent_Exception

This package provides subprograms giving access to the
exception occurrence, or exception occurrence access for
the most recently raised exception.  Unlike the routines in
GNAT.Current_Exceptions, these routines do not have to be
called statically from within an exception handler.

NF-314-7207-004 Issue error for bad Source_Reference pragma

The Source_Reference pragma is (and always has been)
required to be the first line of the file.  This is now
clearly documented, and a diagnostic is issued if the first
Source_Reference pragma is not the first line in the file.

NF-314-7207-006 Warn when Duration unexpectedly used

A new warning has been added when a universal fixed
expression is interpreted as type Standard.Duration.
Although this is correct according to RM semantics, it is
almost always suspicious and represents an unintended
meaning.

NF-314-7215-008 Improve msg for missing WITH of predef unit

The error message handling for cases of forgotten WITH's of
predefined library routines has been improved.

NF-314-7314-004 Remove useless initialization checks

Initialization procedures for arrays were doing unnecessary
subscript range checks, that have now been suppressed,
since an out of range condition is impossible in this
context.

NF-314-7418-008 New switch for gnatchop to exit on errors

The new -x gnatchop switch causes gnatchop to exit on
detecting parse errors.  Now gnatchop also sets the exit
status to indicate errors.

NF-314-7506-010 Improve message for access param comparison

A comparison of an access parameter with null is illegal.
This was always caught by GNAT but with a confusing error
message that complained about the types of the operands.
Now a specific error mesage is given pointing out that it
is not allowed for an access parameter to be null in the
first place.

NF-314-7509-002 Improve warning for possibly null values

The warning for possibly null values has been improved to
be more precise and to catch some previously uncaught
cases.

NF-314-7515-007 Multiple Source_Reference pragmas allowed

It is now permitted for a single file to have more than one
Source_Reference pragma.  All pragmas must refer to the
same original file, but the sections referenced need not be
contiguous.  This permits correct processing of files with
configuration pragmas that are chopped using gnatchop with
the -c and -r switches.

NF-314-7516-012 Better warning messages for Storage_Error

In some cases, a warning about possible storage error was
posted on the offending statement in a generic template.
Now the message is always on the relevant instantiation
with a pointer to the generic template location.

NF-314-7524-009 GNAT version string is in executable

The executable now contains a string identifying the GNAT
version in the form "GNAT Version:  xxx(xxx)" where
xxx(xxx) is the version number.  The external name of this
constant is __gnat_version.

NF-314-7530-009 Consistency checking for -gnatE mode

Units compiled with -gnatE and without -gnatE can be mixed
under certain conditions, now properly documented in the
GNAT Users Guide.  The binder now checks that the rules for
safe mixing are properly followed.

NF-314-7606-012 Improve equality ambiguity error messages

In the case of ambiguous operands for equality, -gnatf now
gives details on the possible resolutions discovered by the
compiler, making it easy to diagnose the cause of this
error in non-obvious situations.

NF-314-7607-007 Improved control for NT temporary files

Under NT, it is now possible to control where temporary
files are created.  First, the TMP environment variable is
checked, and if this is set, it specifies the directory to
be used.  If TMP is not set, then c:\temp is used.  If both
of these checks fail, then, and only then, is the current
working directory used.

NF-314-7611-007 Warnings for WITH of internal GNAT unit

The only units that should be WITH'ed by application
programs are those that are documented in the RM or in the
GNAT documentation.  Any WITH of an internal GNAT
implementation unit not documented in one of these two
locations now generates a warning.  This warning can be
controlled individually by use of the -gnatwi/-gnatwI
switches.  It is on by default.

NF-314-7614-005 Avoid use of a-types.h in runtime

The use of a-types.h is now avoided in building the runtime
library.  This reduces unnecessary symbol table and debug
information

NF-314-7619-008 Access to source related information

A new package GNAT.Source_Info provides some useful utility
subprograms that provide access to source code informations
known at compile time, such as file name, line number and
enclosing entity.

NF-314-7620-002 More flexible source file naming

The Source_File_Name pragma has been enhanced so that it
can provide general pattern driven rules for constructing
file names.  The scheme is powerful enough to accomodate
all common schemes for deriving file names from unit name
that we are aware of, and in particular it supports
standard schemes used by other Ada 95 compilers.  This
means that for most purposes the large set of
Source_File_Name pragmas can be replaced by two pragmas,
giving pattern rules for bodies and specs.

NF-314-7622-004 New packages for CGI programming

A new package GNAT.CGI provides basic services for CGI
(Common Gateway Interface) programming.  A subsidiary
package GNAT.CGI.Cookies provides facilities for dealing
with "cookies" (data kept in Web client software).  A third
package GNAT.CGI.Debug provides debugging facilities.
Between them, these packages enable an easy interface for
Web programming from Ada.

NF-314-7626-013 Automatic backtraces during exception
handling

A new package GNAT.Exception_Traces is now available for
platforms on which the backtrace features is implemented.
This provides a feature for enabling automatic output of
backtraces upon exception occurrences.  Two options are
available, enabling traces either for every occurrence or
only for occurrences that are not caught by a user defined
handler.  The latter is typically useful to get traces when
a task dies because of an unhandled exception.
 
NF-314-7708-001 New Setenv procedure in GNAT.OS_Lib.

A procedure Setenv has been added in GNAT.OS_Lib.  This
procedure can be used to add or remove environment
variables for the current and child process.  This is not
yet supported under VMS, but is fully supported for all
other GNAT ports.

NF-314-7709-004 New unit GNAT.AWK (AWK style file parsing)

A new package GNAT.AWK (file g-awk.ads) provides AWK-like
file parsing with an easy interface for parsing one or more
files containing formatted data.  The file is viewed as a
database where each record is a line and a field is a data
element in this line.

NF-314-7711-001 New function Paren_Count in GNAT.Regpat

A new function Paren_Count is now provided in GNAT.Regpat
to return the maximum number of parentheses pairs in the
compiled regular-expression.

NF-314-7712-005 Support for honoring gcc -fno-common

The -fno-common gcc command line option is now recognized.
The use of this option causes the allocation of
uninitialized global variables to be moved to the bss
section of the object file, rather than generating them as
common blocks.  This solves problems caused by the presence
of a symbol both in a library and in an explicitly linked
object file.

NF-314-7713-002 Improved error message placement

The error message noting that only subtype marks can be
used in a generic array formal are now more accurately
placed and point specifically to the offending construct.

NF-314-7713-003 Front-end inlining

The -gnatN switch enables front-end inlining.  In this
compilation mode, the front-end replaces a call to a
subprogram that has an Inline pragma by the expanded body
of the subprogram, provided the body is short enough.  This
supplements the inlining performed by the GCC back-end.

NF-314-7717-001 Task_Name pragma provided to set task name

A new pragma Task_Name can be used in a task definition to
specify the name used for a task for debugging purposes and
by Ada.Task_Identification.Image.  The argument is the task
name, and can be an expression referencing the task
discriminants, allowing different names to be given to
different instances of the same task type.
 
NF-314-7718-001 Linker_Options extensions now documented

The documentation (GNAT Reference Manual) has been enhanced
to contain full documentation of the GNAT implementation of
the Linker_Options pragma.  GNAT allows multiple arguments,
and also allows the use of ASCII.NUL to separate arguments
in a single string.

NF-314-7718-003 New warning option to detect hiding

New flags -gnatwh/-gnatWH are provided to enable/disable
checking for the case where an inner entity hides an outer
one.  This is of course legal, but in some environments
such hiding is discouraged, and this warning option (which
is by default off) can be used to enforce this requirement.
Note that the common case of one character identifiers such
as I,J,K is excluded from consideration.

NF-314-7721-002 Improved range analysis for subtraction

The circuit for range analysis for subtraction has been
enhanced.  This eliminates some range checks, and some
additional warnings at compile time for cases where the
result is known to be out of range.

NF-314-7721-003 Implement range analysis 'Length

Range analysis for the Length attribute has been added,
resulting in elimination of some range checks, and also
some additional warnings at compile time for cases where
the result is known to be out of range

NF-314-7722-016 Improved error msg for name conflict

The error message for a conflict between an enumeration
literal and a later declared constant of the same name has
been improved.

NF-314-7723-005 GLIDE xref works even if compile errors

The new switch -gnatQ can be used to force generation of an
ALI file even if there are compile errors.  This is most
useful in connection with GLIDE and similar tools, since it
means that cross-reference information is available even
after compiler errors.

NF-314-7723-012 Unreferenced labels generate warnings

In -gnatwu mode, GNAT now diagnoses labels that are not
referenced other than by their initial occurrence.

NF-314-7731-012 New unit GNAT.Dynamic_Tables

A new package GNAT.Dynamic_Tables provides a resizable
one-dimensional array.  It is similar to GNAT.Table except
that the table type is a declared type, so that it can be
used in more general contexts.

NF-314-7801-005 Warning for aliased discriminanted objects

GNAT now generates a warning for an assignment to an
aliased discriminated object that is known to generate a
constraint error at run time.

NF-314-7802-002 GLIDE can go to any file in error message

When an error message from the compiler includes several
file:line references, it is now possible to click on any of
them to display the appropriate file, instead of just the
first one.

NF-314-7814-013 x86 stack traceback for foreign threads

Under x86 targets it is possible to get the stack traceback
through a foreign thread.  This is true for unhandled
exceptions and for GNAT.Traceback services.

NF-314-7817-001 GNAT now compatible with Solaris 2.8

GNAT is now fully compatible with Solaris 2.8.  This
includes proper building and operation of the florist
package (which did need some modifications to be 2.8
compatible).

NF-314-7820-008 Better 'Valid handling for large subtypes

If an object of a discrete type has a larger size than the
base type (e.g.  from the use of a component clause in a
record representation clause), then 'Valid will check all
the bits of the object (previously the code simply use part
of the field, which was an allowable implementation
according to the RM, but nevertheless surprising).

NF-314-7821-010 ASIS tutorial is available

A simple hands-on ASIS tutorial is added to the ASIS
distribution.  It consists of two parts.  One part is based
on the asistant tool and the task is to get the initial
experience with using ASIS queries.  Another part is based
on the ASIS application templates and the task is to
implement simple ASIS tools starting from these templates.
For all the tasks full documented solutions are provided.

NF-314-7821-008 ASIS application templates are available

A set of ASIS application templates is added as a part of
the ASIS distribution.  This set contains the Ada
components which are the same or very similar for many
ASIS-based tools.  These templates may be used as a "quick
start" for ASIS beginners.

NF-314-7822-009 Dynamic elaboration checks improved

Elaboration checks are suppressed for calls to subprograms
in packages to which a pragma Elaborate applies.  The cases
of Elaborate_All and Elaborate_Body already suppressed the
check, but checks were not suppressed for Elaborate.

NF-314-7826-009 gnatdll supports binder arguments

Gnatdll now supports the -bargs parameter passing arguments
to the binder.  For example, this can be used to build a
DLL with stack tracebacks stored in the exception
occurences (gnatbind -E option).

NF-314-7826-010 pragma Comment restriction removed

The placement of pragma Comment is now unrestricted.  This
pragma can appear anywhere within the main unit, including
as the first line of the file.

NF-314-7827-011 Control of warnings for address overlays

The warning switch -gnatwo turns on overlay warnings for
address clauses where implict initialization can cause the
overlaid memory to be clobbered.  The swich -gnatwO turns
off these warnings.  The warnings have been implemented for
a while.  What is new is allowing them to be selectively
turned off (the default is that this warning is enabled).

NF-314-7829-002 Control over validity checking is provided

GNAT now provides a new switch -gnatVx that allows you to
control the level of validity checking.  The options are
n/d/f for none/default/full.  None means no checking for
invalid data, default (which is the default setting)
provides sufficient checking to meet the requirements of
the RM, and full provides extensive validity checking,
particularly useful when used with Normalize_Scalars.

NF-314-7829-003 New warning for hiding loop variables

A common mistake for those familiar with other languages is
to fail to realize that a for loop implicitly declares the
loop variable, and programmers provide a useless and unused
outer level variable definition with the same name.  GNAT
now specifically detects this situation and provides an
explicit warning.

NF-314-7830-008 ASIS Corresponding_Name_Definition_List

The Asis.Expressions.Corresponding_Name_Definition_List
query in ASIS for GNAT is now fully implemented.

NF-314-7830-014 New warning for overlay by access type

The warning for possible unexpected initialization has been
extended to include access types.  The warning is generated
if an access type has an address clause causing overlay,
and there is no pragma Import, so that initialization to
null will take place.  Note that NF-314-7827-011 gives the
capability of controlling such warnings.  Note also that
GNAT 3.13p had a (now corrected error) that caused such
expected initializations to be omitted.

NF-314-7906-017 New package Ada.Interrupts.Signal

A new package Ada.Interrupts.Signal (file a-intsig.ads) has
been created to provide an easier and more portable way of
generating Ada95 interrupts.

NF-314-7910-004 Uniform behavior for Slice subprograms

In packages Ada.Strings.Bounded/Ada.Strings.Unbounded, the
Slice function now returns with the bounds of the slice
expressions, rather than with a lower bound of 1. This was
discussed in the ISO WG9 ARG, and it was agreed that this
was the preferable approach.  This change also improves the
efficiency of these two functions.

NF-314-7914-009 Optimization for object declarations

If an object is declared with an unconstrained nominal type
and the expression is a function call, it is in general
necessary to compute the result of the call first and then
copy that result into the object, after deter- mining the
bounds.  GNAT now suppresses that copy in many cases.  The
copy is still used if the type is controlled, if it is
classwide, or if the object is declared at the library
level.

NF-314-7918-012 Enhanced variant of Spawn in GNAT.OS_Lib

In the package GNAT.OS_Lib, a new Spawn function now
returns the exit status of the executed command as an
Integer value.  The existing Spawn procedure only gives a
boolean result.

NF-314-7924-003 Immediate output switch (-gnate) replaced

The immediate output switch -gnate is no longer defined,
reflecting the fact that this is intended only for use in
diagnostic mode following a compiler crash.  In those cases
where this is needed, the effect can be obtained by use of
the -gnatdO debug switch.  The purpose of this change is to
avoid accidental use of this switch, which disables many
useful error message circuits.

NF-314-7925-003 Protected types visible in entities menu

In addition to subprograms, types and tasks, the entities
menu in GLIDE now includes an entry for protected objects
and types.  This is also available in the speedbar panel.

NF-314-7926-006 Allow SPARK annotations in -gnatyc mode

The -gnatyc mode now allows comments starting with --x
where x is any special character in the lower half of the
ASCII range (16#21#..16#2F#,16#3A#..16#3F#).  This in
particular allows the --# comments that appear as
annotations in the Praxis SPARK language.

NF-314-7929-004 Value_Size and Object_Size output by -gnatR

The -gnatR switch now outputs Value_Size and Object_Size
separately for types where these two values are different.
If the values are the same, then the output simply lists
this common value as the Size value.

NF-314-7930-001 Value_Size and Object_Size for all types.

The Value_Size and Object_Size can now be separately
specified for composite types (records and arrays).  The
meaning is as for scalar types.  The Value_Size is used for
unchecked conversion and packing purposes, and the
Object_Size is used for allocation of objects.

NF-314-7930-006 New attribute Standard'Wchar_T_Size

This attribute returns the size of the C type wchar_t,
which may differ from the Ada Wide_Character type.  The
attribute is primarily intended for the construction of the
wchar_t type in Interfaces.C.

NF-314-7930-007 Changed children of System to be pure

Many more packages in the System hierarchy have been marked
pure.  This change documents that the functions in those
packages are in fact side-effect free, which gives the
compiler more optimization opportunities.

NF-314-7931-001 Additional in-place assignments for
aggregates

Assignments of the form:  S (1 .. N) := (others => Expr);
are now performed in place, without generating a temporary
for the aggregate (as long as Expr is independent of S, of
course).  In addition, array assignments where the
right-hand side is an aggregate with only an others clause
are performed in place even if the bounds of the array are
non-static.

NF-314-7931-002 Improved handling of enumeration image
tables

The handling of enumeration type image tables (for support
of the Value, Image, and Width attributes for enumeration
types has been improved).  The tables are now generated
statically, and are significantly smaller than they were
previously (1-4 bytes overhead per entry instead of 12-15).

NF-314-7931-003 NT Win32Ada binding reformatted for -gnaty

The sources of Win32Ada binding were reformatted to meet
the style requirements for compiling with the -gnaty
switch.

NF-314-8001-002 The -gnatg switch is now fully documented

The -gnatg switch is the GNAT internal implementation
switch.  It is intended only for use by GNAT itself.  The
documentation now fully describes this switch and explains
why it should not be used by application programs.

NF-314-8004-004 Unchecked_Conversion now fully documented

The GNAT Reference Manual now contains complete
documentation on the approach used by GNAT in handling
unchecked conversions where the sizes of the source and
target types are different.

NF-314-8006-002 Improved output for representation
information

The -gnatR switch now takes an optional parameter which can
have the value 0,1,2.  No representation output is
generated in -gnatR0 mode.  In -gnatR1 (same as -gnatR),
representation information is generated for arrays and
records.  For -gnatR2, representation information for all
user declared types and objects is generated.

NF-314-8010-003 Detect duplicate Value/Object_Size clauses

The appearence of more than one Value_Size or Object_Size
clause for a single entity, which was previously allowed
(with the earlier one being ignored), is now detected as an
error, which seems more appropriate and more consistent
with the treatment of duplicate Size clauses.

NF-314-8010-005 Spell checking in GLIDE

The standard ispell command can now be used to spell check
the comments while editing an Ada source file.  The
checking only applies to comments and not to Ada source
code other than comments.

NF-314-8010-012 More flexible GNAT.Threads.Create_Thread

Create_Thread now returns the task id so that this value is
easily known on the client side.

NF-314-8012-002 New warning for unexpected rounding

Warn in cases where the static evaluation rules of Ada as
described in RM 4.9(38) result in different rounding than
would have been obtained at runtime.  This rule is a rather
surprising one, and has caused confusion in the past.
 
NF-314-8014-002 Additional information on unused entities

Warning messages on unused entities (generated by compiling
with -gnatwu) now indicate the kind (variable, function,
etc) of the entity to which the warning applies.

Cross-references are now generated when an entity appears
as a default actual in an instantiation.  This inhibits
warnings if the entity is not used explicitly elsewhere,
and is also used by tools that rely on xref information
(e.g.  GLIDE).

NF-314-8019-001 Documentation on variant object size

An extensive section has been added to the GNAT Reference
manual describing how GNAT treats the Size attribute when
applied to variant record objects.

NF-314-8022-004 Improved documentation for -gnato switch

More extensive documentation is provided for the -gnato
switch that enables overflow checking, emphasizing that
overflow checking is off by default, and explaining the
rationale behind treating overflow checks differently from
other kinds of range checks.

NF-314-8023-003 Document Size Limit

GNAT enforces a maximum Size of objects of 2**31-1, which
since Size is in bits, corresponds to a size of 256
megabytes.  This limit has always been enforced, but it is
now properly documented in the GNAT Reference Manual.

NF-314-8023-005 Improved documentation for GNAT.Task_Lock

The documentation for GNAT.Task_Lock has been enhanced to
make it clear that calling Lock multiple times from the
same task works as expected for nested use of Lock/Unlock.

NF-314-8024-002 C_Pass_By_Copy convention now standardized

The implementation of the C_Pass_By_Copy convention has
been modified to be consistent with the agreed
specification in AI95-00131, which is part of the official
technical corrigendum for Ada 95.  For GNAT, the
modification is that now C_Pass_By_Copy is rejected for any
entities other than record types and subtypes.  Convention
C can always be used instead for other entities (GNAT used
to treat C_Pass_By_Copy as identical to C for other
entities).

NF-314-8025-009 Documentation of GNAT Library Units

The GNAT Reference Manual now contains complete reference
documentation for all GNAT specific units in the GNAT,
System, Interfaces, and System.  This includes several
units that have been present in GNAT, but not previously
documented, including System.Address_Image (to convert
Address values to strings) and Ada.Command_Line.Remove (for
logically removing command line arguments).

NF-314-8028-002 SIGUSR1/SIGUSR2 now handled in GNU/Linux

Using native threads (aka LinuxThreads), it was not
possible to handle the SIGUSR1 and SIGUSR2 signals.  This
limitation has now been removed.  This change affects all
versions of GNAT for GNU/Linux including Debian GNU/Linux
and also Redhat Linux.

NF-314-8030-011 New style-check for exit of named loop

The -gnatye switch now includes checking for missing exit
labels.  It will now cause a warning to be posted if an
exit statement appears which refers to a labeled loop but
the statement does not include the label.

NF-314-8030-014 Improved output from gnatbind -e switch

The output now excludes all output for gnat internal units.
The dependency information for internal units is of
interest only for implementors, and tends to be voluminous
and useless for normal use.  A -de debug flag is introduced
to provide the old behavior for system implementors use.

NF-314-8031-012 More extensive misspelling warnings

The error messages for undefined variables now include
additional cases where a suggestion of a possible
misspelling is provided.  This message now includes cases
where the entity is in a with'ed package and has explicit
qualification.

NF-314-8031-013 Nested package bodies included in -gnatR

The output from the -gnatR switch now includes declarations
that appear in nested package bodies.

NF-314-8031-019 Clear labeling of output in -gnatR output

The output from the -gnatR switch now makes it clear
whether the unit for which representation information is
listed is a spec or a body.

NF-314-8101-005 Alignment warnings for bad address clauses

It is the program's responsibility to ensure that the value
in an address clause is consistent with (i.e.  a multiple
of) the alignment of the object to which it is applied, and
in general this cannot be checked at compile time.  However
it is possible to post warnings in some cases where the
value is known at compile time and is clearly wrong, and
this is now done.

NF-314-8104-007 New Glide variable
ada-prj-gnatfind-switches

This variable can be customized to change the default
switches used for gnatfind when you select the menu item
"Show All References".  For example this can be used to add
the -a switch, in case you often work with read-only ALI
files.

NF-314-8105-007 New convention Win32 equivalent to Stdcall

The convention Win32 is now recognized as equivalent to
Stdcall or DLL (all three conventions are identical in
effect and considered to be conformant).  This eases
porting of code from other compilers that use this
convention name.

NF-314-8106-010 New unit Ada.Exceptions.Is_Null_Occurrence

This GNAT addition to the Ada hierarchy allows a program to
test if an occurrence is the null occurrence
(Null_Occurrence) without enerating an exception.  This
capability is not present in the predefined subprograms in
Ada.Exceptions.

NF-314-8106-010 Warnings for useless type conversions

A warning can be generated for type conversions of the form
a(b) where b is a simple entity name which is of type a
(i.e.  the conversion has no effect).  This warning is
normally off but can be set on by the use of
@code{-gnatwr}.

NF-314-8106-011 Warnings for useless assignments

A warning can be generated for assignments of the form a :=
a; (i.e.  assignments of a variable to itself) which are
obviously useless.  This warning is normally off but can be
set on by the use of @code{-gnatwr}.
 
NF-314-8108-006 Warnings for accidental hiding by child
unit

A warning is generated when a child unit in the context of
a parent hides a compilation unit of the same name.  For
example, Foo.Ada, if it appears in the context of the body
of Foo, will hide an occurrence of the predefined Ada in
the same context, which can lead to surprising visibility
errors later on.

NF-314-8108-004 Better error messages for bad array
aggregate

If an array aggregate is missing elements (e.g.  it has the
index values 1,2,8,9 and is missing 3 .. 7), the error
messages will now give a full list of missing values.
 
NF-314-8114-002 Named numbers included in -gnatwu check

The warning option -gnatwu (check unreferenced entities)
now includes named numbers, so unreferenced named numbers
will now also cause warnings to be generated.

NF-314-8114-016 Better msg placement for with'ed unit not
found

In some cases, the error message for a WITH that directly
or indirectly lead to a file not found could be placed on a
location other than the WITH statement.  It is now always
placed in the most convenient place.

NF-314-8116-001 Support for wide char to string conversions

The library units System.Wch_Con and System.Wch_Cnv provide
a method for converting between wide characters and the
corresponding string representation, using any of the
implemented methods for encoding.

NF-314-8118-003 Backtrace decorators for automatic
backtraces

GNAT.Exception_Traces now includes a backtrace decoration
facility, allowing customization of the way the set of
addresses for a backtrace is output.  A typical use of this
feature is to provide a function that returns the symbolic
information associated with each address, as computed by
GNAT.Traceback.Symbolic.

NF-314-8120-006 Improved dead code detection

The warning circuitry for unreachable code has been
improved.  Now an IF or CASE statement, all of whose
statement sequence end with some transfer of control is
recognized, and code after such a statement is flagged as
dead code with an appropriate warning.

NF-314-8127-007 Improved parser error messages

Some improvements in parser error messages have been made.
If "|" is used in an expression in an inappropriate manner,
the parser suggests that "or" may have been intended.  If a
component is declared in the visible part of a protected
object, the diagnostic reminds that such components can
only be in the private part.

NF-314-8203-008 Default thread library is now LinuxThreads

Under the GNU/Linux operating system, the default tasking
run time is now based on the native LinuxThreads library.
The alternate FSU threads implementation is still available
as an alternative (see file README.TASKING for more
details).  This change applies to all versions of GNU
Linux, including Redhat Linux.

NF-314-8205-001 New package Ada.Characters.Wide_Latin_1

This package provides definitions analogous to those in the
RM defined package Ada.Characters.Latin_1 except that the
type of the constants is Wide_Character instead of
Character.  The provision of this package is in accordance
with RM (A.3(27)).  Note:  this package has been available
for some time, but was not properly documented, so from a
formal point of view was not available to application
programs, but now it is a first class citizen which is
fully documented.

NF-314-8213-003 More flexible placing of address clause

Previously when an address clause and Import pragma were
given for a subprogram, the pragma was required to be given
first.  There is now no restriction on the ordering.
 
NF-314-8214-004 Style violations are now warnings not
errors

Style errors resulting from the use of a pragma Style_Check
or the -gnaty flag are now treated as warnings rather than
errors, which means that an object file can be created if
there are no other errors, and that also the compiler will
find semantic problems even if there are syntactic style
errors.  If the previous behavior of treating these as
errors is desired, the -gnatwe flag can be used.

NF-314-8218-005 New Elaboration_Checks pragma

A new configuration pragma Elaboration_Checks can be used
to select the RM dynamic model of elaboration or the GNAT
default static model.  This may be used in gnat.adc for
partition wide application, or within sources for unit by
unit control.  See also feature NF-314-7530-009.

NF-314-8218-009 More efficient memory allocation

The GNAT run-time file a-raise.c can now easily be
recompiled with lock suppression to improve the efficiency
of memory allocation and deallocation if certain conditions
are met.  See the comment on NO_LOCK in a-raise.c itself
for details.

NF-314-8220-005 Generic sort packages in GNAT now Pure

The units GNAT.Heap_Sort_G (g-hesorg.ads),
GNAT.Bubble_Sort_G (g-busorg.ads) are now Pure instead of
Preelaborate, allowing them to be with'ed and instantiated
by Pure clients.

NF-314-8220-006 Automatic float control for Float
Input-Output

Floating-point conversion in Text_IO no longer relies on
the floating-point processor being correctly set.  This
means that the need for explicit calls to GNAT.Float_Reset
is limited to programs which explicitly use
Long_Long_Float.  This feature is especially helpful on NT,
where system services of all kinds seem to reset the
floating-processor into low precision mode.

NF-314-8225-001 Project file capability for gnatmake

The gnatmake utility is now project file aware, and can be
used with the new GNAT Project Files (see new documentation
section in the users guide).  It now accepts the new
switches -Pproject, -vPx and -Xname=value.

NF-314-8226-007 Better handling of invalid enum opnds for
Image

The Image function for enumeration types yielded rubbish
strings for abnormal and invalid operands (e.g.  created by
unchecked conversions).  A validity check (subject to
control by the -gnatV switch) is now performed so that an
exception (Constraint_Error) is raised for an invalid
operand.

NF-314-8230-001 Style check option for ordered subprograms

The -gnatyo switch (ORDERED_SUBPROGRAMS in the VMS version)
activates a style check that subprogram bodies within a
given scope (e.g.  a package body) must be in alphabetical
order.

NF-314-8302-004 Project file capability for gnatls

The gnatls utility is now project aware, and can be used
with the new GNAT Project Files (see new documentation
section in the users guide).  It now accepts the new
switches -Pproject, -vPx and -Xname=value.

NF-314-8304-001 RPM packages are now provided for GNU/Linux

Under GNU/Linux, GNAT is now provided as either a
compressed tar file as before, or as RPM packages which
means that the installation is simplified on various
versions of GNU/Linux, including Redhat Linux, and Debian
GNU/Linux.

NF-314-8305-003 Better folding of attributes of objects

The Alignment, Size, First, Last, Length, and
Component_Size attributes applied to objects are now
treated as compile time constants if the value can be
determined by the front end.

NF-314-8317-003 Floating-point range checks now catch
NaN's.

In GNAT, Machine_Overflows is False for floating-point
types, which means that operations such as 0.0/0.0 can
generate NaN's.  The RM does not require that NaN's be
caught by subsequent range checks, but it is certainly
convenient if this is the case, and GNAT has now been
modified so that NaN's will always fail any range check and
cause Constraint_Error to be raised.

NF-314-8322-016 Program units now distinguished by gnatxref

The cross-reference section of the ali file now
distinguishes between generic and non-generic units, and
between functions, packages and procedures.  The gnatxref
utility has been enhanced to take advantage of this new
information and now distinguishes these different kinds of
units in identification of entities.

NF-314-8323-004 Additional documentation on elaboration
issues.

A new section has been added to the users guide, entitled
"Additional Elaboration Order Considerations", which
discusses the issue of elaboration ordering requirements
that are not dictated by the language, but rather arise out
of extra-lingual logic requirements of the program.

NF-314-8328-012 Better handling of max size of variant
record
   
If a discriminant range is wider than it needs to be (e.g.
we have a Natural discriminant, which is used as the upper
bound of an array whose maximum bound is 10), then GNAT now
uses the maximum array bound in computing the maximum size
of the record, at least in most simple cases.  In any case
it is a good idea to use a discriminant range that reflects
the range of actual valid values.

NF-314-8330-008 End positions of constructs now in ali file

The cross-reference information in the ALI file now
includes all labels on END lines, and also marks the end of
specs and bodies of tasks, subprograms, packages, protected
types, blocks, loops, entries and accept bodies.  This
information is provided in the output from gnatxref.

NF-314-8407-012 Objects and types distinguished by gnatxref

The cross-reference output output by gnatxref distinguishes
type and object entities (for example an entity is labeled
as an "integer type" or "integer object", rather than
simply being identified as "Type:  integer" in both cases).

NF-314-8409-001 Tree output can be forced with -gnatQ
-gnatt

It is now possible to force tree output using a combination
of the -gnatQ and -gnatt switches (it may also be
appropriate to use -gnatq in this context).  This allows
the use of ASIS on some illegal programs, though if the
error is severe enough to cause a malformed tree, ASIS may
blow up when presented such a tree.

NF-314-8411-002 Boolean types now distinguished by gnatxref

The cross-reference section of the ali file now
distinguishes between boolean types and other enumeration
types, and the gnatxref utility has been enhanced to take
advantage of this new information and now distinguishes
these types in the entity identification information.

NF-314-8412-006 New option for gnatlink for object list
file

The switch -f for gnatlink forces the generation of a
separate file containing a list of objects for the linker,
even if the threshhold for command line length is not
exceeded.  This is useful to get around some cases of
unexpectedly exceeding this limit (e.g.  due to system
environment issues that reduce the limit).  The switch can
only be used on targets for which linker object list files
are implemented.  In addition the limit for generation of
such files on Tru Unix (Alpha) has been reduced to 10_000,
since on some systems the previous limit (30_000) was too
high.

NF-314-8412-010 New file routines in GNAT.OS_Lib

A new routine has been added into GNAT.OS_Lib to rename a
file.  All routines dealing with files now have two
implementations:  one using the String type and one using
an address to specify the filename.  This is a general
clean up to fix inconsistencies.

NF-314-8413-005 Stream size now taken from first subtype

Previously GNAT was using the size of the base type to
determine the number of storage units for use by stream
routines for elementary types.  This is now changed to meet
the new recommendations of AI-195, which suggest using the
size of the first subtype.  GNAT now uses the size of the
first subtype for this determination.

NF-314-8420-006 New tasking run time under Solaris

Under Solaris Sparc, GNAT now comes with a new tasking run
time based on posix threads (rts-pthread).  This run time
has the advantage of being mostly shared across all POSIX
compliant thread implementations, and also provides under
Solaris 8 the semantics of PTHREAD_PRIO_PROTECT and
PTHREAD_PRIO_INHERIT.  The predefined Ceiling_Locking
policy for pragma Locking_Policy is used to specify
PTHREAD_PRIO_PROTECT, and a new implementation defined
policy, Inheritance_Locking, can be used to specify the use
of PTHREAD_PRIO_INHERIT.

NF-314-8430-004 Enhanced style checking for references

For cases in which there is a separate body entity
(packages, subprograms, entries, tasks, protected types,
accept statements, subprogram formals), the switch -gnatyr
now checks the casing of the body entity to make sure that
it is the same as that of the spec entity.

NF-314-8509-011 New package GNAT.Expect

This package provides a set of subprograms similar to what
is available with the standard Tcl Expect tool, allowing
you to easily spawn and communicate with an external
process.  You can use this package to send commands or
inputs to the process, and compare the output with some
expected regular expression.

NF-314-8514-003 Improved error message for access
discriminants

When declaring a self-referential structure as a limited
record that contains a discriminated component that points
to the enclosing record, a common mistake is to define the
type of the component as having a discriminant with a
general access type, rather than as a proper access
discriminant.  This results in an accessibility violation
(RM 3.10.2 (21)).  The new message indicates that the error
is in the discriminant declaration itself.

NF-314-8522-001 Solaris programs do not depend on
libthread.so

On the Solaris operating system, for programs that do not
use tasking, the generated executables no longer depend on
libthread.so so that a link can be successfuly completed
without requiring this library to be present.

NF-314-8526-003 Record'Size evaluated at compile time

In the case where the size of a record type is specified
using a size representation attribute clause, the front end
now folds the attribute reference at compile time.  The
result is still not a static expression, but the quality of
code is improved, and in addition, representation clauses
(such as component clauses) that require values and types
to be statically known at compile time are permitted in
additional cases as a result of this change.

Re: ACT announces availability of GNAT 3.14p

[Christoph Grein]

> NF-314-7926-006 Allow SPARK annotations in -gnatyc mode
> 
> The -gnatyc mode now allows comments starting with --x
> where x is any special character in the lower half of the
> ASCII range (16#21#..16#2F#,16#3A#..16#3F#).  This in
> particular allows the --# comments that appear as
> annotations in the Praxis SPARK language.

Why are the other characters 16#40#, 16#5B#..16#5F#, 16#7B#..16#7E#
not allowed?

(Gnat must be very bad product if it needs sooooo many enhancements:-)

Re: ACT announces availability of GNAT 3.14p

[Leon Winslow]

Robert Dewar wrote:

> Ada Core Technologies (ACT) has made available at the NYU
> site (ftp://cs.nyu.edu/pub/gnat) GNAT 3.14p builds for the
> following targets:
>
> MS Windows (NT/2K)
> Sparc Solaris (2.5.1 through 2.8)
> GNU Linux (Redhat 6.2)
>
> The above are the official platforms, but in practice the
> NT version works reasonable well on Win 98 and Win ME and
> other versions of GNU Linux including Debian GNU/Linux are
> known to be compatible with this version of GNAT.
>
> These are the only public versions that ACT plans to build.
> As always, the releases contain the full sources, and we
> invite volunteers to create builds for other platforms.  We
> also draw attention to the availability of source snapshots
> for the current development version of GNAT (similar to the
> 3.15 release, but on GCC 3, rather than GCC 2).  The above
> public versions are still based on ACT's 2.8.1 GCC version.
>
> These versions are provided without any warranty or
> guarantee of any kind, and no support of any kind is
> available for these public versions from ACT.  They are
> provided as a service for use by students, hobbyists and
> researchers who need access to a high quality Ada 95
> system.
>
> handling

I can understand the reason for limiting ACTs work to Windows NT, but
this is also one of the  reason that Ada is "sliding into oblivion."
The majority of the programming is being done on Windows platforms other
than NT and 2K.  (MS has already announced dates for dropping all suport
of these two platforms.).  A compiler that works "reasonably well" in
W98, XP or Me is never going to be used on those platforms for any
serious work.

Alas, I knew Ada well and hate to see it go down hill, but ....

Lee Winslow

Re: ACT announces availability of GNAT 3.14p

[Dmitry A. Kazakov]

On Sun, 03 Feb 2002 03:07:42 -0500, Leon Winslow
<leon.winslow@eliminatespam.notes.udayton.edu> wrote:

>Robert Dewar wrote:
>
>> Ada Core Technologies (ACT) has made available at the NYU
>> site (ftp://cs.nyu.edu/pub/gnat) GNAT 3.14p builds for the
>> following targets:
>>
>> MS Windows (NT/2K)
>> Sparc Solaris (2.5.1 through 2.8)
>> GNU Linux (Redhat 6.2)
>>
>> The above are the official platforms, but in practice the
>> NT version works reasonable well on Win 98 and Win ME and
>> other versions of GNU Linux including Debian GNU/Linux are
>> known to be compatible with this version of GNAT.
>>
>> These are the only public versions that ACT plans to build.
>> As always, the releases contain the full sources, and we
>> invite volunteers to create builds for other platforms.  We
>> also draw attention to the availability of source snapshots
>> for the current development version of GNAT (similar to the
>> 3.15 release, but on GCC 3, rather than GCC 2).  The above
>> public versions are still based on ACT's 2.8.1 GCC version.
>>
>> These versions are provided without any warranty or
>> guarantee of any kind, and no support of any kind is
>> available for these public versions from ACT.  They are
>> provided as a service for use by students, hobbyists and
>> researchers who need access to a high quality Ada 95
>> system.
>>
>> handling
>
>I can understand the reason for limiting ACTs work to Windows NT, but
>this is also one of the  reason that Ada is "sliding into oblivion."
>The majority of the programming is being done on Windows platforms other
>than NT and 2K.  (MS has already announced dates for dropping all suport
>of these two platforms.).  A compiler that works "reasonably well" in
>W98, XP or Me is never going to be used on those platforms for any
>serious work.

Actually among Windows clones, NT is the most widely used platform in
industry [=best approximation of serious work]. This situation will
not change in one day or month. No matter whether Microsoft like it or
not. Then, XP is a successor of NT/2k, not Win 95/98/me. Yet XP is far
less stable [if this word can be applied to Microsoft products] than
NT. So IMO ACT does it well. I believe there should be no big problems
with using GNAT under XP. What I would wish, is GNAT for Win CE, but I
also understand the reasons why ACT does not support it.

>Alas, I knew Ada well and hate to see it go down hill, but ....

Regards,
Dmitry Kazakov

Re: ACT announces availability of GNAT 3.14p

[Larry Kilgallen]

In article <3C5CEFCE.D41ABFFF@eliminatespam.notes.udayton.edu>, Leon Winslow <leon.winslow@eliminatespam.notes.udayton.edu> writes:

> Robert Dewar wrote:
> 
>> Ada Core Technologies (ACT) has made available at the NYU
>> site (ftp://cs.nyu.edu/pub/gnat) GNAT 3.14p builds for the
>> following targets:
>>
>> MS Windows (NT/2K)
>> Sparc Solaris (2.5.1 through 2.8)
>> GNU Linux (Redhat 6.2)
>>
>> The above are the official platforms, but in practice the
>> NT version works reasonable well on Win 98 and Win ME and
>> other versions of GNU Linux including Debian GNU/Linux are
>> known to be compatible with this version of GNAT.
>>
>> These are the only public versions that ACT plans to build.


> I can understand the reason for limiting ACTs work to Windows NT, but
> this is also one of the  reason that Ada is "sliding into oblivion."
> The majority of the programming is being done on Windows platforms other
> than NT and 2K.  (MS has already announced dates for dropping all suport
> of these two platforms.).  A compiler that works "reasonably well" in
> W98, XP or Me is never going to be used on those platforms for any
> serious work.


For "serious work", ACT recommends that you pay money for their
GNAT Professional product.

But for comparison sake, for which Windows variants does Microsoft
give away their compilers for free ?

Re: ACT announces availability of GNAT 3.14p

[Jeffrey Creem]

"Leon Winslow" <leon.winslow@eliminatespam.notes.udayton.edu> wrote in
message news:3C5CEFCE.D41ABFFF@eliminatespam.notes.udayton.edu...

stuff deleted but here is the part he was talking about:

> >
> > The above are the official platforms, but in practice the
> > NT version works reasonable well on Win 98 and Win ME and
> > other versions of GNU Linux including Debian GNU/Linux are
> > known to be compatible with this version of GNAT.


> I can understand the reason for limiting ACTs work to Windows NT, but
> this is also one of the  reason that Ada is "sliding into oblivion."
> The majority of the programming is being done on Windows platforms other
> than NT and 2K.  (MS has already announced dates for dropping all suport
> of these two platforms.).  A compiler that works "reasonably well" in
> W98, XP or Me is never going to be used on those platforms for any
> serious work.
>
> Alas, I knew Ada well and hate to see it go down hill, but ....
>
> Lee Winslow
>

I hate to (or perhaps love to) sound like a www.slashdot.com person here but
don't most programs only work "reasonable well" on  98, Me.

But seriously.. First of all you have the incorrect grouping of OS's since
you correctly
group NT and 2000 but then put XP with 98 and ME.   XP is an NT/2000
followon not a
95, 98, ME follow on.

Second, when it comes to reasonable well on previous verions of the compiler
I have never
run into (in the past) a case where it did not just work 100% (although I am
sure there are some). The
new release includes GVD (debugger) which does have some issues on the older
OSs so this is probably
more true now than it was in the past..

Having said that, in terms of real marketshare for developers...Most
developers are on the NT path but
the execuables out of GNAT have always worked just fine on the 95 line of
OSs.

Re: ACT announces availability of GNAT 3.14p

[Robert Dewar]

Leon Winslow <leon.winslow@eliminatespam.notes.udayton.edu> wrote in message news:<3C5CEFCE.D41ABFFF@eliminatespam.notes.udayton.edu>...

> I can understand the reason for limiting ACTs work to 
> Windows NT ...  A compiler that works "reasonably well" 
> in W98, XP or Me is never going to be used on those 
> platforms for any serious work.
> 
> Lee Winslow

Lee is seriously confused here, ACT's work is of course
not limited to these platforms. Since others may possibly
share the same confusion, I should perhaps clarify.

For serious work using Ada 95, ACT provides a commercial
implementation of Ada 95, GNAT Pro, on a very wide range
of platforms including the following (list not complete)

  Native Platforms:

    Windows 2000
    Windows NT
    Windows XP
    Interix
    Solaris
    Solaris-x86
    AIX
    Tru64 (formerly Dec Unix)
    SGI Irix
    SCO Unix
    JVM (JGNAT)
    OpenVMS
    HPUX
    GNU-Linux (Redhat Linux and other versions)

  Cross-Platforms

    x86 Lynx
    Power PC Lynx
    68k VxWorks
    Ultrasparc VxWorks
    PPC VxWorks
    PPC VxWorks AE
    Bare board
    AAMP
    (the above with various hosts, including Solars, NT)
    (the VxWorks based products are available directly
     from Wind River Systems under their WinDirect program)

  High Integrity

    GNAT HI-E (no run time)
    GNAT HI-E (Ravenscar profile)
    VxWorks-Cert

The above list is not complete, but if you are interested in doing
serious work in Ada 95 on any of these systems,
or on systems not listed here, consult Ada Core Technologies directly
for information (sales@gnat.com)
including information on how to arrange for free evaluation
systems, including full support.

We shortly expect to announce GNAT Pro version 3.15, which
contains many new features, including a greatly extended
capability for project management, and we will also announce a
completely new powerful integrated development
environment based on GTKAda technology.

The public versions are not intended at all for serious work, so we
not only agree with Lee here, but we very
much discourage the use of the public version of GNAT
for serious mission critical work, since for one thing
we discourage the use of unsupported software in such
environments. They are intended for student and hobbyist
use and we provide the most commonly used ports for this
purpose. We also of course provide the sources, so we
expect to see other versions of GNAT built (in the past
volunteers have built ports for DOS, BSD Unix, Atari,
NEXT, and all sorts of other machines), and indeed you
see threads starting here already on building for Solaris
x86, and AIX. 

For those interested in working with the GNU project for
generating interesting new Free Software, we would recommend that you
get involved with the development
of GNAT version 5 which is now part of the GCC project.
This version of GNAT works with GCC 3.x and snapshots are
available at gnu.org.

Robert Dewar
Ada Core Technologies

Re: ACT announces availability of GNAT 3.14p

[Robert Dewar]

dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) wrote in message news:<3c5d136a.741292@news.cis.dfn.de>...
> On Sun, 03 Feb 2002 03:07:42 -0500, Leon Winslow
> <leon.winslow@eliminatespam.notes.udayton.edu> wrote:

> Yet XP is far less stable [if this word can be applied to 
> Microsoft products] than NT.

Actually our experience so far is that, at least as a GNAT
Pro development environment, XP is more stable than NT (I
am in the process of switching my own development from OS/2
to XP now, since unfortunately our tools have not continued to be
developed for OS/2, so it is time to say goodbye to the only *really*
stable system for the PC that I met so
far :-)

> So IMO ACT does it well. I believe there should be no big 
> problems with using GNAT under XP.

GNAT Pro version 3.15 works just fine under XP, and we
consider XP to be a fully supported target. It may be
the case that 3.14p works fine on XP, we just don't know
since we have never tried, so we don't like to make guesses. One
person at ACT tried it briefly and it seemed
to work, but that's as far as we have gone. This is just
a matter of timing, XP was not around when 3.14 was being
developed, but XP is reasonably compatible with NT in
practice.

> What I would wish, is GNAT for Win CE, but I
> also understand the reasons why ACT does not support it.

The reason is pretty simple, we never had a potential customer
seriously interested in this target (it is not
a hard port to do, and I guess the fact that no volunteer
did it yet means there is not much interest in the hobbyist
arena for this port either). Certainly there are many systems for
which GNAT could easily be ported if there
is interest (we just heard that the port Jim Hopper is
doing for Mac OS/X is coming along very nicely), and some
interesting new ports of GNAT Pro will be appearing soon
from Ada Core Technologies.

Robert Dewar
Ada Core Technologies

Re: ACT announces availability of GNAT 3.14p

[Samuel Tardieu]

On  3/02, Robert Dewar wrote:

| Actually our experience so far is that, at least as a GNAT
| Pro development environment, XP is more stable than NT (I
| am in the process of switching my own development from OS/2
| to XP now, since unfortunately our tools have not continued to be
| developed for OS/2, so it is time to say goodbye to the only *really*
| stable system for the PC that I met so far :-)

Well, it looks like you have not tested FreeBSD then :) PC running a stable
version of FreeBSD do typically have uptimes of hundreds of days.

Last July, you wrote after your signature "(who one of these days will probably
bite the bullet and switch to Linux -- I am beginning to miss some of the
nice GNAT tools that are not available on OS/2 -- anyone know of an
implementation of EPM on Linux :-)". Will you choose Windows XP rather
than Linux?

  Sam

Re: ACT announces availability of GNAT 3.14p

[Pascal Obry]

dewar@gnat.com (Robert Dewar) writes:

> expect to see other versions of GNAT built (in the past
> volunteers have built ports for DOS, BSD Unix, Atari,
> NEXT, and all sorts of other machines), and indeed you
> see threads starting here already on building for Solaris
> x86, and AIX. 

And Max OS X.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: ACT announces availability of GNAT 3.14p

[Robert Dewar]

Samuel Tardieu <sam@rfc1149.net> wrote in message news:<mailman.1012747681.11597.comp.lang.ada@ada.eu.org>...
> On  3/02, Robert Dewar wrote:
> 
> Well, it looks like you have not tested FreeBSD then :) 

  That's right, I have no experience with FreeBSD (I am
  not much of a fan of any version of Unix actually :-)

> Will you choose Windows XP rather than Linux?

  Yes, because (a) I am familiar with the command language,
  but more importantly (b) lots of folks at ACT run 
  GNU/Linux (surely that's what you meant to say in the
  above :-) so it is good to have some significant   
  development going on on XP -- we like to have our
  development efforts spread across as many environments
  as possible, and the GNAT tools are now in very good
  shape on XP.

Re: ACT announces availability of GNAT 3.14p

[Stephen Leake]

Leon Winslow <leon.winslow@eliminatespam.notes.udayton.edu> writes:

> I can understand the reason for limiting ACTs work to Windows NT, but
> this is also one of the  reason that Ada is "sliding into oblivion."
> The majority of the programming is being done on Windows platforms other
> than NT and 2K.  (MS has already announced dates for dropping all suport
> of these two platforms.).  A compiler that works "reasonably well" in
> W98, XP or Me is never going to be used on those platforms for any
> serious work.

But the reason GNAT only works "reasonably well" on those platforms is
that they are only "reasonably good" platforms! I would never use them
for "serious work". I have Win 95 at home, because it runs games well,
which is the major use of the computer. I keep hoping that a Windows
NT variant will appear that also runs games well; that is what we
need! 

-- 
-- Stephe

Re: ACT announces availability of GNAT 3.14p

[Stephen Leake]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

> Leon Winslow <leon.winslow@eliminatespam.notes.udayton.edu> writes:
> 
> > I can understand the reason for limiting ACTs work to Windows NT, but
> > this is also one of the  reason that Ada is "sliding into oblivion."
> > The majority of the programming is being done on Windows platforms other
> > than NT and 2K.  (MS has already announced dates for dropping all suport
> > of these two platforms.).  A compiler that works "reasonably well" in
> > W98, XP or Me is never going to be used on those platforms for any
> > serious work.
> 
> But the reason GNAT only works "reasonably well" on those platforms is
> that they are only "reasonably good" platforms! I would never use them
> for "serious work". I have Win 95 at home, because it runs games well,
> which is the major use of the computer. I keep hoping that a Windows
> NT variant will appear that also runs games well; that is what we
> need! 

Apparently I have missed the MS marketing hype about XP. It seems to
be derived from NT, which is good. Does it also run games well (Myst
III, in particular)?

-- 
-- Stephe

Re: ACT announces availability of GNAT 3.14p

[Darren New]

Stephen Leake wrote:
> Apparently I have missed the MS marketing hype about XP. It seems to
> be derived from NT, which is good. Does it also run games well (Myst
> III, in particular)?

Myst III runs fine under Win2000. There's actually very few (modern)
games that don't. NT4 didn't run games because it didn't have DirectX.
What tends not to run under 2000 is programs that access I/O ports
directly, like special hardware.

(OT, so follow up to me.)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
  The opposite of always is sometimes.
   The opposite of never is sometimes.

Re: ACT announces availability of GNAT 3.14p

[Preben Randhol]

On 04 Feb 2002 11:07:39 -0500, Stephen Leake wrote:
> Apparently I have missed the MS marketing hype about XP. It seems to
> be derived from NT, which is good. Does it also run games well (Myst
> III, in particular)?

Wouldn't know, was Myst written in Ada95? ;-) But as to XP's stability
it isn't so stable as for instance Linux. I have had problems after only
3 days of using it at work. And the dumbed-down interface is really
annoying for one that has be using computers since he was 10. Also
Office 97 (and in particular powerpoint) doesn't work. Not surprising
really as M$ makes more money if you are force to upgrade.

But I can at least say that the GNAT 3.13p compiler works (also GtkAda)
from what I have tested in this short time.

Preben Randhol

Re: ACT announces availability of GNAT 3.14p

[Pascal Obry]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

> Apparently I have missed the MS marketing hype about XP. It seems to
> be derived from NT, which is good. Does it also run games well (Myst
> III, in particular)?

Yes it does.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: ACT announces availability of GNAT 3.14p

[Karl Ran]

dewar@gnat.com (Robert Dewar) wrote in message news:<5ee5b646.0201301849.4e951bcb@posting.google.com>...

> GNAT 3.14p NEW FEATURES LIST

[tons of cool features deleted]

I just installed 3.14p, but I'm still getting the (old)linker warnigs:


gnatlink -L/usr/local/include/gtkada -L/usr/local/lib -lgtkada
-L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib
-ldl -lXi -lXext -lX11 -lm project5.ali
/usr/gnat/lib/gcc-lib/i686-pc-linux-gnu/2.8.1/adalib/libgnat.a(a-adaint.o):
In function `__gnat_tmp_name':
a-adaint.o(.text+0x504): the use of `tmpnam' is dangerous, better use
`mkstemp'
/usr/gnat/lib/gcc-lib/i686-pc-linux-gnu/2.8.1/adalib/libgnat.a(g-os_lib.o):
In function `gnat__os_lib__create_temp_file':
g-os_lib.o(.text+0x2ed): the use of `mktemp' is dangerous, better use
`mkstemp'
----------------------------------------------------------------------


gnatlink -v -v ... says:
GNATLINK 3.14p (20010503) Copyright 1996-2001 Free Software
Foundation, Inc.
gnatbind -v  says:
GNATBIND 3.14p (20010503) Copyright 1995-2001 Free Software
Foundation, Inc.

What did I do wrong? I thought I completely removed the old
version(3.13)

Karl, 
who tends to ignore (new)warnings when warnings are present all the
time :(

Re: ACT announces availability of GNAT 3.14p

[Preben Randhol]

On 6 Feb 2002 13:36:36 -0800, Karl Ran wrote:

> 
> gnatlink -v -v ... says:
> GNATLINK 3.14p (20010503) Copyright 1996-2001 Free Software
> Foundation, Inc.
> gnatbind -v  says:
> GNATBIND 3.14p (20010503) Copyright 1995-2001 Free Software
> Foundation, Inc.
> 
> What did I do wrong? I thought I completely removed the old
> version(3.13)

What do you mean? I don't see that it says version 3.13p?

-- 
Preben Randhol         �For me, Ada95 puts back the joy in programming.�

Re: ACT announces availability of GNAT 3.14p

[Stephen Leake]

karlran1234@yahoo.com (Karl Ran) writes:

> dewar@gnat.com (Robert Dewar) wrote in message
> news:<5ee5b646.0201301849.4e951bcb@posting.google.com>...
> 
> > GNAT 3.14p NEW FEATURES LIST
> 
> [tons of cool features deleted]
> 
> I just installed 3.14p, but I'm still getting the (old)linker warnigs:
> 
> 
> <snip description of warnings about 'mktemp'>
> 
> What did I do wrong? I thought I completely removed the old
> version(3.13)

What you did wrong was to assume that 3.14p fixed these warnings :).

This warning says that the gnat runtime is using some "deprecated"
functions. Apparently ACT has decided not to fix this.

> Karl, 
> who tends to ignore (new)warnings when warnings are present all the
> time :(

Yes, I agree it is bad to ignore warnings. In this particular case, it
is warnings in code you did not write, so I would be less nervous. But
a bug report to report@gnat.com does seem in order.

-- 
-- Stephe

Re: ACT announces availability of GNAT 3.14p

[Robert Dewar]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<ud6zhqqkv.fsf@gsfc.nasa.gov>...
> Apparently ACT has decided not to fix this.

As far as I know this warning occurs only with Redhat version 7, but
as clearly documented, 3.14p does not support Redhat 7, only Redhat 6.
Now it may be the case
that most things work fine with Redhat 7, but if you use
Redhat 7 with GNAT you are definitely on untested territory.

Re: ACT announces availability of GNAT 3.14p

[John English]

Robert Dewar wrote:
> 
> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<ud6zhqqkv.fsf@gsfc.nasa.gov>...
> > Apparently ACT has decided not to fix this.
> 
> As far as I know this warning occurs only with Redhat version 7, but
> as clearly documented, 3.14p does not support Redhat 7, only Redhat 6.
> Now it may be the case
> that most things work fine with Redhat 7, but if you use
> Redhat 7 with GNAT you are definitely on untested territory.

Wouldn't it make more sense to target a new GNAT version to the current
Red Hat version rather than one that's about a year out of date?

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: ACT announces availability of GNAT 3.14p

[Georg Bauhaus]

John English <je@brighton.ac.uk> wrote:

: Wouldn't it make more sense to target a new GNAT
                                    Uhm,  ^^^?
: version to the current
: Red Hat version rather than one that's about a year out of date?

- georg

Re: ACT announces availability of GNAT 3.14p

[Stephen Leake]

dewar@gnat.com (Robert Dewar) writes:

> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:<ud6zhqqkv.fsf@gsfc.nasa.gov>... 
> > Apparently ACT has decided not to fix this.
> 
> As far as I know this warning occurs only with Redhat version 7, but
> as clearly documented, 3.14p does not support Redhat 7, only Redhat 6.
> Now it may be the case
> that most things work fine with Redhat 7, but if you use
> Redhat 7 with GNAT you are definitely on untested territory.

To be more precise, it occurs with binutils 2.10 and later. ACT
apparently builds GNAT with binutils 2.9.1 (that's what's in their
source tree), and so does not get the warning.

I know this because I'm using binutils 2.10 on a couple systems :).

So I would say "If you are using GNAT with binutils other than 2.9.1,
you are on untested territory".

-- 
-- Stephe

Re: ACT announces availability of GNAT 3.14p

[Florian Weimer]

dewar@gnat.com (Robert Dewar) writes:

> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<ud6zhqqkv.fsf@gsfc.nasa.gov>...
>> Apparently ACT has decided not to fix this.
>
> As far as I know this warning occurs only with Redhat version 7, but
> as clearly documented, 3.14p does not support Redhat 7, only Redhat 6.
> Now it may be the case
> that most things work fine with Redhat 7, but if you use
> Redhat 7 with GNAT you are definitely on untested territory.

The warning indicates a security defect in the GNAT runtime.  In fact,
I have reported this defect on 2000-04-16 to report@gnat.com, even
before the warning existed.  Check your bug tracking system. ;-)

The GCC CVS contains an attempt to fix this defect, but it introduces
a different, probably more serious security defect.

Re: ACT announces availability of GNAT 3.14p

[Florian Weimer]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

[mktemp() warnings]

> To be more precise, it occurs with binutils 2.10 and later.

It depends on the version of GNU libc, too.

Re: ACT announces availability of GNAT 3.14p

[Florian Weimer]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

[tmpname()/mktemp() warnings]

> To be more precise, it occurs with binutils 2.10 and later.

It depends on the version of GNU libc, too.

Re: ACT announces availability of GNAT 3.14p

[Robert Dewar]

John English <je@brighton.ac.uk> wrote in message news:<3C63B527.ABA4F1A7@brighton.ac.uk>...

> Wouldn't it make more sense to target a new GNAT version 
> to the current Red Hat version rather than one that's 
> about a year out of date?

The 3.14p sources were frozen some time ago, when Red Hat
version 7 was not in wide use. The current version of GNAT (e.g. the
sources at gnu.org) are indeed targetted for more
up to date versions. It is up to you whether you want to
operate at the bleeding edge with software that has not
been tested in the field extensively (the GNAT 5 version
at gnu.org), or you want to use a version that has been
extensively tested in the field (the 3.14p distribution).
But you can't have it both ways, if you want something that
is absolutely up to date, it will not have been extensively
tested. That's the way things are :-)

Re: ACT announces availability of GNAT 3.14p

[Robert Dewar]

Christoph Grein <christoph.grein@eurocopter.com> wrote in message news:<mailman.1012465441.24069.comp.lang.ada@ada.eu.org>...

> Why are the other characters 16#40#, 16#5B#..16#5F#, 
> 16#7B#..16#7E# not allowed?

Why not?
We have no requirement for recognizing these characters in
this context in our style rules. We choose our style rules
to meet our needs and those of our users (including in this
case SPARK users). You are free to choose different style
rules, in which case you can't use our automatic checking?
Do you really have a specific need for the above, or is
this just a question for the sake of question :-)

Next you will be asking why we don't allow special characters in the
Chinese plane of wide characters :-) :-)

(this is all in the context of the characters permitted
following the -- in a comment. And if you think that you
should be allowed anything, fine, don't use -gnatyc!)

Re: ACT announces availability of GNAT 3.14p

[Robert Dewar]

Florian Weimer <fw@deneb.enyo.de> wrote in message news:<87ofixit6v.fsf@deneb.enyo.de>...
> The warning indicates a security defect in the GNAT 
> runtime.  In fact, I have reported this defect on 
> 2000-04-16 to report@gnat.com, even before the warning 
> existed.  Check your bug tracking system. ;-)

We are of course aware of this bug report which was retired
some time ago (but after 3.14p was frozen), but "security
defect" is rather extreme considering how this is used. 
You can always use scary language like this to talk about
anything, but it is a bit over the top in this case!

And if you think there is a "security defect" in the current version
(I disagree), you should report it (to
GNATS or report@gnat.com).

Re: ACT announces availability of GNAT 3.14p

[Matthew Woodcraft]

dewar@gnat.com (Robert Dewar) writes:

> It is up to you whether you want to operate at the bleeding edge with
> software that has not been tested in the field extensively (the GNAT 5
> version at gnu.org) [...]

How bleeding edge is that? The last patch I can find to the gcc/ada
directory from ACT was presented in a message with the subject "Reflect
ACT changes of 2001/11/08".

-M-

Re: ACT announces availability of GNAT 3.14p

[Florian Weimer]

dewar@gnat.com (Robert Dewar) writes:

> We are of course aware of this bug report which was retired
> some time ago (but after 3.14p was frozen), but "security
> defect" is rather extreme considering how this is used. 
> You can always use scary language like this to talk about
> anything, but it is a bit over the top in this case!

No, it isn't.

/tmp is shared on multi-user UNIX systems, and if a malicious local
user creates a symbolic link with a suitable name at the right time,
the output which is supposed to be written into a newly-created
temporary file is redirected to a different file instead, which can
have devastating effects (suppose that /etc/passwd is overwritten, for
example).

For many different pieces of software, it has been demonstrated over
and over again that such attacks are indeed possible, so this is not
just a theoretical issue.  (BTW, this is also true for the buffer
overflow bug in the current FSF sources I reported for the second or
third time.)

A random sample of similar problems:

http://www.kb.cert.org/vuls/id/426273
http://www.kb.cert.org/vuls/id/626919
http://www.cert.org/vendor_bulletins/VB-97.05.lynx
http://www.ciac.org/ciac/bulletins/l-084.shtml
http://www.securityfocus.com/bid/3135
http://www.securiteam.com/unixfocus/5XP0M2A4BU.html
http://cert.uni-stuttgart.de/archive/win-sec-ssc/2000/09/msg00012.html
http://www.insecure.org/sploits/sam.hpux.race.html

> And if you think there is a "security defect" in the current version
> (I disagree), you should report it (to
> GNATS or report@gnat.com).

I have nothing to add to the old bug report.  I think it contains all
the relevant information.

Re: ACT announces availability of GNAT 3.14p

[Robert Dewar]

Florian Weimer <fw@deneb.enyo.de> wrote in message news:<87n0yhf8e1.fsf@deneb.enyo.de>...

> /tmp is shared on multi-user UNIX systems, and if a 
> malicious local ...

Yes, sure, but in practice, this function is not used in
user programs (unless they specifically want to use /TMP
in which case they acquire this well known liability), but
only during certain development steps. If you are doing
Ada development on a machine where malicious users can
create links suddenly, you have a whole host of problems
NOT related to /TMP at all.

That's the point here. I agree that if all, or even some,
generated Ada programs used /TMP silently, there would be
a problem, but this is not the case, and has never been
the case.

Requiring the compiler and build tools to avoid the use
of /TMP seems an unreasonable suggestion to me.

Re: ACT announces availability of GNAT 3.14p

[Florian Weimer]

dewar@gnat.com (Robert Dewar) writes:

> That's the point here. I agree that if all, or even some,
> generated Ada programs used /TMP silently, there would be
> a problem, but this is not the case, and has never been
> the case.

Really?  The GNAT implementation of RM A.8.2(4) seems to this.

Re: ACT announces availability of GNAT 3.14p

[Robert Dewar]

Florian Weimer <fw@deneb.enyo.de> wrote in message news:<87g049f0wb.fsf@deneb.enyo.de>...
> dewar@gnat.com (Robert Dewar) writes:
> 
> > That's the point here. I agree that if all, or even 
> > some, generated Ada programs used /TMP silently, there 
> > would be a problem, but this is not the case, and has 
> > never been the case.
> 
> Really?  The GNAT implementation of RM A.8.2(4) seems to 
> this.

You misunderstand what I am saying. When the user asks for
a temporary file *explicitly* (nothing silent about that),
then the temporary file goes in TMP, which seems the right
semantics for a Unix environment to us. If you are concerned about the
security issue, e.g. if you are writing a setuid program in Ada, then
most certainly I would advise against explicit use of temporary files
in the Ada sense. The Ada semantics for temporary files is "give me a
temporary file, you choose where, using standard system
conventions". I would say that is not suitable at all for
high security programs, where you want to know EXACTLY what
files you are creating and EXACTLY what their names are.

So once again, GNAT programs use the standard Unix convention for
temporary files (put them in /TMP) only
if you explicitly ask for a temporary file. This is never
done silently, but only on request in the manner documented. That's
why this talk of security problems
seems a bit overdone. Yes, there are many ways to deliberately shoot
yourself in the foot, we advise against
such actions :-)

You seem to be arguing for not using /TMP for temporary
files ever, but that seems the wrong choice to us in a
Unix environment. Really you are arguing for removing this
feature from Unix entirely. OK, but that's an argument to
be carried on elsewhere, the policy of GNAT is to blend
harmoniously into the host operating system. If you manage
to convince Unix to remove the "dangerous" use of /TMP, then GNAT will
be happy to conform :-)

Re: ACT announces availability of GNAT 3.14p

[Florian Weimer]

dewar@gnat.com (Robert Dewar) writes:

> You misunderstand what I am saying. When the user asks for
> a temporary file *explicitly* (nothing silent about that),
> then the temporary file goes in TMP, which seems the right
> semantics for a Unix environment to us. If you are concerned about the
> security issue, e.g. if you are writing a setuid program in Ada, then
> most certainly I would advise against explicit use of temporary files
> in the Ada sense.

You are mixing two things here.  (Maybe I have been mixing these two
things, too, but I don't think so!)  The problem in GNAT 3.14p and
earlier affects *all* programs running on a multi-user system which
create temporary files.  As a result, you cannot use the Ada temporary
file facility at all, at least if you care about security.

My concerns regarding set-user-ID programs apply to the FSF CVS
version of GNAT only, where you can choose the path where temporary
files go.  (I hope there's consensus that the buffer overflow bug has
to be fixed, so this not worth a discussion.)

> You seem to be arguing for not using /TMP for temporary
> files ever, 

No, not really.

> but that seems the wrong choice to us in a
> Unix environment.

Exactly.  /tmp is *the* place for temporary files.

I just want that the Ada run-time opens the temporary file with the
O_EXCL flag for the first time (and retries if it already exists).
O_EXCL ensures that the test for existence and the creation of the
file are performed in a single atomic operation, eliminating the
current race condition.  (The FSF version of GNAT uses mkstemp(),
which invokes open() with the O_EXCL flag behind the scenes, multiple
times if necessary.)

Re: ACT announces availability of GNAT 3.14p

[Larry Kilgallen]

In article <87k7tkkqbo.fsf@deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes:
> dewar@gnat.com (Robert Dewar) writes:
> 
>> You misunderstand what I am saying. When the user asks for
>> a temporary file *explicitly* (nothing silent about that),
>> then the temporary file goes in TMP, which seems the right
>> semantics for a Unix environment to us. If you are concerned about the
>> security issue, e.g. if you are writing a setuid program in Ada, then
>> most certainly I would advise against explicit use of temporary files
>> in the Ada sense.
> 
> You are mixing two things here.  (Maybe I have been mixing these two
> things, too, but I don't think so!)  The problem in GNAT 3.14p and
> earlier affects *all* programs running on a multi-user system which
> create temporary files.  As a result, you cannot use the Ada temporary
> file facility at all, at least if you care about security.

I believe saying "*all* programs running on a multi-user system which
create temporary files" is overly broad.  If GNAT is conforming to
operating system expectations as Robert Dewar said, then on VMS
it might use SYS$SCRATCH as the storage area, and by default that
is fully protected from other unprivileged users.  If for some
reason you want to reduce the security on a VMS system, there are
steps you can take to make SYS$SCRATCH not be protected from other
unprivileged users.  (Actually, VMS has a different mechanism that
GNAT might also use that puts the file into no directory.)

I would hope that on Unix there is some way to redefine /tmp so
as to provide more protection.  But attempting to make the default
use of /tmp by an Ada program more secure than the default use of /tmp
by a shell script will be effective only if you also prevent use of
/tmp by shell scripts.

Re: ACT announces availability of GNAT 3.14p

[Aidan Skinner]

On 11 Feb 2002 10:19:46 -0600, Larry Kilgallen <Kilgallen@SpamCop.net>
wrote in <XLQoaxSGta64@eisner.encompasserve.org>:

>  as to provide more protection.  But attempting to make the default
>  use of /tmp by an Ada program more secure than the default use of /tmp
>  by a shell script will be effective only if you also prevent use of
>  /tmp by shell scripts.

AIUI the problem is GNAT calling the mktemp(3) function to create it's
temporary file, which does not do a check for file existence and
creation in an atomic manner (ie. I can create a symlink with very
careful timing and clobber say, /etc/passwd).

The mkstemp(3) call does this check in an atmoic manner, thereby
avoiding the problem.

Shell scripts should use the mktemp(1) command to create temporary
files, which (on OpenBSD 2.9 and FreeBSD 4.5) uses the mkstemp(3)
library call and are thus OK from this perspective. I don't have
access to any other *nix boxes to check what they do.

- Aidan
-- 
aidan@velvet.net  http://www.velvet.net/~aidan/  aim:aidans42
finger for pgp key fingerprint: |-----------------------------
01AA 1594 2DB0 09E3 B850        | The lurkers support me in 
C2D0 9A2C 4CC9 3EC4 75E1        | email

Re: ACT announces availability of GNAT 3.14p

[Samuel Tardieu]

On 11/02, Robert Dewar wrote:

| You seem to be arguing for not using /TMP for temporary
| files ever, but that seems the wrong choice to us in a
| Unix environment. Really you are arguing for removing this
| feature from Unix entirely. OK, but that's an argument to
| be carried on elsewhere, the policy of GNAT is to blend
| harmoniously into the host operating system. If you manage
| to convince Unix to remove the "dangerous" use of /TMP, then GNAT will
| be happy to conform :-)

/tmp is not unsafe, mktemp() is. On many systems, there exists another
function called mkstemp() which returns an *open* file instead of a
file name. Here is an excerpt of the FreeBSD man page:

     The mkstemp() function makes the same replacement to the template and
     creates the template file, mode 0600, returning a file descriptor opened
     for reading and writing.  This avoids the race between testing for a
     file's existence and opening it for use.

Using mkstemp() does remove the security hole. In fact, some linkers generate
a warning if mktemp() is used to remind programmers that there are other
ways to do that.

Re: ACT announces availability of GNAT 3.14p

[Florian Weimer]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> I believe saying "*all* programs running on a multi-user system which
> create temporary files" is overly broad.

Yes, I think I dropped the UNIX reference somewhere above.

> I would hope that on Unix there is some way to redefine /tmp so
> as to provide more protection.

I believe some rather special variants can do that (probably UNICOS/mk
or something like that), but it is by no means a common feature.

> But attempting to make the default use of /tmp by an Ada program
> more secure than the default use of /tmp by a shell script will be
> effective only if you also prevent use of /tmp by shell scripts.

At least on non-proprietary UNIX-like systems, thinks are getting
better, and one shell script is fixed after the other.

Re: ACT announces availability of GNAT 3.14p

[Larry Kilgallen]

In article <87sn874ymw.fsf@deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes:
> Kilgallen@SpamCop.net (Larry Kilgallen) writes:

>> But attempting to make the default use of /tmp by an Ada program
>> more secure than the default use of /tmp by a shell script will be
>> effective only if you also prevent use of /tmp by shell scripts.
> 
> At least on non-proprietary UNIX-like systems, thinks are getting
> better, and one shell script is fixed after the other.

Perhaps there is a net improvement in the distributions, but I have
to believe things are not that good when you count locally written
shell scripts.

Re: ACT announces availability of GNAT 3.14p

[Robert Dewar]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<88fiD5sVuJOa@eisner.encompasserve.org>...
> Perhaps there is a net improvement in the distributions, 
> but I have to believe things are not that good when you 
> count locally written shell scripts.

I would certainly agree with that. But I remind again, that
if you are writing high security Ada programs, e.g. those
running as setuid, you are well advised to stay away from
anonymous temporary files whose location is not specified
by the standard in any case.

Re: ACT announces availability of GNAT 3.14p

[John English]

Robert Dewar wrote:
> 
> John English <je@brighton.ac.uk> wrote in message news:<3C63B527.ABA4F1A7@brighton.ac.uk>...
> 
> > Wouldn't it make more sense to target a new GNAT version
> > to the current Red Hat version rather than one that's
> > about a year out of date?
> 
> The 3.14p sources were frozen some time ago, when Red Hat
> version 7 was not in wide use...

But surely you only just announced the release of 3.14p? Do you
mean that 3.14p was prepared for release a year or so ago but
only actually publicly released last month? Or am I missing
something?

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: ACT announces availability of GNAT 3.14p

[Karl Ran]

dewar@gnat.com (Robert Dewar) wrote in message
news:<5ee5b646.0202071709.11b3f88c@posting.google.com>...
> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:<ud6zhqqkv.fsf@gsfc.nasa.gov>...
> > Apparently ACT has decided not to fix this.
>
> As far as I know this warning occurs only with Redhat version 7, but
> as clearly documented, 3.14p does not support Redhat 7, only Redhat 6.
> Now it may be the case
> that most things work fine with Redhat 7, but if you use
> Redhat 7 with GNAT you are definitely on untested territory.

OK,  
I admit, I'm running a untested Linux-Distribution(Suse 7.1)
So, am I the only one who is using a 'bleeding-edge Linux-distribution'?

How you guys got rid of these warnings?
I'm using binutils-2.11.2 for some x-devl - can't go back to 2.9.1.

I hope there are better solution than I have!:

~/bin/gnatlink:

open IN, "/usr/gnat/bin/gnatlink  @ARGV 2>&1 |";
while (<IN>) {
  $line=$_;

  if ($line !~ /(tmp|temp)/) {
    print $line;
  }
}

A propper Ada version is left as an exercise for the reader ;)

Karl,
who is anxious about what will happen to posters who sends  
perl-hacks to comp.lang.ada ;)

Re: ACT announces availability of GNAT 3.14p

[Aidan Skinner]

On 12 Feb 2002 06:47:01 -0800, Karl Ran <karlran1234@yahoo.com> wrote
in <e7ebd224.0202120647.30d0f732@posting.google.com>:

>  How you guys got rid of these warnings?

The correct way is probably to replace the calls to mktemp in the gnat
sources with mkstemp, it has the same prototype and simliar enough
semantics that it should be easy to do.

Of course, I say this without actually trying it. 

- Aidan
-- 
aidan@velvet.net  http://www.velvet.net/~aidan/  aim:aidans42
finger for pgp key fingerprint: |-----------------------------
01AA 1594 2DB0 09E3 B850        | The lurkers support me in 
C2D0 9A2C 4CC9 3EC4 75E1        | email

Re: ACT announces availability of GNAT 3.14p

[Florian Weimer]

karlran1234@yahoo.com (Karl Ran) writes:

> How you guys got rid of these warnings?
> I'm using binutils-2.11.2 for some x-devl - can't go back to 2.9.1.
>
> I hope there are better solution than I have!:

Well, here's what we've put together:

http://cert.uni-stuttgart.de/advisories/gnat_temp_files.php

The patch is reproduced below (it needs mkstemp()):

--- g-os_lib.ads	2002/02/10 10:08:12	1.1
+++ g-os_lib.ads	2002/02/10 11:12:24
@@ -162,9 +162,10 @@
    --  that it fails if the file already exists. File descriptor returned is
    --  Invalid_FD if the file exists or cannot be created.
 
-   Temp_File_Len : constant Integer := 12;
-   --  Length of name returned by Create_Temp_File call (GNAT-XXXXXX & NUL)
+   Temp_File_Len : constant Integer := 17;
+   --  Length of name returned by Create_Temp_File call
+   --  (/tmp/gnat-XXXXXX & NUL)
 
    subtype Temp_File_Name is String (1 .. Temp_File_Len);
    --  String subtype set by Create_Temp_File

--- g-os_lib.adb	2002/02/10 10:05:19	1.1
+++ g-os_lib.adb	2002/02/10 10:46:11
@@ -192,27 +192,15 @@
      (FD   : out File_Descriptor;
       Name : out Temp_File_Name)
    is
-      function Get_Temp_Name (T : Address) return Address;
-      pragma Import (C, Get_Temp_Name, "mktemp");
-
-      function Open_New_Temp
-        (Name  : System.Address;
-         Fmode : Mode)
-         return  File_Descriptor;
-      pragma Import (C, Open_New_Temp, "open_new_temp");
+      function Get_Temp_Name (T : Address) return File_Descriptor;
+      pragma Import (C, Get_Temp_Name, "mkstemp");
 
    begin
-      Name (1 .. Temp_File_Len - 1) := "GNAT-XXXXXX";
+      Name (1 .. Temp_File_Len - 1) := "/tmp/gnat-XXXXXX";
       Name (Temp_File_Len)          := ASCII.NUL;
 
-      --  Check for NULL pointer returned by C
-
-      if Get_Temp_Name (Name'Address) = Null_Address then
-         FD := -1;
-      else
-         FD := Open_New_Temp (Name'Address, Binary);
-      end if;
+      FD := Get_Temp_Name (Name'Address);
    end Create_Temp_File;
 
    -----------------

--- a-adaint.c	2002/02/10 09:58:23	1.1
+++ a-adaint.c	2002/02/10 10:00:11
@@ -591,7 +591,15 @@
     free (pname);
   }
 #else
-  tmpnam (tmp_filename);
+  {
+    int fd;
+    strcpy (tmp_filename, "/tmp/gnat-XXXXXX");
+    fd = mkstemp(tmp_filename);
+    if (fd < 0)
+      strcpy(tmp_filename, "");
+    else
+      close(fd);
+  }
 #endif
 }
 

Re: ACT announces availability of GNAT 3.14p

[Aidan Skinner]

On Tue, 12 Feb 2002, David C. Hoos wrote:

> Where did you get the idea that the two functions have the
> same prototype?

Because I'm blind. :) Doh!

- Aidan
-- 
aidan@velvet.net  http://www.velvet.net/~aidan/  aim:aidans42
finger for pgp key fingerprint: |-----------------------------
01AA 1594 2DB0 09E3 B850        | The lurkers support me in
C2D0 9A2C 4CC9 3EC4 75E1        | email

Re: ACT announces availability of GNAT 3.14p

[David C. Hoos]

Where did you get the idea that the two functions have the
same prototype?

mktemp returns a pointer to a string which is the name of the
file which would have been unique at the moment the was
generated (but not necessarily afterward, which is the whole
point of the problem).

mkstemp, on the other hand returns a file descriptor for the
file which has been created and opened for exclusive use of
the caller.

David
----- Original Message ----- 
From: "Aidan Skinner" <    >
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Tuesday, February 12, 2002 9:28 AM
Subject: Re: ACT announces availability of GNAT 3.14p


> On 12 Feb 2002 06:47:01 -0800, Karl Ran <karlran1234@yahoo.com> wrote
> in <e7ebd224.0202120647.30d0f732@posting.google.com>:
> 
> >  How you guys got rid of these warnings?
> 
> The correct way is probably to replace the calls to mktemp in the gnat
> sources with mkstemp, it has the same prototype and simliar enough
> semantics that it should be easy to do.
> 
> Of course, I say this without actually trying it. 
> 
> - Aidan
> -- 
> aidan@velvet.net  http://www.velvet.net/~aidan/  aim:aidans42
> finger for pgp key fingerprint: |-----------------------------
> 01AA 1594 2DB0 09E3 B850        | The lurkers support me in 
> C2D0 9A2C 4CC9 3EC4 75E1        | email
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 

Re: ACT announces availability of GNAT 3.14p

[Florian Weimer]

dewar@gnat.com (Robert Dewar) writes:

> I would certainly agree with that. But I remind again, that
> if you are writing high security Ada programs, e.g. those
> running as setuid, you are well advised to stay away from
> anonymous temporary files whose location is not specified
> by the standard in any case.

Funny to see that Robert is spreading misinformation on CLA. ;-)

The problem in GNAT 3.14p and earlier does not only affect setuid
applications, it affects any application which creates temporary
files.  Arguing from the Ada standard is of no help here because the
Ada standard does not provide an interface to create temporary files
safely, without race conditions.  Furthermore, in GNAT 3.14p, the
location *is* hardwired to /tmp for setuid programs, at least if the
underlying libc is reasonable (which can be checked by examining the
source code).

Re: ACT announces availability of GNAT 3.14p

[Larry Kilgallen]

In article <87sn862yq4.fsf@deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes:
> dewar@gnat.com (Robert Dewar) writes:
> 
>> I would certainly agree with that. But I remind again, that
>> if you are writing high security Ada programs, e.g. those
>> running as setuid, you are well advised to stay away from
>> anonymous temporary files whose location is not specified
>> by the standard in any case.

> The problem in GNAT 3.14p and earlier does not only affect setuid

He said "e.g." not "i.e.".  Certainly you do not disagree that
security is important for a program running with setuid, do you ?

> applications, it affects any application which creates temporary
> files.

And the answer seems to be that in _some_ operating systems which
GNAT can target, use of the C runtime library can provide a call
that gives better security.   If GNAT were to simply use that call
when it is possible, that might lead to assumptions that the security
of GNAT was good on _all_ operating systems which GNAT can target.

Re: ACT announces availability of GNAT 3.14p

[jim]

In article <uaduqy0g7.fsf@wanadoo.fr>, Pascal Obry <p.obry@wanadoo.fr>
wrote:

> dewar@gnat.com (Robert Dewar) writes:
> 
> And Max OS X.
> 
> Pascal.

See www.adapower.net/macos for a beta version of os x gnat based upon
gcc 3.x.  the port is being done by a team of people not by me alone so
i am just the messenger here ;-)  If you want to talk to us check out
the link to subscribe to our mailing list on the page to keep up to
date with what we are doing.

Jim

Re: ACT announces availability of GNAT 3.14p

[Pascal Obry]

jim <jim_evart@yahoo.com> writes:

> In article <uaduqy0g7.fsf@wanadoo.fr>, Pascal Obry <p.obry@wanadoo.fr>
> wrote:
> 
> > dewar@gnat.com (Robert Dewar) writes:
> > 
> > And Max OS X.
> > 
> > Pascal.
> 
> See www.adapower.net/macos for a beta version of os x gnat based upon
> gcc 3.x.  

I know that was why I have added Mac OS X to Robert's list. Mac OS X seems to
be a very nice platform nice GUI and safe kernel based on BSD...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"