I'll add that even for non-extern types, preserving type alias symbols into the generated code would be useful from the perspective of readability of the generated code (which benefits developers more than users, but such developer benefits are important for accelerating the rate of progress).
-Brad On Tue, 7 Apr 2015, Michael Ferguson wrote: > Hi Jeff - > > c_char is the name of a type (defined in SysCTypes.chpl), > not a keyword. > > We do already support C strings - we have a c_string type > also available. That corresponds to 'const char*' which is > usually what you want, but not always. > > Suppose I'm trying to call an extern function taking in > a char** argument, in which it will return an allocated char*. > Right now, I can't even write Chapel code to add the > cast like > (char**) &myArgument > because Chapel doesn't understand char as distinct from int/uint(8). > > If we did support the tracking the extern types, you'd be able > to say something like > myArgument:c_ptr(c_char) > to achieve the cast. Right now such a manually-added cast doesn't > help... > > -michael > > On 4/7/15, 11:17 AM, "Jeff Hammond" <[email protected]> wrote: > >> Are all instances of "some_c_type" keywords in Chapel such that the >> compiler is certain to recognize them? I apologize for my Chapel >> ignorance, but I can't tell if "c_char" in your original example is >> your name or a keyword. >> >> As for the fundamental issue, as we've determined already, char isn't >> like int in that the signedness is not specified. However, rather >> than fight with char, why not go all the way to supporting C strings >> with 1 character a special case thereof? >> >> Best, >> >> Jeff >> >> On Tue, Apr 7, 2015 at 7:03 AM, Michael Ferguson <[email protected]> >> wrote: >>> Hi Jeff - >>> >>> I think you're more or less proposing that we add 'char' as a >>> sibling basic type to 'int' and 'real' etc in Chapel. I think >>> it would be better to update the compiler to emit the extern >>> type names. >>> >>> When you say >>> >>> extern type some_c_type = some_chapel_type; >>> >>> you're presumably doing that because you wish to pass variables >>> of type some_c_type to extern functions, so I think it makes >>> sense for the compiler to emit some_c_type in the backend in preference >>> to some_chapel_type. >>> >>> >>> Cheers, >>> >>> -michael >>> >>> On 4/6/15, 6:43 PM, "Jeff Hammond" <[email protected]> wrote: >>> >>>> Thanks for the clarification. Given that Chapel seems to be doing >>>> what it is asked in your example, is something like the following not >>>> appropriate to address the issue of char being ambiguous w.r.t. >>>> (un)signed? >>>> >>>> extern type c_char = char(8); >>>> >>>> I wonder how much it matters though, since the printable characters >>>> are always nonnegative >>>> [http://stackoverflow.com/questions/2054939/is-char-signed-or-unsigned-b >>>> y- >>>> default]. >>>> >>>> Best, >>>> >>>> Jeff >>>> >>>> On Thu, Apr 2, 2015 at 11:03 AM, Michael Ferguson <[email protected]> >>>> wrote: >>>>> Hi Jeff - >>>>> >>>>> Yes, many C compilers will give a warning if you >>>>> e.g. pass (int8_t*) into something expecting (char*), >>>>> because int8_t might be typedef'd to 'signed char', >>>>> and char could be unsigned as I understand it, so >>>>> the C compiler gives a signed-vs-unsigned warning... >>>>> >>>>> -michael >>>>> >>>>> On 4/2/15, 2:00 PM, "Jeff Hammond" <[email protected]> wrote: >>>>> >>>>>> What are the problems with external integration? int8_t is required >>>>>> by POSIX, at least if I understand >>>>>> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html >>>>>> correctly. Is the issue that it is not interoperable with char? >>>>>> >>>>>> Jeff >>>>>> >>>>>> On Tue, Mar 31, 2015 at 8:11 AM, Michael Ferguson <[email protected]> >>>>>> wrote: >>>>>>> Hi - >>>>>>> >>>>>>> If you say, for example, >>>>>>> >>>>>>> extern type c_char = int(8); >>>>>>> var x:c_char; >>>>>>> >>>>>>> then by the time the code is generated, we get >>>>>>> >>>>>>> int8_t x_chpl; >>>>>>> >>>>>>> which causes problems in a variety of extern integration >>>>>>> contexts. We want it to say rather: >>>>>>> >>>>>>> char x_chpl; >>>>>>> >>>>>>> >>>>>>> The question is - what do we need to do in order to fix it? >>>>>>> >>>>>>> I think that we need to do the following, but I wanted >>>>>>> to ask if there is another simpler approach? >>>>>>> >>>>>>> - add a normalizedType* to the Type class >>>>>>> - the compiler would generate 2 types where it used to do one: >>>>>>> -- Type for int(8) which would have normalizedType=this >>>>>>> -- Type for c_char with normalizedType = int(8) >>>>>>> - fix some or all Type* equality checks (possibly with C++ overload >>>>>>> of >>>>>>> ==) >>>>>>> to check normalizedType instead of Type* >>>>>>> - make sure that function resolution instantiates with the original >>>>>>> Type >>>>>>> instead of the normalizedType (e.g. so that c_ptr(c_char) ends up >>>>>>> generating as char* rather than int8_t*), even as it uses the >>>>>>> normalized type when deciding how to instantiate. >>>>>>> >>>>>>> Note that in some cases that would mean we would need to generate >>>>>>> two functions where we used to do only one: >>>>>>> >>>>>>> proc writeln(x) // if this is used with c_char and int(8), we need >>>>>>> >>>>>>> proc writeln(x:c_char) >>>>>>> proc writeln(x:int(8)) >>>>>>> >>>>>>> >>>>>>> >>>>>>> Is that a good approach? Are there better ideas? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -michael >>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> -- >>>>>>> -- >>>>>>> ----- >>>>>>> Dive into the World of Parallel Programming The Go Parallel Website, >>>>>>> sponsored >>>>>>> by Intel and developed in partnership with Slashdot Media, is your >>>>>>> hub >>>>>>> for all >>>>>>> things parallel software development, from weekly thought leadership >>>>>>> blogs to >>>>>>> news, videos, case studies, tutorials and more. Take a look and join >>>>>>> the >>>>>>> conversation now. http://goparallel.sourceforge.net/ >>>>>>> _______________________________________________ >>>>>>> Chapel-developers mailing list >>>>>>> [email protected] >>>>>>> https://lists.sourceforge.net/lists/listinfo/chapel-developers >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Jeff Hammond >>>>>> [email protected] >>>>>> http://jeffhammond.github.io/ >>>>> >>>> >>>> >>>> >>>> -- >>>> Jeff Hammond >>>> [email protected] >>>> http://jeffhammond.github.io/ >>> >> >> >> >> -- >> Jeff Hammond >> [email protected] >> http://jeffhammond.github.io/ > > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > Chapel-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/chapel-developers > ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
