Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

/cc @dotnet/interop-contrib

I'm not clear on why this change is so involved. If the goal here is just to use an initial stackalloc, why isn't it something more like main...stephentoub:runtime:readlinkstackalloc ?

I'm not clear on why this change is so involved. If the goal here is just to use an initial stackalloc, why isn't it something more like main...stephentoub:runtime:readlinkstackalloc ?

see this discussion :

#69335 (comment)

Rent may override last return (external code is depending on ReadLink last return to validate for example whether the file is really a symbolic link). So we need to relocate all validations done outside ReadLink scope and do it inside. We should also take into account that some callers do not care about validation, they want just the result.

Rent may override last return (external code is depending on ReadLink last return to validate for example whether the file is really a symbolic link)

Isn't that a separate issue from the stackalloc, and one that already exists?

Addressing that also shouldn't require lots of additional changes: the original error code can just be stored into a local with Marshal.GetLastPInvokeError and then restored as the very last thing done with Marshal.SetLastPInvokeError.

Addressing that also shouldn't require lots of additional changes: the original error code can just be stored into a local with Marshal.GetLastPInvokeError and then restored as the very last thing done with Marshal.SetLastPInvokeError.

Some of the callers ignore all errors (including the unexpected errors) and assumed that null means that the link does not exist. The earlier version of this PR tried to address this by turning unexpected errors into exceptions. @pedrobsaila Is it correct?

(It is fine to not address this issue as part of this PR.)

Addressing that also shouldn't require lots of additional changes: the original error code can just be stored into a local with Marshal.GetLastPInvokeError and then restored as the very last thing done with Marshal.SetLastPInvokeError.

Some of the callers ignore all errors (including the unexpected errors) and assumed that null means that the link does not exist. The earlier version of this PR tried to address this by turning unexpected errors into exceptions. @pedrobsaila Is it correct?

(It is fine to not address this issue as part of this PR.)

it is correct

it is correct

Thanks. Then yeah, sounds like those call sites should be fixed separately after this PR goes in.

Thanks. Then yeah, sounds like those call sites should be fixed separately after this PR goes in.

Opened #71970