On Jan 6, 2009, at 1:03 AM, Alan W. Irwin wrote: > Hi Jerry: > > I noticed some garbage after the device name for the Ada thick and > thin > example 31 results in stderr.
Thanks for catching that--I don't know where my stderr output goes. Or more likely, this line was not executed when I ran the example. > In contrast to this less-than-ideal result > for plgfnam, plgver produces good looking results for Ada thick and > thin > example 1 library version. There plgver is called using the > functional form > without arguments so I tried to do the same for plgfnam and it > didn't work. > > IMO, plgdev, plgfnam, and plgver (and their thick versions) should all > be implemented identically in the bindings since they all produce > strings. Accordingly I have made some Ada bindings changes as > of revision 9259. > > Note, there was no way I could get the procedure version of plgfnam > to work > with the To_Ada second argument True, so I uniformly set that to > False for > all procedure versions of plgdev, plgver, and corresponding thick > versions > in analogy with the existing plgfnam procedural version. Unless > the analogy > is wrong for some unknown reason this should be the right thing to > do, but > note we do not test the procedural versions of anything but plgfnam > so these > API changes are untested by any of our tests. Setting the second parameter in To_Ada (full name is Interefaces.C.To_Ada, FWTW) to False should be best, as you found. Ada String (one of three string types in Ada) is an array of Character (char) that is _not_ terminated by null. (Null is not needed in Ada since the length of the array is known.) In the case of e.g. plgfnam, the String PL_Output_File_Name is declared to be an array of length 80, 0..79. As I understand it, the call to C (PLplot_Thin.plgfnam) will fill up that array with 80 characters beginning from 0 offset, one of which is null. To_Ada converts that to an Ada String that is manufactured on the spot to be exactly the right length; if the second argument to To_Ada is True, a null character is appended; if False, no null character is appended. Thus, the length of the Ada string will vary by 1 depending on whether the second argument is True or False. > > I also changed the Ada 31st examples to use the new function > version of > plgfnam (and its thick counterpart) when outputting results to > stderr, and > it no longer has garbage after the output name. I can see where the garbage came from--fnam is an 80-character string and Ada appended all 80 characters to the argument in Put_Line. It put out not only the null character but everything after that, all 80 characters. > > Thus, everything seems to be working correctly with my changes with no > garbage output results for examples 31. However, I am programming > by analogy > here with no deep understanding of what I am doing so will you > please review > my changes? Your changes look good. The only thing I see odd is that the new function version of plgfnam has To_Ada(blabla, True) and I think you want that to be False, like the other instances. > > N.B. I am pretty sure you could stick strictly with the procedural > form of > plgfnam (and thick counterpart) in Ada examples 31 if you used some > string-trimming function to get rid of the trailing garbage for the > filename > output to stderr. However, please do not do that since I think the > current > implementation in Ada examples 31 is a better way to go since it > exercises > both the procedural and functional forms of plgfnam while also > getting rid of the trailing garbage in stderr. Yes--that string-trimming function is performed by To_Ada, as I described above. Example 31 could have been repaired like this: Put_Line(Standard_Error, "Output file name is " & To_Ada(fnam, False); but, as you say, that is an inconsistent use between these three string-returning functions/procedures. FWIW, I wrote a little Ada program that outputs a string with a null character at the end. When it went to the terminal, the null character was suppressed but when I redirected the output to a text file, the null character was present. Maybe this is a Unix thing. > > Alan > __________________________ > Alan W. Irwin > > > On 2009-01-06 00:03-0800 Alan W. Irwin wrote: > > >> >> N.B. I am pretty sure you could stick strictly with the procedural >> form of >> plgfnam (and thick counterpart) in Ada examples 31 if you used some >> string-trimming function to get rid of the trailing garbage for >> the filename >> output to stderr. However, please do not do that since I think >> the current >> implementation in Ada examples 31 is a better way to go since it >> exercises >> both the procedural and functional forms of plgfnam while also >> getting rid of the trailing garbage in stderr. >> > > Hi Jerry: > > I woke up this morning with a different conclusion on this matter. > There is > no need to slavishly follow the C language and provide a procedural > form to > return strings using argument lists. Instead, the functional form > is fine. > This is well understood, for Python, for example, where all > returned values > must be implemented with a functional form. Also, Doug and I have > just been > through this for the Perl/PDL examples. In general, the functional > forms of > plgdev, plgfnam, and plgver are just much easier to use for returned > character strings so that is all the Perl/PDL bindings provide, and > I think > we should do the same in Ada. I have looked at Ada examples 14 > which use > the functional form of plgdev to determine the value of an > Unbounded string, > and it is pretty clear that is a better way to go then the alternative > procedural form where you have to specify a string of sufficient > size so you > don't get a buffer overflow. This is just an accident waiting to > happen in > C, but there is no need to propagate that bad situation to other more > sophisticated languages such as Ada. > > So here is what I think should be done. Remove all the procedural > forms > of plgdev, plgfnam, and plgver and rely exclusively on the > functional form. > > Do you agree to this change? > I don't have a problem with that, so let's see what happens. However, there could be a problem at the documentation level. I think I mentioned one or two of the two previous function replacements in the Ada part of the docs, and I'll update it so that all three replacements are mentioned. But someone reading the main documentation might be puzzled since it indicates (in C) that they are procedures. Maybe it would be appropriate to add a note in the primary documentation which languages use function forms. Making these functions with a String argument should be OK generally-- Ada users are accustomed to passing String (of the three string types available--the others are Bounded_String and Unbounded_String) as arguments and converting as necessary, as in Example 14. That seems to be part of the Ada way, since string subroutines e.g. printing commands always take String, resulting in many lines that have string conversions in them, like this: Put_Line(To_String(A_String)) where A_String can be either of the other two kinds of Ada strings. I have to say that figuring out Ada's string facilities has caused me more than a little head scratching. > If so, I will do the work and change examples 31 accordingly. I can change 31--it will involve the use of Unbounded_String and I can probably do that more efficiently than you can. > > Alan ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
