strlen

2018-02-02 Thread ceder (-) Per Cederqvist @ Pike (-) developers forum
https://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/strlen.html says that strlen is deprecated and that we are supposed to use sizeof instead. At the same time, I see new Pike code beeing committed that use strlen (282a8a93 by Grubba 2018-01-04, a5c5c7cd by Bill 2017-12-22, be932f5

strlen

2018-02-02 Thread ceder (-) Per Cederqvist @ Pike (-) developers forum
Oh. Right. Are there any plans to actually remove strlen? http://pike.lysator.liu.se/docs/man/chapter_3.html documents strlen without mentioning that it is deprecated. It also states that the return type of sizeof is string, which seems wrong.

strlen

2018-02-02 Thread Henrik Grubbstr�m (Lysator) @ Pike (-) developers forum
>https://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/strlen.html >says that strlen is deprecated and that we are supposed to use sizeof >instead. At the same time, I see new Pike code beeing committed that >use strlen (282a8a93 by Grubba 2018-01-04, a5c5c7cd by Bill >2017-12-22, be

strlen

2018-02-02 Thread Martin Nilsson (Coppermist) @ Pike (-) developers forum
>Are there any plans to actually remove strlen? No.

Re: strange error on cross-compiled pike 8

2018-02-02 Thread H. William Welliver III
The configure test sets PIKE_BYTEORDER to 0 because (obviously) it can't test that when cross compiling. It seems like having a byteorder of "0" ought to be a failure, and possibly a way to define it manually, since there doesn't appear to be a consistent convention (ie, if not explicitly big-en

pike version when cross compiling

2018-02-02 Thread H. William Welliver III
I also noticed that the script run during make install assumes that the version of the pike executable running the installer is the version being installed. Perhaps it should actually look at the version it's installing? For instance, when cross compiling the version could theoretically be diffe