* GNAT 3.14p and Red Hat 7.2 @ 2002-03-24 23:20 Ken Nelson 2002-03-25 15:22 ` Mark Johnson 2002-03-26 10:06 ` Dr. Michael Paus 0 siblings, 2 replies; 17+ messages in thread From: Ken Nelson @ 2002-03-24 23:20 UTC (permalink / raw) GNAT 3.14p was released to run on GNU Linux (Red Hat 6.2). Has anyone ported it to Red Hat 7.2? If not, can someone from ACT comment on how much work this would be and the best way(s) to perform a port? Ken ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GNAT 3.14p and Red Hat 7.2 2002-03-24 23:20 GNAT 3.14p and Red Hat 7.2 Ken Nelson @ 2002-03-25 15:22 ` Mark Johnson 2002-03-26 2:12 ` Ken Nelson 2002-03-26 10:06 ` Dr. Michael Paus 1 sibling, 1 reply; 17+ messages in thread From: Mark Johnson @ 2002-03-25 15:22 UTC (permalink / raw) Ken Nelson wrote: > > GNAT 3.14p was released to run on GNU Linux (Red Hat 6.2). Has anyone > ported it to Red Hat 7.2? If not, can someone from ACT comment on how > much work this would be and the best way(s) to perform a port? > > Ken I guess I don't understand the question. We have been using 3.14a (as well as 3.15w, 3.15a,...) for some time on both RH 7.1 and 7.2 systems (building applications & running them) without any problems at all. Install it, change your path, and go. I could guess at the problem you are having but perhaps you could elaborate :-) some more. --Mark ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GNAT 3.14p and Red Hat 7.2 2002-03-25 15:22 ` Mark Johnson @ 2002-03-26 2:12 ` Ken Nelson 2002-03-26 14:56 ` Mark Johnson 2002-03-26 17:21 ` Stephen Leake 0 siblings, 2 replies; 17+ messages in thread From: Ken Nelson @ 2002-03-26 2:12 UTC (permalink / raw) Mark Johnson <mark_h_johnson@raytheon.com> wrote in message news:<3C9F40A2.5AF3920D@raytheon.com>... > Ken Nelson wrote: > > > > GNAT 3.14p was released to run on GNU Linux (Red Hat 6.2). Has anyone > > ported it to Red Hat 7.2? If not, can someone from ACT comment on how > > much work this would be and the best way(s) to perform a port? > > > > Ken > > I guess I don't understand the question. We have been using 3.14a (as > well as 3.15w, 3.15a,...) for some time on both RH 7.1 and 7.2 systems > (building applications & running them) without any problems at all. > Install it, change your path, and go. I could guess at the problem you > are having but perhaps you could elaborate :-) some more. > --Mark Well, since your a _paying_ customer, it _should_ work for you. ;-) In the GNAT 3.14p announcement thread... http://groups.google.com/groups?hl=en&threadm=5ee5b646.0202030611.1df3899a%40posting.google.com&rnum=1&prev=/groups%3Fq%3Dannounce%2Bgnat%2B3.14p%2Bgroup:comp.lang.ada%26hl%3Den%26selm%3D5ee5b646.0202030611.1df3899a%2540posting.google.com%26rnum%3D1 ...the following exchange took place between John English and 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 :-) Indicating that if I simply run GNAT 3.14p on Red Hat 7.2, it will probably "go bump in the night" at a bad time (that never happens at a good time). So, having some time and interest, I decided to attempt building the compiler from its sources. I have a working copy of GNAT 3.13p and gcc 2.8.1 [ken@linux gcc-2.8.1-gnat-3.14p]$ gnatmake -v GNATMAKE 3.13p (20000509) Copyright 1995-2000 Free Software Foundation, Inc. Usage: gnatmake opts name {[-cargs opts] [-bargs opts] [-largs opts]} [ken@linux gcc-2.8.1-gnat-3.14p]$ gcc -v Reading specs from /home/free_sw/apps/lib/gcc-lib/i686-pc-linux-gnu/2.8.1/specs gcc version 2.8.1 I have done the following: 1. Unpacked gcc-2.8.1 source 2. Copied the GNAT 3.14p src/ada directory into the gcc 2.8.1 directory 3. Applied the gcc-281.dif patches 4. Touched cstamp-h.in 5. Did not see any specific instructions for this target 6. Touched treeprs.ads a-[es]info.h nmake.ad[bs] in ada directory 7. Ran GCC's configure script with no parameters 8. Successfully ran: make CC=gcc CFLAGS="-O2" LANGUAGES="c ada gcov" 9. Successfully ran: make CC=gcc CFLAGS="-O2" LANGUAGES="c ada gcov" bootstrap 10. However, make CC=gcc CFLAGS="-O2" gnattools produces: ../xgcc -B../ -DIN_GCC -O2 -o ../gnatmem b_gnatmem.o gnatmem.o memroot.o a-gmem.o a-adaint.o a-argv.o a-cio.o a-cstrea.o a-exit.o a-final.o a-init.o a-raise.o a-sysdep.o ada.o a-comlin.o a-except.o a-filico.o a-finali.o a-flteio.o a-inteio.o a-ioexce.o a-stream.o a-tags.o a-textio.o a-tiflau.o a-tigeau.o a-tiinau.o a-tiocst.o gnat.o g-casuti.o g-hesora.o g-htable.o g-os_lib.o gnatvsn.o interfac.o i-cstrea.o system.o s-assert.o s-except.o s-exctab.o s-exngen.o s-exnllf.o s-fatllf.o s-ficobl.o s-fileio.o s-finimp.o s-finroo.o s-imgbiu.o s-imgenu.o s-imgint.o s-imgllb.o s-imglli.o s-imgllu.o s-imgllw.o s-imgrea.o s-imguns.o s-imgwiu.o a-traceb.o s-traceb.o s-mastop.o s-parame.o s-powtab.o s-secsta.o s-sopco3.o s-sopco4.o s-sopco5.o s-stache.o s-stalib.o s-stoele.o s-stratt.o s-strops.o s-soflin.o s-unstyp.o s-valllu.o s-vallli.o s-valint.o s-valrea.o s-valuns.o s-valuti.o ../prefix.o \ -laddr2line -lbfd -liberty a-adaint.o: In function `__gnat_tmp_name': a-adaint.o(.text+0x42c): the use of `tmpnam' is dangerous, better use `mkstemp' g-os_lib.o: In function `gnat__os_lib__create_temp_file': g-os_lib.o(.text+0x2f1): the use of `mktemp' is dangerous, better use `mkstemp' a-gmem.o: In function `__gnat_gmem_a2l_initialize': a-gmem.o(.text+0xc4): undefined reference to `convert_addresses' a-gmem.o: In function `__gnat_gmem_read_bt_frame': a-gmem.o(.text+0x20d): undefined reference to `convert_addresses' make[2]: *** [../gnatmem] Error 1 make[2]: Leaving directory `/home/free_sw/gcc-2.8.1-gnat-3.14p/ada' make[1]: *** [gnatmem] Error 2 make[1]: Leaving directory `/home/free_sw/gcc-2.8.1-gnat-3.14p' make: *** [gnattools] Error 2 The function convert_addresses (from RH 6.2) appears to no longer be apart of the binutils package in Red Hat 7.2. The previous two errors can be fairly easily worked-around, but I don't recall exactly what I did to do that (in a previous build). Having run into a non-trival issue (probably not the last) which has been solved by ACT, I decided to appeal to c.l.a. to see if someone might provide some assistance/guidance - instead of just blindly, laboriously, slaying dead bugs that I reincarnated. Ken ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GNAT 3.14p and Red Hat 7.2 2002-03-26 2:12 ` Ken Nelson @ 2002-03-26 14:56 ` Mark Johnson 2002-03-26 19:52 ` Florian Weimer 2002-03-26 17:21 ` Stephen Leake 1 sibling, 1 reply; 17+ messages in thread From: Mark Johnson @ 2002-03-26 14:56 UTC (permalink / raw) Ken Nelson wrote: > [snip] Oh. Building gnat from source. I don't generally do that, but may still be able to help... > a-adaint.o: In function `__gnat_tmp_name': > a-adaint.o(.text+0x42c): the use of `tmpnam' is dangerous, better use > `mkstemp' > g-os_lib.o: In function `gnat__os_lib__create_temp_file': > g-os_lib.o(.text+0x2f1): the use of `mktemp' is dangerous, better use > `mkstemp' I have reported this particular problem to ACT several months ago - and it was subsequently fixed. > a-gmem.o: In function `__gnat_gmem_a2l_initialize': > a-gmem.o(.text+0xc4): undefined reference to `convert_addresses' > a-gmem.o: In function `__gnat_gmem_read_bt_frame': > a-gmem.o(.text+0x20d): undefined reference to `convert_addresses' convert_addresses is referenced by g-trasym.adb to assist in the generation of the symbolic stack traceback (lookup file name & line number from debug data). This should have been brought in by linking libaddr2line.a (-laddr2line). The copy on my system was in the binary tar file from ACT (and not part of the binutils RPM) - for versions 3.14a, 3.15w, etc. Since you are building from source, it might not be built correctly. I haven't looked at the binary for 3.14p, but it should have the appropriate library you need. If not, use the stub version in a-adaint.c as an interim fix. --Mark ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GNAT 3.14p and Red Hat 7.2 2002-03-26 14:56 ` Mark Johnson @ 2002-03-26 19:52 ` Florian Weimer 0 siblings, 0 replies; 17+ messages in thread From: Florian Weimer @ 2002-03-26 19:52 UTC (permalink / raw) Mark Johnson <mark_h_johnson@raytheon.com> writes: > I have reported this particular problem to ACT several months ago - and > it was subsequently fixed. I can't tell anything about the internal ACT version, but the fix in GNAT 5.0 introduces another problem (a buffer overflow). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GNAT 3.14p and Red Hat 7.2 2002-03-26 2:12 ` Ken Nelson 2002-03-26 14:56 ` Mark Johnson @ 2002-03-26 17:21 ` Stephen Leake 2002-03-26 19:53 ` Florian Weimer 1 sibling, 1 reply; 17+ messages in thread From: Stephen Leake @ 2002-03-26 17:21 UTC (permalink / raw) KennethNelson@attbi.com (Ken Nelson) writes: ><snip> > I have a working copy of GNAT 3.13p and gcc 2.8.1 > > 10. However, make CC=gcc CFLAGS="-O2" gnattools produces: > > <snip>> a-adaint.o: In function `__gnat_tmp_name': > a-adaint.o(.text+0x42c): the use of `tmpnam' is dangerous, better use > `mkstemp' > g-os_lib.o: In function `gnat__os_lib__create_temp_file': > g-os_lib.o(.text+0x2f1): the use of `mktemp' is dangerous, better use > `mkstemp' These are just warnings about potential security problems. They should be ignored. > a-gmem.o: In function `__gnat_gmem_a2l_initialize': > a-gmem.o(.text+0xc4): undefined reference to `convert_addresses' > a-gmem.o: In function `__gnat_gmem_read_bt_frame': > a-gmem.o(.text+0x20d): undefined reference to `convert_addresses' > make[2]: *** [../gnatmem] Error 1 make[2]: Leaving directory > `/home/free_sw/gcc-2.8.1-gnat-3.14p/ada' make[1]: *** [gnatmem] > Error 2 make[1]: Leaving directory > `/home/free_sw/gcc-2.8.1-gnat-3.14p' make: *** [gnattools] Error 2 Just comment out 'gnatmem' in the makefile, so it doesn't get built. You won't need it for anything > The function convert_addresses (from RH 6.2) appears to no longer be > apart of the binutils package in Red Hat 7.2. It's provided in a patch to binutils in the GNAT source distribution. > The previous two errors can be fairly easily worked-around, but I > don't recall exactly what I did to do that (in a previous build). Just ignore them :). -- -- Stephe ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GNAT 3.14p and Red Hat 7.2 2002-03-26 17:21 ` Stephen Leake @ 2002-03-26 19:53 ` Florian Weimer 2002-03-27 10:49 ` David C. Hoos, Sr. 0 siblings, 1 reply; 17+ messages in thread From: Florian Weimer @ 2002-03-26 19:53 UTC (permalink / raw) Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes: >> <snip>> a-adaint.o: In function `__gnat_tmp_name': >> a-adaint.o(.text+0x42c): the use of `tmpnam' is dangerous, better use >> `mkstemp' >> g-os_lib.o: In function `gnat__os_lib__create_temp_file': >> g-os_lib.o(.text+0x2f1): the use of `mktemp' is dangerous, better use >> `mkstemp' > > These are just warnings about potential security problems. They should > be ignored. The first warning is issued because the code *does* contain a security problem (your Ada application will be affected only if it uses temporary files, though). Ignoring it won't make it go away. ;-) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GNAT 3.14p and Red Hat 7.2 2002-03-26 19:53 ` Florian Weimer @ 2002-03-27 10:49 ` David C. Hoos, Sr. 2002-03-27 11:55 ` Florian Weimer 0 siblings, 1 reply; 17+ messages in thread From: David C. Hoos, Sr. @ 2002-03-27 10:49 UTC (permalink / raw) ----- Original Message ----- From: "Florian Weimer" <fw@deneb.enyo.de> Newsgroups: comp.lang.ada To: <comp.lang.ada@ada.eu.org> Sent: March 26, 2002 1:53 PM Subject: Re: GNAT 3.14p and Red Hat 7.2 > Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes: > > >> <snip>> a-adaint.o: In function `__gnat_tmp_name': > >> a-adaint.o(.text+0x42c): the use of `tmpnam' is dangerous, better use > >> `mkstemp' > >> g-os_lib.o: In function `gnat__os_lib__create_temp_file': > >> g-os_lib.o(.text+0x2f1): the use of `mktemp' is dangerous, better use > >> `mkstemp' > > > > These are just warnings about potential security problems. They should > > be ignored. > > The first warning is issued because the code *does* contain a security > problem (your Ada application will be affected only if it uses > temporary files, though). Ignoring it won't make it go away. ;-) More correctly, one should say "your Ada application will be affected only if it uses GNAT.OS_Lib.Create_Temp_File." One can certainly safely use temporary files in Ada programs. > _______________________________________________ > comp.lang.ada mailing list > comp.lang.ada@ada.eu.org > http://ada.eu.org/mailman/listinfo/comp.lang.ada > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GNAT 3.14p and Red Hat 7.2 2002-03-27 10:49 ` David C. Hoos, Sr. @ 2002-03-27 11:55 ` Florian Weimer 2002-03-28 16:04 ` Georg Bauhaus 0 siblings, 1 reply; 17+ messages in thread From: Florian Weimer @ 2002-03-27 11:55 UTC (permalink / raw) "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes: >> The first warning is issued because the code *does* contain a security >> problem (your Ada application will be affected only if it uses >> temporary files, though). Ignoring it won't make it go away. ;-) > > More correctly, one should say "your Ada application will be affected > only if it uses GNAT.OS_Lib.Create_Temp_File." > > One can certainly safely use temporary files in Ada programs. But not using the mechanism in A.8.2(4). :-/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GNAT 3.14p and Red Hat 7.2 2002-03-27 11:55 ` Florian Weimer @ 2002-03-28 16:04 ` Georg Bauhaus 2002-03-28 20:34 ` Florian Weimer 0 siblings, 1 reply; 17+ messages in thread From: Georg Bauhaus @ 2002-03-28 16:04 UTC (permalink / raw) Florian Weimer <fw@deneb.enyo.de> wrote: : "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes: : :>> The first warning is issued because the code *does* contain a security :>> problem (your Ada application will be affected only if it uses :>> temporary files, though). Ignoring it won't make it go away. ;-) :> :> More correctly, one should say "your Ada application will be affected :> only if it uses GNAT.OS_Lib.Create_Temp_File." :> :> One can certainly safely use temporary files in Ada programs. : : But not using the mechanism in A.8.2(4). :-/ I recall a discussion of OS security in the Minix book by Tanenbaum, where he points out that you should not believe in security because your system manual tells you some part of the system has been secured. On the contrary, the mechanism should be open to cracking attempts, to be tested. On the surface, this seems unrelated, and mkstemp() (or whatever its name is) is open to testing of all kinds. But the mindset seems related, at least to me. If programmers feel they have written a secure program because they are told their compiler doesn't use insecure OS facilities, I wouldn't, necessarily, as a user of their program. Proven security...? Improved security due to the removal of one possible hole? Let me argue in favour of documenting possible holes. If program writers learn to pay attention to the outcome of the compilation process, and they must, once they now even an Ada program doesn't just use RM virtuality, they will care about what OS facilities operate behind the scenes. Who knows what will happen to a running Ada program if the OS kernel supports modifying the hardware clock... I don't, right know, but if my program depends on that device, I will pay attention, and hope to find a note somewhere near the Clock documentation. - Georg ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GNAT 3.14p and Red Hat 7.2 2002-03-28 16:04 ` Georg Bauhaus @ 2002-03-28 20:34 ` Florian Weimer 2002-03-29 16:02 ` Georg Bauhaus 0 siblings, 1 reply; 17+ messages in thread From: Florian Weimer @ 2002-03-28 20:34 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > I recall a discussion of OS security in the Minix book > by Tanenbaum, where he points out that you should not believe > in security because your system manual tells you some part > of the system has been secured. On the contrary, the mechanism > should be open to cracking attempts, to be tested. Did Tanenbaum really write that? What strange way to think about security! We haven't got just manuals, we have also got source code. Looking at the source code is far more efficient than random black box testing without vendor support. I'm surprised how many vulnerabilities are uncovered by more or less systematic black box testing, but such testing can only show the presence of bugs, not their absence. > Improved security due to the removal of one possible hole? Yes, of course, and it's not a "possible hole", it's a typical /tmp race condition. > Let me argue in favour of documenting possible holes. This particular problem has been documented over and over again. In fact, it is one of the most well-known security problems in UNIX-centered code. > If program writers learn to pay attention to the outcome > of the compilation process, and they must, once they now > even an Ada program doesn't just use RM virtuality, > they will care about what OS facilities operate behind the > scenes. Well, I *do* care, that's why I complain about the problem! But your advice not to fix such problems and just document them is entirely incomprehensible to me. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GNAT 3.14p and Red Hat 7.2 2002-03-28 20:34 ` Florian Weimer @ 2002-03-29 16:02 ` Georg Bauhaus 2002-03-30 16:18 ` Georg Bauhaus 0 siblings, 1 reply; 17+ messages in thread From: Georg Bauhaus @ 2002-03-29 16:02 UTC (permalink / raw) Florian Weimer <fw@deneb.enyo.de> wrote: : Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: : :> I recall a discussion of OS security in the Minix book :> by Tanenbaum, where he points out that you should not believe :> in security because your system manual tells you some part :> of the system has been secured. On the contrary, the mechanism :> should be open to cracking attempts, to be tested. : : Did Tanenbaum really write that? What strange way to think about : security! Maybe I should try to state this more clearly. Some quotes: `First, the system design should be public. Assuming that the intruders do not know how the system works serves only to delude the designers.' `Fifth, the protection mechanism should be ... built into the lowest layers of the system. Trying to retrofit security to an existing insecure system is nearly impossible.' : We haven't got just manuals, we have also got source code. yes, see above. : Looking at : the source code is far more efficient than random black box testing : without vendor support. Maybe, don't know the efficiency scale here, but why look at OS source code in order to be free to care less about null string file names, because the compiler is smart enough to work around OS's race conditions? I was trying to argue that while this may be "fixed", it might support the false idea that Ada programs are safe by RM and good OS aware compilers. That's a dangerous aproach in my view! : but such : testing can only show the presence of bugs, not their absence. Neither can the absence be shown to a degree that deserves the name security. There is none, only protection (OS), trust (human), and a good setup (both). :> Improved security due to the removal of one possible hole? : : Yes, of course, and it's not a "possible hole", it's a typical /tmp : race condition. So it is a typical hole, that's not a compliment for ___ {, ___} (fill in here). (Important point. What is the intention of forcing mkstemp()? Beeing able to say, "See, no GNU Ada program introduces security problems by using race-condition OS facilities?") : This particular problem has been documented over and over again. In : fact, it is one of the most well-known security problems in : UNIX-centered code. So change UNIX. Don't change the look of its system calls. See above, quote 2. : But your : advice not to fix such problems and just document them is entirely : incomprehensible to me. I think an OS problem should not be fixed by a compiler, introducing the possibility of a non-portable fix-me-once-more problem, should there be another operating system with shared scratch space, and someone wants to adapt the compiler to that system. (Again in an attempt to free programmers from having to think about possible security holes introduced by their programs?) And for programs that should run under high protection, as opposed to an operating system that should be protected from the vulnerabilities of its inherent race conditions (mkstemp() is a _workaround_, since the originals are still there), I would of course try to make sure every external thing used by the program is in a well known state, with an appropriate setup and good administration e.g.. The qoutes can be found in both the Minix book and Modern OSs, security chapters. - georg running Debian GNU/Linux most of the time. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GNAT 3.14p and Red Hat 7.2 2002-03-29 16:02 ` Georg Bauhaus @ 2002-03-30 16:18 ` Georg Bauhaus 2002-03-30 19:17 ` Florian Weimer 0 siblings, 1 reply; 17+ messages in thread From: Georg Bauhaus @ 2002-03-30 16:18 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote: : Maybe I should try to state this more clearly. Some quotes: And maybe my previous post was a bit strong, ahum. happy holidays. - georg (but look at glibc's tmpfile() H) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GNAT 3.14p and Red Hat 7.2 2002-03-30 16:18 ` Georg Bauhaus @ 2002-03-30 19:17 ` Florian Weimer 2002-03-30 21:22 ` David C. Hoos, Sr. 0 siblings, 1 reply; 17+ messages in thread From: Florian Weimer @ 2002-03-30 19:17 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote: > : Maybe I should try to state this more clearly. Some quotes: > And maybe my previous post was a bit strong, ahum. happy holidays. > - georg > (but look at glibc's tmpfile() H) An Ada temporary file requires a name, and tmpfile() creates an unnamed file. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GNAT 3.14p and Red Hat 7.2 2002-03-30 19:17 ` Florian Weimer @ 2002-03-30 21:22 ` David C. Hoos, Sr. 2002-03-30 23:14 ` Florian Weimer 0 siblings, 1 reply; 17+ messages in thread From: David C. Hoos, Sr. @ 2002-03-30 21:22 UTC (permalink / raw) ----- Original Message ----- From: "Florian Weimer" <fw@deneb.enyo.de> Newsgroups: comp.lang.ada To: <comp.lang.ada@ada.eu.org> Sent: March 30, 2002 1:17 PM Subject: Re: GNAT 3.14p and Red Hat 7.2 > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes: > > > Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote: > > : Maybe I should try to state this more clearly. Some quotes: > > And maybe my previous post was a bit strong, ahum. happy holidays. > > - georg > > (but look at glibc's tmpfile() H) > > An Ada temporary file requires a name, and tmpfile() creates an > unnamed file. Where did you get the idea that an Ada temporary file requires a name? There are only two mentions of temporary files in the LRM, viz.: A.8.2 (4) A null string for Name specifies an external file that is not accessible after the completion of the main program (a temporary file). A null string for Form specifies the use of the default options of the implementation for the external file. A.8. (23) The exception Status_Error is propagated if the given file is not open. The exception Use_Error is propagated if the associated external file is a temporary file that cannot be opened by any name. Thus, an Ada temporary file is also unnamed. Respectfully, David Hoos > _______________________________________________ > comp.lang.ada mailing list > comp.lang.ada@ada.eu.org > http://ada.eu.org/mailman/listinfo/comp.lang.ada > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GNAT 3.14p and Red Hat 7.2 2002-03-30 21:22 ` David C. Hoos, Sr. @ 2002-03-30 23:14 ` Florian Weimer 0 siblings, 0 replies; 17+ messages in thread From: Florian Weimer @ 2002-03-30 23:14 UTC (permalink / raw) "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes: > Where did you get the idea that an Ada temporary file requires a > name? Oh, someone from ACT told it to me, and I didn't check it. > A.8. (23) The exception Status_Error is propagated if the given file > is not open. The exception Use_Error is propagated if the associated > external file is a temporary file that cannot be opened by any name. The GNAT standpoint seems to be, "our temporary files can be opened by a name, that's why we never raise Use_Error". ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GNAT 3.14p and Red Hat 7.2 2002-03-24 23:20 GNAT 3.14p and Red Hat 7.2 Ken Nelson 2002-03-25 15:22 ` Mark Johnson @ 2002-03-26 10:06 ` Dr. Michael Paus 1 sibling, 0 replies; 17+ messages in thread From: Dr. Michael Paus @ 2002-03-26 10:06 UTC (permalink / raw) Ken Nelson schrieb: > > GNAT 3.14p was released to run on GNU Linux (Red Hat 6.2). Has anyone > ported it to Red Hat 7.2? If not, can someone from ACT comment on how > much work this would be and the best way(s) to perform a port? Just give it a try. I am using 3.14p on my Suse 7.3 without any problems so far. Michael ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2002-03-30 23:14 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-03-24 23:20 GNAT 3.14p and Red Hat 7.2 Ken Nelson 2002-03-25 15:22 ` Mark Johnson 2002-03-26 2:12 ` Ken Nelson 2002-03-26 14:56 ` Mark Johnson 2002-03-26 19:52 ` Florian Weimer 2002-03-26 17:21 ` Stephen Leake 2002-03-26 19:53 ` Florian Weimer 2002-03-27 10:49 ` David C. Hoos, Sr. 2002-03-27 11:55 ` Florian Weimer 2002-03-28 16:04 ` Georg Bauhaus 2002-03-28 20:34 ` Florian Weimer 2002-03-29 16:02 ` Georg Bauhaus 2002-03-30 16:18 ` Georg Bauhaus 2002-03-30 19:17 ` Florian Weimer 2002-03-30 21:22 ` David C. Hoos, Sr. 2002-03-30 23:14 ` Florian Weimer 2002-03-26 10:06 ` Dr. Michael Paus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox