Enable socket options definitions

[loganek]

Fixes #304

[sunfishcode]

My main question here is whether it's better to define all of these macros, or to selectively define only the ones which WASI is expected to support. For example, let's say something like SO_ATTACH_BPF doesn't happen for the foreseeable future. Is it better for WASI to define it and have it fail at runtime, or to leave it undefined?

[loganek]

My main question here is whether it's better to define all of these macros, or to selectively define only the ones which WASI is expected to support. For example, let's say something like SO_ATTACH_BPF doesn't happen for the foreseeable future. Is it better for WASI to define it and have it fail at runtime, or to leave it undefined?

Yeah, I did think about it; on one hand it's better to handle unimplemented properties as early as possible (in that case, at compilation time). On the other hand, that will make porting code to WASM more difficult. This will be especially hard for the code that doesn't use non-supported properties, but e.g. relies on 3rd party dependency that under the hood uses it in some branches that are very unlikely to be hit. Not sure if there's a general guidance or if there were similar situations before - we either prioritize safety and avoid runtime errors (even for properties that aren't likely to be used anyway) or we lean towards ease of porting existing codebase. I'm personally less concerned about runtime errors as this can be handled at the testing stage; at the same time I'm aware of the status of test coverage for multiple projects around... I'm curious to know what are the community thought on that.

[sbc100]

We could always introduce more macros like _WASI_EMULATED_SIGNAL.. perhaps we could have a single one that enables maximum source compatibility, for folks that just want to get something building?

[yamt]

My main question here is whether it's better to define all of these macros, or to selectively define only the ones which WASI is expected to support. For example, let's say something like SO_ATTACH_BPF doesn't happen for the foreseeable future. Is it better for WASI to define it and have it fail at runtime, or to leave it undefined?

Yeah, I did think about it; on one hand it's better to handle unimplemented properties as early as possible (in that case, at compilation time). On the other hand, that will make porting code to WASM more difficult. This will be especially hard for the code that doesn't use non-supported properties, but e.g. relies on 3rd party dependency that under the hood uses it in some branches that are very unlikely to be hit. Not sure if there's a general guidance or if there were similar situations before - we either prioritize safety and avoid runtime errors (even for properties that aren't likely to be used anyway) or we lean towards ease of porting existing codebase. I'm personally less concerned about runtime errors as this can be handled at the testing stage; at the same time I'm aware of the status of test coverage for multiple projects around... I'm curious to know what are the community thought on that.

while i can understand the argument for things like SO_LINGER,
i don't think it makes much sense to have very linux-specific stuff, which is not portable regardless of wasi.