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-by- >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/ ------------------------------------------------------------------------------ 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
