[linux-lvm] [lvm-devel] MUSL fun

Brendan Heading brendanheading at gmail.com
Sat Feb 13 21:19:56 UTC 2016

> 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.


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.


More information about the linux-lvm mailing list