diff options
author | Rich Felker <dalias@aerifal.cx> | 2024-07-05 13:22:25 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2024-07-05 13:22:25 -0400 |
commit | dd1e63c3638d5f9afb857fccf6ce1415ca5f1b8b (patch) | |
tree | efce49a1ae163adba9efc35a88062031843b8f8b /src/unistd/mips64 | |
parent | 008f737ddf5de815ef7e26d195767d927c8c8e76 (diff) | |
download | musl-dd1e63c3638d5f9afb857fccf6ce1415ca5f1b8b.tar.gz musl-dd1e63c3638d5f9afb857fccf6ce1415ca5f1b8b.tar.xz musl-dd1e63c3638d5f9afb857fccf6ce1415ca5f1b8b.zip |
syslog: revert LOG_FAC/LOG_FACMASK changes
commit 895736d49bd2bb318c69de99a05ea70c035c2da9 made these changes along with fixing a real bug in LOG_MAKEPRI. based on further information, they do not seem to be well-motivated or in line with policy. the result of LOG_FAC is not a meaningful facility value if we shift it down like before, but apparently the way it is used by applications is as an index into an array of facility names. moreover, all historical systems which define it do so with the shift. as it is a nonstandard interface, there is no justification for providing a macro by the same name that is incompatible with historical practice. the value of LOG_FACMASK likewise is 0x3f8 on all historical systems checked. while only 5 bits are used for existing facility codes, the convention seems to be that all 7 bits belong to the facility field and theoretically could be used to expand to having more facilities. that seems unlikely to happen, but there is no reason to make a gratuitously incompatible change here.
Diffstat (limited to 'src/unistd/mips64')
0 files changed, 0 insertions, 0 deletions