#pragma strict_types
int main (int argc, array(string) argv)
{
string s = argv[0];
Stdio.File ("test", "cw")->write (s);
}
produces these warnings for the write call:
foo.pike:5: Warning: Type mismatch in argument 1 to write.
foo.pike:5: Warning: Expected: array(string(0..255)) | string(0..255) |
__attribute__("sprintf_format", string(0..255)).
foo.pike:5: Warning: Got : string.
This is strictly speaking correct and in the long run it's probably a
good idea to restrict I/O functions to octet strings. But in practice
this warning is very cumbersome and will probably cause widespread
proliferation of the fairly clumsy type "string(0..255)" if one tries
to fix it. My view:
o There should be a better type name than "string(0..255)" for octet
strings. (That type cannot be a typedef since typedef'ed types
still don't work very well.)
o If we're to separate the types for octet and char strings, I think
it should be done also when char strings happen to contain only
narrow 8-bit chars. I.e. the string width is not really the
important characteristic, rather it's whether the string contains
characters or binary octets.
o Fixing the types for the I/O functions requires discussion (see
e.g. points above). It ought to be done consistently over all I/O
subsystems. Compat and utility functions might be required. This is
not something to embark on at this time, I think.
To sum up, for 7.8 I think it's better to not introduce string(0..255)
in write() etc. Opinions?
