I think that "Hyrum's Law" is a poor excuse for doing almost anything. If
you take that to the extreme, it can only be satisfied by implementing your
compiler exactly the same as the "standard" implementation, which is
obviously inconsistent with the goals of Tinycc, and can only result in
endless tracking down of edge cases involving undefined behavior, where the
actual remedy should be fixing code that makes use of undefined behavior.
An extreme example of how this goes wrong can be found in Windows XP. XP
was a BIG change to Windows, and one of its goals was to not break anything
that worked in Windows 98, or NT, or something like that. But LOTS of
things broke because a lot of applications had bugs like using pointers
after the memory had been freed, so the decision was made to not actually
have free() actually free memory. This was clearly a bad decision, because
it meant that you had to have far more memory on your computer for it to
handle a given workload, but it was "good" for Windows because it quickly
got a reputation for being an OS that "just works".
On Thu, May 29, 2025 at 6:10 PM Lino Mastrodomenico <
l.mastrodomen...@gmail.com> wrote:
> 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
>
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
