> commands/toolcontext.c: In function 'create_toolcontext': > commands/toolcontext.c:1796:10: error: assignment of read-only variable > 'stdin' > stdin = new_stream; > -- > > So now - from where comes the idea of 'stdin' being read-only variable ? > Looking at some POSIX spec e.g.: > http://pubs.opengroup.org/onlinepubs/009695399/functions/stdin.html > > there is no sign of having this read-only var. > > So what kind of OS this actually is ? musl's rather conservative interpretation appears to be that since the values of stdin, stdout and stderr are explicitly defined by POSIX, it is implicit that the variables holding these values should be const. http://www.openwall.com/lists/musl/2013/03/18/1 There's not a lot of point in debating the rights or wrongs of this. If it were me, I'd take a pragmatic approach, and if it were me I'd make this a configurable option, but this defeats musl's stated objectives and they won't accept a patch to change it. > There is a reason from lvm2 implementation here - freopen() is not giving > application full control over internal buffer allocation and we need to be > sure we lock-in memory for critical section - and some glibc versions are > allocating buffers here via 'mmap' call. > > That said - there could be accepted a patch checking in configure for > 'read-only' stdin - and using then #ifdef compilation that would > replace use of internal lvm2 reopen code with libc function. I had a suspicion you would have a good reason. On first glance your proposal sounds like a good compromise and one that would be worth exploring. Brendan _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
