Feature survey: are convenient funtions like `uall`, `ptr_mangle`, `ptr_demangle` needed?

[RocketMaDev]

While tackling chanllenges, I find that some useful funtions like unpack 6 bytes of recv, processing pointers xored with fs:[0x30] not implemented yet. Could anyone tell me if these funtions are need to be implemented in pwntools? Plz let me know and I would like to include them in a new PR once I finished my first PR #2442.

[Arusekk]

I would love u48/p48, as well as ptr_mangle from glibc 2.4+ (I would love to get architecture-aware behaviour there), and maybe some ptr_mangle_cookie that would return the cookie suitable for ptr_(de)mangle, given actual pointer and mangled value.

[RocketMaDev]

I would love u48/p48...

But when recving heap address, another u40 is needed for glibc 2.32+, why don't we just create uall? @Arusekk

[Arusekk]

You cannot reliably uall on a tube, recv has to know the correct length or it can return patrial or extra data anyway. But unpack_all would be a better name than uall I guess.

[RocketMaDev]

Let me do some explanation. uall takes bytes object and convert it into int, not a tube. In other word, uall == unpack(word_size='all'), instead of unpack(recv(), 'all'). And uall is shorter and easy to type out just like u64. unpack_all is a bit too long.

[Arusekk]

I meant tube.u64() which expands to u64(tube.recvn(8)) and friends. I would still prefer both unpack_all and u48 (u40 can go there as well). Feel free to submit a PR with either combination.

[RocketMaDev]

I see. If we add u48 and u40, there will be less situations to call unpack_all. In that case, it doesn't matter if unpack_all is that long.