Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Fix printf segfaults with unassigned interfaces #2375

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 3 commits into from
Closed

Fix printf segfaults with unassigned interfaces #2375

wants to merge 3 commits into from

Conversation

@NotsoanoNimus
Copy link
Contributor

Printing interface-typed variables without an assigned value cause segfaults within the stdlib std::io::print functions. Also, empty fault values, while not really something that will occur, should at least output something when encountered.

Feel free to change the text for what's output on empty/null input for these two.

module eee;
import std::io;

interface Decl
{
}

struct TestS (Decl, Printable)
{
    int a;
}
fn usz? TestS.to_format(&self, Formatter* formatter) @dynamic => formatter.printf("[%d]", self.a);

faultdef DERP;

fn void main()
{
    TestS a = {100};
    Decl z = &a;
    io::printfn("%s", z);   // works fine to print "[100]"

    fault p; fault o = DERP;
    io::printfn("%s|%s", p, o);   // 'p' prints nothing; should at least show a placeholder

    Decl y;
    io::printfn("%s", y);   // stdlib segfault/runtime-error
}

Gives:

> c3c compile-run main2.c3
Program linked to executable './eee'.
Launching ./eee
[100]
|eee::DERP

ERROR: 'Out of bounds memory access.'
   [backtraces to std.io.Formatter.out_str]

After fix:

> c3c compile-run main2.c3
Program linked to executable './eee'.
Launching ./eee
[100]
<EMPTY-FAULT>|eee::DERP
<EMPTY-INTERFACE>
Program completed with exit code 0.

Book-reader
Book-reader reviewed Aug 6, 2025
View reviewed changes
Book-reader
Book-reader reviewed Aug 6, 2025
View reviewed changes
lib/std/io/formatter.c3
return self.out_substr((*(fault*)arg.ptr).nameof);
return self.out_substr((*(fault*)arg.ptr).nameof ?: "<EMPTY-FAULT>");
case INTERFACE:
if (!*(uptr*)arg.ptr) return self.out_substr("<EMPTY-INTERFACE>");
Copy link
Contributor

@Book-reader Book-reader Aug 6, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (!*(uptr*)arg.ptr) return self.out_substr("<EMPTY-INTERFACE>");
if (!((any*)arg).ptr) return self.out_substr("<EMPTY-INTERFACE>");

interfaces are stored as an any so while doing !*(uptr*)arg.ptr will work it's probably better to check it like this. it using a uptr also makes it depend on the fact that the any stores its pointer before its type and would break if that ever changes

Copy link
Contributor Author

@NotsoanoNimus NotsoanoNimus Aug 6, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very good observation and suggestion. I will make this change. And to reference your other comment, I think this particular check (once updated) can remain under interface to emit the <EMPTY-INTERFACE> text while an empty ANY TypeKind can simply emit <EMPTY>, so that there's at least a distinction to the empty value.

What do you think?

Copy link
Contributor

@Book-reader Book-reader Aug 6, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see any issue with that, I think the distinction would be good.

Book-reader
Book-reader suggested changes Aug 6, 2025
View reviewed changes
Copy link
Contributor

@Book-reader Book-reader left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the same error happens when printing something like (any)(int*)null so maybe the check could be moved to the case ANY check to catch that as well

@lerno lerno self-assigned this Aug 6, 2025
@lerno lerno added the Bug Something isn't working label Aug 6, 2025
@lerno lerno added this to the 0.7.5 milestone Aug 6, 2025
lerno added a commit that referenced this pull request Aug 6, 2025
@lerno
Formatter did not properly handle "null" for any, and null for empty …
9c770f3 
…faults. #2375
@lerno lerno added the Fixed needs testing Needs verification / testing that it now works label Aug 6, 2025
@lerno
Copy link
Collaborator

lerno commented Aug 6, 2025

Oops I didn't realize this was a PR. Epic fail.

@lerno lerno removed the Fixed needs testing Needs verification / testing that it now works label Aug 6, 2025
lerno added a commit that referenced this pull request Aug 6, 2025
@lerno
Updated like the PR #2375
29bae1f
@lerno
Copy link
Collaborator

lerno commented Aug 6, 2025

Ok, so I essentially integrated this in my own PR because I thought this was an issue. 🤪 . Mine just had "(null)" though, so I updated it with (empty-any) and (empty-interface) and (empty-fault) as per this PR. I added unit tests for it as well.

@lerno lerno closed this Aug 6, 2025
@lerno
Copy link
Collaborator

lerno commented Aug 6, 2025

Good find and thank you for taking the time with the PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

1 more reviewer

@Book-reader Book-reader Book-reader requested changes

Reviewers whose approvals may not affect merge requirements

Assignees

@lerno lerno

Labels

Bug Something isn't working

Projects

None yet

Milestone

0.7.5

Development

Successfully merging this pull request may close these issues.

3 participants

@NotsoanoNimus @lerno @Book-reader