beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: https://libera.irclog.whitequark.org/picolisp | Check www.picolisp.com for more information
seninha has quit [Quit: Leaving]
hrberg has quit [Ping timeout: 250 seconds]
hrberg has joined #picolisp
rob_w has joined #picolisp
beneroth has quit [Ping timeout: 276 seconds]
beneroth has joined #picolisp
seninha has joined #picolisp
<fbytez> It seems that `(char)` and `(peek)` skip single NULL bytes and return NIL on consecutive ones;
<fbytez> `(line)` seems to read them as any other character;
<fbytez> `(from)` seems to pay them no attention;
<fbytez> `(till)` will always stop at a NULL.
<abu[m]> This may well be. As I said, a null byte is not expected in an input stream. Thus it is used as "uninitialized" for the internal $Chr global variable.
<fbytez> I would've thought that `(line)` and `(from)` were implemented in terms of `(char)` and `(peek)`, yet the behaviour is different.
<abu[m]> They all use $Chr, but do not really call (char) or (peek)
<fbytez> Why do they treat the (= $Chr 0) differently?
<abu[m]> Basically, $Chr is checked before every read operation, and if zero, a prefetch triggered to fill it first
<abu[m]> Stress here on *before*
<abu[m]> i.e. to handle a freshly opened stream
<abu[m]> after that, $Chr is assumed to hold a non-zero byte
<fbytez> Yeah, I'm not understanding why `(line)` doesn't skip but `(char)` and `(peek)` do.
<fbytez> Well, and `(line)` doesn't get "interrupted".
<abu[m]> It is all a consequence of the above
<abu[m]> They do not "skip"
<abu[m]> They just fill on the first call
<abu[m]> (vi 'line)
<abu[m]> ... (unless C (setq C (call $Get))) ...
<abu[m]> Similar in all reading functions
<abu[m]> (de read1 ((i32 . End)) (unless (val $Chr) (call $Get) )
<fbytez> I mean in the sense that `(line)` "provides" the NULLs whereas the others are "interrupted"; can't determine EOF.
<abu[m]> As (char) and (peek) handle only one single char, this test happens upon each call
<abu[m]> I don't remember the details of (line) atm
<abu[m]> (out "a" (wr 65) (wr 0) (wr 66) (wr 10))
<abu[m]> (in "a" (line)) -> ("A" NIL "B")
<abu[m]> Anyway, this is undefined behavior
<fbytez> It's not something you'd ever change?
<abu[m]> Never ever ☺
<fbytez> That's unfortunate.
<abu[m]> You can produce tons of illegal input
<abu[m]> It is not only the null bytes
<abu[m]> Why care? Garbage in, garbage out
<fbytez> Security experts could give you better answers than me.
<fbytez> That aside, why waste time processing garbage as though it's not?
<abu[m]> It is not a security issue
<fbytez> "Fail fast".
<abu[m]> No! Why waste time checking for thins which should be checked at better places
<abu[m]> In 99% percent you are *sure* there is no null byte. Why check each time?
<abu[m]> Do you also check that after adding 3 and 4 it is *really* 7 ?
<fbytez> Depends on how it has supposed been determined.
<abu[m]> If you generated the data, they are OK. Period. If they might be damaged during transmission, you need general integrity checks
<fbytez> "IF"
<abu[m]> not at hoc stupid isolated checks
<abu[m]> Come on!
<fbytez> "Come on" indeed. A server doesn't mostly receive data that it generated itself.
<abu[m]> Then they must be checked in an intelligent way. Not at the low level byte reading.
<fbytez> Byte is what all the data is.
<abu[m]> But not only null bytes
<fbytez> Indeed.
<abu[m]> If a client sends garbage, it may be wrong data
<abu[m]> Or non-UTF
<abu[m]> doesn't matter
<fbytez> Yep. It has be parsed / validated / whatever.
<abu[m]> Pil does not crash, just the user's data are garbage
<abu[m]> You are free to modify pil input Have fun!
<abu[m]> I think this is not a security problem. It is all about the semantics of user data.
<abu[m]> It may be all legal digits, but still the numbers might be wrong
<abu[m]> There is no general check to be hardcoded, and which then eats CPU time every time
<abu[m]> Then, the next problem is that if you abort at such a low level, it is very hard to handle at the higher application levels
<abu[m]> Have you ever written a real practical application?
<abu[m]> And do you know what "premature optimations" are?
<fbytez> Do you know how sensitive, defensive and rude you are?
<abu[m]> Oops, no, I don't know. Sorry!
<abu[m]> I just asked you
<abu[m]> Your views are typical for academic text books, from authors who never wrote a real program ;)
<abu[m]> So I assumed you are a student
<abu[m]> Perhaps I'm rude because all this is totally opposite the PicoLisp philosopy