chr(0) has a string length of 0

[maxxon]

assert(chr(0).strlen == chr(1).strlen, \
"chr(0) has a string length of "+chr(0).strlen.string+\
" while chr(1) has a string length of "+chr(1).strlen.string+".")

This is kinda annoying. Do you use C's strlen to calculate a length of a string? Are you not using the std::string class?

Thanks,


|\/|x

[Gavino]

Avisyth strings are implemented internally as null-terminated sequences of characters, following the C convention (and allowing the use of standard C library functions). Therefore, a string cannot itself contain a null byte.

The chr() function currently does no checking on its argument. Perhaps chr(0) should be illegal (and values > 255 or negative should also be rejected).

[jmac698]

It also comes up in this case

s=chr(65)+chr(0)+chr(66)
messageclip(s)

This is bad for writefile creating any type of binary.

[TheFluff]

What results are you expecting to get from putting an ASCII NUL in a C or C-like string? Even in a std::string, using \0 has a number of more or less subtle gotchas. I'd say the current behavior is perfectly logical and consistent.

jmac's use case is patently insane; using Avisynth script to do binmode I/O is a terrible idea in pretty much every possible way.

[jmac698]

How else should I extract closed captions from a video (as little white lines), and write it to a standard cc.bin file? Are you saying script should make it impossible to program such a utility? That just makes no sense. Why should I care about C strings? That's an implementation detail. I want a script that lets me work with binary. WriteFile only writes strings.

[Gavino]

Strings in the script language are designed to handle text.
If you want binary output, you can always write your own plugin.

[jmac698]

So there's serious limitations in the script language then. I believe I had this discussion before (about Avisynth being incomplete), but someone said it was Turing complete and you could write anything with it, but that's not the practical reality. But here's a happy thought, I could emote uuencode.

[TheFluff]

How else should I extract closed captions from a video (as little white lines), and write it to a standard cc.bin file? Are you saying script should make it impossible to program such a utility? That just makes no sense. Why should I care about C strings? That's an implementation detail. I want a script that lets me work with binary. WriteFile only writes strings.

Basically what Gavino said. Strings in Avisynth script are C strings. That's not an "implementation detail", it's their fundamental data type. If you want binary output, write a plugin; it'll most likely be about an order of magnitude faster anyway. (This advice sure does feel familiar for some reason.)

If you feel you just have to abuse Avisynth scripting for absolutely everything under the sun, write a plugin that does what you want in the most generic way possible; i.e. a plugin that provides functionality for working with general byte arrays in various ways. It's not particularly hard; you can just pretend env->NewVideoFrame() is malloc() and take it from there.

So there's serious limitations in the script language then. I believe I had this discussion before (about Avisynth being incomplete), but someone said it was Turing complete and you could write anything with it, but that's not the practical reality. But here's a happy thought, I could emote uuencode.
It is Turing complete and you can indeed write anything, it just doesn't necessarily have to be convenient to do so. Furthermore, I think you've misunderstood what Turing completeness means; it only concerns the computability of numeric algorithms, not funny side-effect stuff like the ability to do file I/O.

[maxxon]

This has become quite a funny thread. :D

I only find this annoying only because the std::string class actually does allow for '\0' characters and I was considering embedding a binary number inside a string:sly:. I actually tried and succeeded to make a base255 lib just for fun. Though I doubt I'd put it in the production code of AviSynthLib.

I do understand that if you were to try and use a function that required a C-string, this would not work as expected, but what C functions are you using in a C++ environment? Just because they are available, doesn't mean that should be used. I don't think plugins should be a concern in this regard either as long as this is documented well.

Gavino and TheFluff are correct though, if someone wanted to generate a binary file, a plugin is a logical and faster workaround. I also do find that string parsing is quite slow, but this is really starting to get beyond its real purpose: To be a video manipulator, not a string editor. :p


|\/|x