"Neagtive overflow" & other flaws in binary operations.

[ma9ik]

Hello,

Recently I've tried to use BASH to do some binary operations, that task turned out to be far more difficult, that I could ever imagined.

First of all, I've found out that 2 shifted to the left edge of boundary (2**63) produces as a result a negative number "-9223372036854775808" ("funny" thing is, when you substract "1" from this value, it gives positive value as a result), this problem is of course related to "u2 code", but still it's an error, which can cause various difficult to perceive problems during script execution - i.e. PERL deals with it by substituting integer value, with floating point value, which at least has a proper sign.

Another thing, which doesn't behave exactly the way it should, is bit shifting. While shifting positive value to the right gives 0 at the end, then shifting negative value gives "-1" at the end, again it's related to "u2 code". I.e. try to shift "1", 63 times to the left (it will turn into negative value), then shift it back to the right, you'll never guess it won't evaluate to "0" but to "-1"! This is error in "logic", which lays beneath this whole idea. Bit operations shouldn't be sensitive to "u2 coding", as coding is on higher abstract level then any of bit operations, which deals with "raw bits" on lowest level!

Genrally speaking, there is significant flaw in BASH, if it comes to any binary operations - with whole do respect, your whole idea is one big misconception. You've introduced all kinds of bit operators but they "works" only on numbers, if anyone try to use it on character, they won't work properly (those are some other "magical bits"?!). BASH for some reason is concentrated almost solely on strings (almost like PERL), reading & writing characters is relatively easy thing to be done but doing same thing with "raw data" (binary data) requires making crude workarounds (like using coreutils "od" to read data as numbers, not as characters & ab-using "printf" to later write them to the file), while it should be possible to do it easily by using only read & write commands - data stored in memory or on disc (or any other medium), are just bunch of bits, meaning of those bits is determined later, during processing (like in "C" language, where type "char" is in fact numeric & it's interpretation by some commands gives it special meaning) & programmer should be being able to decide the way he want to perceive those data!

I can see two solutions (one dosen't exclude the other) to this problem.

First one is to add commands which allows to read & write data the way, they could be processed always as numbers.

The other is to introduce user defined data types or at least add ability to control "data perception" (if they should be perceived as numbers or characters or some other way...i.e. references). Giving a user/programmer an ability to control "general" data type, will makes various operations easier, its results more predictable & the best thing is, it can be introduced the way, that doesn't require to change whole logic of BASH or even force scripts to be re-written - it might be an extension, which user uses only if necessary, if not the BASH behave as it is now.

To be honest, I would never dream (or I rather should write "to have a nightmare") to use BASH to do binary ops but unfortunatelly I've faced task which requires me to relay on it (& thankfully some of "coreutils"), I'm able to overcome all flaws mentioned above, using very coarse workarounds (essentially "hacking" some commands), to do the things, that should have been done easily, with full support of the enviroment.