westonpace commented on code in PR #34133:
URL: https://github.com/apache/arrow/pull/34133#discussion_r1139433788


##########
csharp/src/Apache.Arrow/C/CArrowSchemaExporter.cs:
##########
@@ -0,0 +1,265 @@
+// Licensed to the Apache Software Foundation (ASF) under one or more
+// contributor license agreements. See the NOTICE file distributed with
+// this work for additional information regarding copyright ownership.
+// The ASF licenses this file to You under the Apache License, Version 2.0
+// (the "License"); you may not use this file except in compliance with
+// the License.  You may obtain a copy of the License at
+//
+//     http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing, software
+// distributed under the License is distributed on an "AS IS" BASIS,
+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+// See the License for the specific language governing permissions and
+// limitations under the License.
+
+
+using System;
+using System.Collections.Generic;
+using System.IO;
+using System.Linq;
+using System.Runtime.InteropServices;
+using Apache.Arrow.Types;
+
+namespace Apache.Arrow.C
+{
+    public static class CArrowSchemaExporter
+    {
+        /// <summary>
+        /// Export a type to a <see cref="CArrowSchema"/>.
+        /// </summary>
+        /// <param name="datatype">The datatype to export</param>
+        /// <param name="schema">An allocated but uninitialized CArrowSchema 
pointer.</param>
+        /// <example>
+        /// <code>
+        /// CArrowSchema* exportPtr = CArrowSchema.Create();
+        /// CArrowSchemaExporter.ExportType(dataType, exportPtr);
+        /// foreign_import_function(exportPtr);
+        /// CArrowSchema.Free(exportPtr);

Review Comment:
   So let's split these into two points.
   
   1. I agree that `CArrowSchema*` needs to be freed.  I'm not sure it has to 
be heap-allocated.  I think it could be stack-allocated but I don't remember if 
`struct` was guaranteed to be stack allocated or not.  It's probably large 
enough (with all the strings) to justify heap allocation so I think this is 
good.
   
   2. I'm not sure that it is safe to assume that `release` has been set to 
null.  I do agree it is safe when calling Arrow-C++'s import function.  I just 
don't think this is part of the spec.  And, the spec is very clear that it is 
the consumer's responsibility to call the top-level `release` function.  So, 
while Arrow does copy everything into its own memory during it's import 
function I don't think this is spec-mandated.  Maybe it would be a good idea to 
add this mandate to the spec?
   



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to