Hi, > > > > >> > Since we have bytestream_put and _get which changes the pointer every > > > > >> > time, anyone against _change and _show which does the same, but without > > > > >> > advancing the pointer? > > > > >> > > > > >> are they needed for any code? if no theres no sense in adding them > > > > >> currently, also i dont like redundancy (LE/BE* / bytestream_show()) > > > > > > > > > > I'm doing some code, which needs this. Currently it has LES_8/16/32 for > > > > > writing such values, and LE_8/16/32 for reading. > > > > > > > > > > Which is better, adding LES_ or extending bytestream_ and replacing all > > > > > LE_ occurances too? > > > > > > > > Do not add anything with generic names like LE_*. > > > > > > what about > > > AV_<L|B><R|W><2|4|8> ? > > > > > > so that for example AV_BW4 would be a big endian 32bit write ... > > > > And you plan to remove the current bytestream_ stuff? I dont get the > > rationale in this. > > i am speaking about LE_* BE_* stuff not bytestream_ stuff We have actually semi duplicates now. Bytestream stuff and LE/BE lot of codes use LE/BE for sequantial reading, thus advancing the pointer after reading. Per my understanding, this would be the preferred way now: * add AV_xyz, where x is L/B (little/big), y is R/W and z is the width (2,4,8) (altought I would prefer AV_<R/W><L/B><8/16/32> * change bytestream functions to use the above macros * change all the old code which uses LE/BE for sequential reading to use bytestream If I got this right, I will implement it now. -- Alex Beregszaszi
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4