From bobduff@world.std.com Wed Jan 8 11:23:05 1997 Return-Path: Received: from inmet.camb.inmet.com by camb.inmet.com (SMI-8.6/SMI-SVR4) id LAA04645; Wed, 8 Jan 1997 11:23:04 -0500 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA01051; Wed, 8 Jan 97 11:23:33 EST Received: from europe.std.com by sw-eng.falls-church.va.us (8.7.1/) id QAA25681; Wed, 8 Jan 1997 16:20:24 GMT Received: from world.std.com by europe.std.com (8.7.5/BZS-8-1.0) id LAA02644; Wed, 8 Jan 1997 11:22:54 -0500 (EST) Received: by world.std.com (5.65c/Spike-2.0) id AA07283; Wed, 8 Jan 1997 11:22:52 -0500 Date: Wed, 8 Jan 1997 11:22:52 -0500 From: bobduff@world.std.com (Robert A Duff) Message-Id: <199701081622.AA07283@world.std.com> To: wwgrol@pseserv3.fw.hac.com Cc: ada-comment@sw-eng.falls-church.va.us, wwgrol@pseserv3.fw.hac.com In-Reply-To: <9701072126.AA18140@most> (wwgrol@pseserv3.fw.hac.com) Subject: Re: A question about storage size of task object (fwd) content-length: 3854 !topic Storage_Size, pragma and attribute. !reference RM95 13.3(59) to 13.3(67) !reference 97-15700.a W. Wesley Groleau (Wes) 97-1-7 !from Bob Duff <> !discussion > when you give pragma storage_size (X), the implementation must reserve > X OR MORE units or raise Storage_Error. The attribute must return X OR MORE. > > An implementation is also allowed to have storage associated with a task > object which is NOT counted in the attribute's measurement. > > I have some difficulties with the RM in these paragraphs: > > 1. RM says that the units are "storage elements" but the Annotated RM, > hints in 13.3(66.a) that it's "bytes" Now the definition of "byte" has > been debated at length within the last six months, but I don't think the > ARM gives it a definition. The AARM is using the term "bytes" informally to mean "storage element". On most machines these days, the two terms refer to the same thing. The AARM is allowed to be sloppy like that; the RM is not. > 2. the attribute 'Storage_Size is not worth much when you allow it to > a. be larger than requested We have to allow it to be larger than requested, because we want to allow the RTS to allocate in chunks. E.g., it is perfectly reasonable for an RTS to allocate all task stacks in multiples of 4096 bytes, and any wording that forbids that is unacceptable. > b. be less than the actual We wanted to allow complete freedom in the management of TCB's. Some RTS's want to allocate TCB's in some special area, perhaps in operating system memory, and it really doesn't make sense to lump this storage in with the storage for the task stack. Consider for example an implementation of Ada on top of Windows 95, where each Ada task is mapped to a Win 95 thread. The Ada implementer has no control over how much storage is used by a Win 95 thread. > c. not include all the storage that a task object actually withholds from > other parts of the system. I'm not sure how this is different from (b). But in any case, the purpose of pragma Storage_Size is *not* to make sure the task doesn't use up too much memory, although it can be used in that manner if you know something about your implementation. The purpose is to make sure that the task has enough memory for its own work. > To put it another way, the following BOGUS interpretation does not > violate the RM: > > If you give a task "pragma Storage_Size(X);" then the system will reserve > Y units of storage such that X < Y < unknown. And the value of > 'Storage_Size will be Z such that X < Z < unknown. Y may be greater than, > less than, or equal to Z. The system may actually consume an amount of > space greater than Y or Z. Yes. But suppose the RM said that *exactly* X storage elements are reserved, and that 'Storage_Size returns *exactly* X. Would that be any better? No, because the RM doesn't define how much storage is used by any given operation, and the RM allows Storage_Error to be raised by *anything*. E.g., the following "BOGUS interpretation" does not violate the RM: Every time a task does an integer assignment, it uses up an additional, unrecoverable, 1 megabyte chunk of memory. So, the answer to your question is: Yes, the definition of Storage_Size is vague. But it has to be that way. And one has to assume that implementers are not deliberately trying to damage their customers. This last part is true of many cases where the RM allows implementation freedoms, especially low-level concerns like storage management, where the RM really can't nail things down precisely. In order to use Storage_Size effectively, you need to know some things about your implementation: how is storage organized (stack, heap, special TCB memory, etc), how much memory is used for various things, how much the Storage_Size is rounded up, etc. - Bob From brosgol@east.alsys.com Wed Jan 8 11:28:27 1997 Return-Path: Received: from inmet.camb.inmet.com by camb.inmet.com (SMI-8.6/SMI-SVR4) id LAA04762; Wed, 8 Jan 1997 11:28:26 -0500 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA01183; Wed, 8 Jan 97 11:28:54 EST Received: from gw.alsys.com by sw-eng.falls-church.va.us (8.7.1/) id QAA25714; Wed, 8 Jan 1997 16:25:45 GMT Received: from east.alsys.com (wheel.east.alsys.com) by gw.alsys.com (4.1/SMI-4.1.1) id AA26318; Wed, 8 Jan 97 08:28:36 PST Received: from sparky.east.thomsoft.com by east.alsys.com (4.1/SMI-4.1) id AA14363; Wed, 8 Jan 97 11:27:12 EST Received: from rescatore.east.alsys.com (rescatore.east.aonix.com) by sparky.east.thomsoft.com (5.0/SMI-SVR4) id AA18723; Wed, 8 Jan 1997 11:22:43 +0500 Received: by rescatore.east.alsys.com with Microsoft Mail id <01BBFD3C.F91CCD20@rescatore.east.alsys.com>; Wed, 8 Jan 1997 08:21:40 -0500 Message-Id: <01BBFD3C.F91CCD20@rescatore.east.alsys.com> From: Ben Brosgol To: "'ada-comment@sw-eng.falls-church.va.us'" Subject: Re: Interfaces.C.Strings.Value with len returning String Date: Wed, 8 Jan 1997 08:21:38 -0500 Encoding: 61 TEXT content-length: 2792 !topic Interfaces.C.Strings.Value with len returning String !reference RM95 B.3.1(40) !reference 97-15695.a Tucker Taft 1997-1-3 !reference 97-15696.a Ben Brosgol 97-1-3 <> !discussion Here is my response to Dan Lehman's questions/comments: BB> The following is probably the simplest BB> correction to B.3.1(40): BB> BB> Equivalent to To_Ada( Value(Item, Length) & nul, Trim_Nul => True). BB> BB> The inner call Value(Item, Length) produces a char_array that might or BB> might not be nul-terminated; by concatenating nul we ensure nul termination. DL> But, at least at the *intuitive* level, it seems silly to append nul when DL> one is asking precisely to Trim_Nul! (-; An alternative and perhaps more intuitive wording would be as follows: "If Item = Null_Ptr then Value propagates Dereference_Error. Otherwise the result String has lower bound 1 and comprises the elements obtained by applying To_Ada to each char in the array referenced by Item, stopping either immediately before the first occurrence of nul or immediately after Length chars, whichever happens earlier." BB> Thus the To_Ada call will not propagate Terminator_Error. DL> What is the point of raising Terminator_Error, anyway? Note that T_E is DL> NOT raised when Trim_Nul=False, yet one might think that THEN is DL> precisely when one would want it raised. DL> (-; intuitively: "Don't trim the nul. ... WHAT, there ISN'T a nul?! DL> Whoa, Nully!") DL> DL> Is it the purpose of To_Ada to sort of type-check for correct C-string DL> formation (i.e. having nul termination), but only when Trim_Nul=True!? DL> Why not let such nul-checking be done explicitly by the program with DL> Is_Nul_Terminated functions, and leave the conversions to give the DL> with/without-nul results without exception? Some char_array values will be nul-terminated, whereas others might either not contain a nul, or contain a nul as an interior char. So when you convert these to Ada strings you have to indicate your intent. That is the point behind the Trim_Nul parameter for To_Ada. If you expect the C char_array to be nul terminated, and you want to strip the nul when you convert it to Ada, then set Trim_Nul to true. In such a case the absence of a nul in the C char_array is an error, so Terminator_Error is propagated. If a nul in the char_array is not to be trimmed, or if there might not be a nul there, then set Trim_Nul to False. In this case the absence of nul is not an error. These semantics seem pretty intuitive to me. It would be inefficient to require the program to check for nul termination explicitly with a call on Is_Nul_Terminated before doing the conversion since the same string scan is done in the termination check and the conversion. -Ben Brosgol brosgol@aonix.com From lehman@ida.org Wed Jan 8 21:29:23 1997 Return-Path: Received: from inmet.camb.inmet.com by camb.inmet.com (SMI-8.6/SMI-SVR4) id VAA08868; Wed, 8 Jan 1997 21:29:22 -0500 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA13643; Wed, 8 Jan 97 21:29:51 EST Received: from ida.org by sw-eng.falls-church.va.us (8.7.1/) id CAA01418; Thu, 9 Jan 1997 02:26:43 GMT Received: from poseidon.csed.ida.org by ida.org (4.1/SMI-4.1) id AA04225; Wed, 8 Jan 97 21:25:46 EST Received: by poseidon.csed.ida.org (SMI-8.6/SMI-SVR4) id VAA01556; Wed, 8 Jan 1997 21:27:16 -0500 Date: Wed, 8 Jan 1997 21:27:16 -0500 From: lehman@ida.org (Dan Lehman) Message-Id: <199701090227.VAA01556@poseidon.csed.ida.org> To: ada-comment@sw-eng.falls-church.va.us Subject: Re: Interfaces.C.Strings.Value with len returning String Cc: brosgol@east.alsys.com X-Sun-Charset: US-ASCII content-length: 1475 !topic Interfaces.C.Strings.Value with len returning String !reference RM95 B.3.1(40) !reference 1997-15695.a !reference 97-15696.a !reference 97-15703.a !from Dan Lehman 1997-01-08 <> !discussion Well, I am ready to become *informed*, but on face value I'd rearrange Ben's words for quite different semantics--as: | If you expect the C char_array to be nul terminated [but it is NOT], | in such a case the absence of a nul in the C char_array is an error, | so Terminator_Error is propagated. [regardless of what was to be done with the nul by To_Ada!] I.e., I don't see (but others can enlighten me) that, for only one of these cases, the absence of a nul terminator is (more likely) an error: If you want to strip the nul when you convert it to Ada, then set Trim_Nul to true. If a nul in the char_array is not to be trimmed, then set Trim_Nul to False. I'm suggesting/asking that To_Ada with Trim_Nul=True has a main function of providing nul-free strings, not of checking char_arrays for nul. In this light, raising T_E seems unwanted. (And, in this regard, To_Ada with Trim_Nul=False *might* be seen to have a main function of yielding strings WITH nul--e.g., if the Ada code is building a table of strings intended to be later exported/shared with a C program (so needing nul termination).) Terminator_Error is only raised by To_Ada (in, I ask, one dubious case) and To_Chars_Ptr (when nul_check=true--a non-dubious case! :-). ---Dan ------- *