On May 29 2025 22:51 grischka via Tinycc-devel <tinycc-devel@nongnu.org> wrote:
> On May 29, 2025 12:35:04 AM UTC, Lino Mastrodomenico
> <l.mastrodomen...@gmail.com> wrote:
> >E.g. this slightly modified test case returns 42 on GCC and Clang but 0x90
> >on the current TCC mob:
> >
> >static void my_cleanup(int **p) {
> > **p = 0x90;
> >}
> >
> >int test_cleanup(void) {
> > int n = 42;
> > int __attribute__((cleanup(my_cleanup))) *p = &n;
> > return n;
>
> Because what gcc does is "required semantics"? Maybe it is just undefined
> behavior, like in
> int n=0,*p=&n; return n + (*p=1);
I can't find a detailed specification for cleanup, so this might have
been initially undefined behavior or an implementation detail.
But Hyrum's Law (https://www.hyrumslaw.com/ ) requires that any such
undefined behavior becomes required semantics if it's implemented
consistently, and indeed it's common for glib/GTK code to assume that
the cleanup has not happened yet while the return expression is being
evaluated (in glib, g_auto is a wrapper around
__attribute__((cleanup))). See e.g. the code in this example, which
relies on this detail:
https://docs.gtk.org/glib/auto-cleanup.html#variable-declaration
And I confess I have an ulterior motive for wanting these semantics in
TCC: I'm working on implementing the defer statement in TCC and for
"defer" the ordering of the cleanup code and return is very explicitly
defined in the specification and matches what GCC does with
__attribute__((cleanup)). So if TCC followed that example, I could
share a lot of code between the handling of defer and cleanup.
For context, the defer statement is an upcoming C2y feature awaiting
approval:
https://thephd.dev/_vendor/future_cxx/technical%20specification/C%20-%20defer/C%20-%20defer%20Technical%20Specification.pdf
In fact since the C standard committee chose to to define "defer" with
a technical specification, it's likely that it will be officially
standardized years before C2y is finalized. I'll start a separate
thread with more details about defer once my patch is ready but I
wanted to mention here the potential overlap with cleanup and why I
care about this detail. Sorry for not mentioning it sooner.
> > When looking at the source code I'm tempted to swap leave_scope and
> > gfunc_return as Herman did.
>
> And what if there is no 'return'?
>
> printf("... %d\n", ({
> int __attribute__ ((cleanup(my_cleanup))) n = 42;
> n; }));
For statement expression, my expectation as end user is that the last
expression is effectively an implicit return and it should be
evaluated before the cleanups, and indeed that's what GCC and Clang
do. But I admit this might be less important since it's an interaction
between two GNU extensions and I can't find code that relies on this,
unlike the regular "return" case.
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
