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
