Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Technically unsafe behavior in safe rust using #![no_main] #47685

Closed
CensoredUsername opened this issue Jan 23, 2018 · 7 comments
Closed

Technically unsafe behavior in safe rust using #![no_main] #47685

CensoredUsername opened this issue Jan 23, 2018 · 7 comments
Labels
C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@CensoredUsername
Copy link
Contributor

Using #![no_main], and a #[no_mange] pub static main array the linker will assume that the main array is actually the main function and execute whatever is in there. Outside of a warning for nonstandard naming this compiles fine on stable and nightly on both debug and release mode.

Example

This example will print the text Main is usually a function\n on x64 linux and probably crash violently on anything else.

It's rather hard to trigger this behavior without trying, but it should probably not compile without errors. Maybe add a check for #![no_main] crates that whatever's declared as #[no_mangle] main is actually a function with the correct signature.

Meta

The issue exists on rustc 1.25.0-nightly, rustc 1.23.0 and anything in between.

@retep998
Copy link
Member

retep998 commented Jan 24, 2018

#[no_mangle] is dangerous and unsafe in general. Combining it with #![no_main] is not a novel source of bad behavior.

#47449
#28179

@CensoredUsername
Copy link
Contributor Author

Whoops, missed those while searching (only searched for no_main).

It should be noted though that the proposed solution in the other issues (errors on duplicate symbols) would not work in this case as #![no_main] avoids emitting the main symbol in general.

@pietroalbini pietroalbini added C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 6, 2018
@MarkDDR
Copy link

MarkDDR commented May 3, 2018

Why does the compiler put the array of (effectively) bytes in .text instead of .data? That should prevent at least this particular instance from occurring.

@CensoredUsername
Copy link
Contributor Author

The correct place for it to be would be .rodata . But it used to be quite normal to map constants into the .text section. Mapping it into .data would be less efficient as .data has to be copied into the process memory space while .text can just be directly mapped into the process space.

@L-as
Copy link

L-as commented May 4, 2018

I don't think this should result in a compilation error, since it might be useful occasionally. However I do think there should be a lint against it, or perhaps some kind of unsafe {} required?

@steveklabnik
Copy link
Member

Triage: no change

@jonas-schievink
Copy link
Contributor

This is basically a duplicate of #28179, so closing in favor of that

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants