cargo:rustc-env=VAR=VALUE value restriction

[leongross]

Problem

Contrary to linux environments, cargo seems to limit the the range of accepted values to the printable ascii range. I see no reason to restrict this, especially since e.g. the linux environment can have any bytes as a value.

Steps

build.rs

use std::io::Write;

fn main() {
    std::io::stdout()
        .write_all(b"cargo:rustc-env=ENV_WRITE_INV=\xff\xfe\xdf\n")
        .unwrap();
}

main.rs

fn main() {
    dbg!(env!("ENV_WRITE_INV"));
}

error:

src/main.rs:6:10
  |
6 |     dbg!(env!("ENV_WRITE_INV"));
  |          ^^^^^^^^^^^^^^^^^^^^^
  |
  = help: use `std::env::var("ENV_WRITE_INV")` to read the variable at run time
  = note: this error originates in the macro `env` (in Nightly builds, run with -Z macro-backtrace for more info)

However in Linux this works as expected:

export TEST=$(echo -en "\xff\xfe\xfd")
echo $TEST | xxd

Possible Solution(s)

Accept all possible values, since I don't see any reason why this should be restricted.
Also this creates an inconsistency that is not necessary and can be confusing.

Notes

No response

Version

cargo 1.74.1 (ecb9851af 2023-10-18)
release: 1.74.1
commit-hash: ecb9851afd3095e988daaa35a48bc7f3cb748e04
commit-date: 2023-10-18
host: x86_64-unknown-linux-gnu
libgit2: 1.7.1 (sys:0.18.0 vendored)
libcurl: 8.4.0-DEV (sys:0.4.68+curl-8.4.0 vendored ssl:OpenSSL/1.1.1u)
ssl: OpenSSL 1.1.1u  30 May 2023
os: Fedora 37 (ThirtySeven) [64-bit]

[weihanglo]

There is a line that ignores non-UTF8 value from a build script directive.

cargo/src/cargo/core/compiler/custom_build.rs

Lines 793 to 796 in a885354

	let line = match str::from_utf8(line) {
	Ok(line) => line.trim(),
	Err(..) => continue,
	};

Cargo can possibly support that, though there might be some hard works of dealing with bytes. If I recall correctly, rustc emits dep-info as a UF8 file, and also writes those envs as String. There is also an unstable rustc option --env that you could pass sandboxed envs in. Unfortunately rustc CLI only accepts UTF8-encoded flags afaik. Hence, it is a broader issue than cargo itself.

Out of curiosity, could you share some use cases of that kind of environment variables?

[epage]

Supporting non-UTF8 would also make this platform dependent as Windows wouldn't support that. There is likely nothing platform independent that can be passed through here as OsStr is mostly opaque. That was recently relaxed some but there are a lot of complications when passing them between processes. It might be able to work but it'd require some decent analysis to be sure.