Thanks for you feedback Felix, I talked to Peter on #chicken and he wasn't happy about another foreign-type. I suppose I agree with him, there are quite a few already and maybe it'll just be confusing: having a "c-string" and a "string" foreign type would probably do more harm than gain.
I decided to do a (c-pointer char) and wrap the string argument in (location ...) which isn't all that bad. I couldn't use scheme-pointer because my C-function argument is already declared as char* and not void*. And I guess string->blob/shared isn't all that useful if no other Schemes support it and we have plenty of other workarounds. I never really got blobs anyway, when do you *not* just want to use a string instead? They print so much nicer than blobs, even with binary data that's escaped with \x! K. On Fri, Jun 27, 2014 at 11:05 AM, Felix Winkelmann < felix.winkelm...@bevuta.com> wrote: > > Oh, I see. I though it was meant to be used interchangeably. I can't use > > string->blob, though, because that will copy the data and I need to > modify > > it from C. What foreign type should I use for this sort of thing? > > > > - (c-pointer char) with (location "string") works, but is a lot of typing > > > > - scheme-pointer seems to work, but: > > > > requires type cast in C: > > > > (print ((foreign-lambda* c-string ((scheme-pointer x)) "((char*)x)[0] = > 65; > > return(x);") "xBC")) > > > > allows all types, I just want blob/string: > > > > (print ((foreign-lambda* c-string ((scheme-pointer x)) "((char*)x)[0] = > 65; > > return(x);") 45.0)) > > > > is there a "string" foreign type that works like "blob", that provides a > > (char*) argument and checks that argument is a string? Or is there a > > string->blob/shared procedure anywhere? > > You could also keep everything as it is and ignore the warning, but I > understand that it isn't the cleanest solution. I'm not aware of any > documented interchangability between strings and blobs, it is an > implementation artefact. "string->blob/shared" would make sense but is > not possible in the current implementation (srfi-4 vectors have an > indirection to the raw data buffer, there this conversion only changes > the wrapper object, but strings and blobs contain the data without the > indirection.) > > So, I can't think of a solution that answers all of your questions. > I would go with the scheme-pointer. > > We could add another foreign type, that accepts strings but doesn't > copy. I'll look into that. > > > felix >
_______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers