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
