Skip to content

Deprecate __LINE__ and __FILE__ #1068

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

Closed
Rangi42 opened this issue Sep 29, 2022 · 0 comments · Fixed by #1072
Closed

Deprecate __LINE__ and __FILE__ #1068

Rangi42 opened this issue Sep 29, 2022 · 0 comments · Fixed by #1072
Labels
enhancement Typically new features; lesser priority than bugs rgbasm This affects RGBASM
Milestone

Comments

@Rangi42
Copy link
Contributor

Rangi42 commented Sep 29, 2022

The advantage of these constants in C is that they're not affected by macros, so you can have a "utilities.h":

#define crash(msg) exit((fprintf(stderr, "%s(%d): %s", __FILE__, __LINE__, msg), 1))

And then crash("oops"); on line 42 of main.c will print "main.c(42): oops", not "utilities.h(6): oops".

On the other hand, rgbasm does not work like that. __FILE__ and __LINE__ use their deepest context in the fstack of include, rept, and macro nodes. So they're only useful for local reporting, but then, you already know what line you're on when you write them.

If anything, it would be more useful to expose other dynamic information. Such as the current section name, which #1066 would allow with SECTION(@). Or the current "label scope", a concept which is mentioned in rgbasm(5) but not currently accessible. (Similar to __func__ in C99, or __FUNCTION__ in gcc prior to that.) That would let you do this in utilities.inc:

MACRO error
    FAIL STRFMT("In section \"%s\", label %s: %s", SECTION(@), __LABELSCOPE__, \1)
ENDM
@Rangi42 Rangi42 added the rgbasm This affects RGBASM label Sep 29, 2022
@ISSOtm ISSOtm added the enhancement Typically new features; lesser priority than bugs label Sep 29, 2022
@Rangi42 Rangi42 added this to the 0.6.0 milestone Sep 30, 2022
Rangi42 added a commit to Rangi42/rgbds that referenced this issue Sep 30, 2022
Unlike C, these constants are not convenient for logging in macros,
since they always report the same data (their location in the macro).

Fixes gbdev#1068
Rangi42 added a commit to Rangi42/rgbds that referenced this issue Sep 30, 2022
Unlike C, these constants are not convenient for logging in macros,
since they always report the same data (their location in the macro).

Fixes gbdev#1068
Rangi42 added a commit to Rangi42/rgbds that referenced this issue Sep 30, 2022
Unlike C, these constants are not convenient for logging in macros,
since they always report the same data (their location in the macro).

Fixes gbdev#1068
ISSOtm pushed a commit that referenced this issue Sep 30, 2022
Unlike C, these constants are not convenient for logging in macros,
since they always report the same data (their location in the macro).

Fixes #1068
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Typically new features; lesser priority than bugs rgbasm This affects RGBASM
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants