Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

[Rob Landley]

On 5/14/22 11:56, Ivo van Poorten wrote:
> On Sat, 14 May 2022 04:31:24 -0500 Rob Landley  wrote:
>> On 5/11/22 11:55, Ivo van Poorten wrote:
>> > https://github.com/rui314/chibicc
>> 
>> Yeah, I saw your poke about that through the old qcc mailing list. :)
> 
> Haha, wasn't sure if it was still read, so I thought I'd post a link
> here, too. Wider audience, etc..
>  
>> kconfig/conf.c:38: static char nohelp_text[] = N_("Sorry, no help
>> available for this option yet.\n");
>> ^ expected ','
> 
> This looks like a cpp bug, assuming N_ is a macro. 

Yup, several other simple C compilers I tried had various cpp bugs, and more
than one didn't consider 'int a = 0 || "string";' to be a constant initializer
(but whatever the pointer for "string" is it CAN'T be NULL, and || returns 1 or
0 depending on whether its inputs are zero or nonzero, therefore...) See my
comment at the end of:

https://www.patreon.com/posts/building-toybox-66377238

(I would love to be able to link to the specific comment, but patreon doesn't
seem to have implemented that? You'd think when patreon raised its fees for new
creators they would have used the money to hire somebody, but they haven't
responded to vimeo exiting the video hosting business, still haven't fixed the
screen blanking bug, inexplicably handed half their market to onlyfans...)

(Huh, not "half": patreon pays out an average of $6.4 million/month so somewhere
under $100 million/year going through it, and onlyfans took in over $2 billion
in 2020. Meanwhile pornhub's annual revenue is $97 billion, about 5 times
prudetube's which pixelates out bikinis. Yup, humans continue to be hume.)

>> generated/obj/lib_args.o unknown argument: -funsigned-char
>> make: *** [Makefile:19: toybox] Error 1
>> 
>> There are some todo items, it seems. (Also, what targets does it
>> output code for? Hmmm, codegen.c looks like it's hardwired to x86?
> 
> chibicc could work like tinycc, having several codegen-*.c, and compile
> separate binaries for each target. Looks like it now solely targets
> x86_64.

Working like tinycc would mean also having a linker. Instead it generates text
assembly and feeds it through an external as. (Which is a choice, but means that
tinycc in 100k lines of code could run a program, and chibicc can't. In fact
half the reason people ever used tinycc was because #!/usr/bin/tinycc -run at
the top of your C file, with chmod +x, meant you could execute your C source.)

>> My
>> whole qcc idea was to glue qemu's tcg to the tinycc front end to get
>> all the targets qemu supports, but these days I think that's way
>> overkill...)
> 
> Probably. x86_64, arm64 and risc-v should cover most use cases.

I do not care about open Itanic, and am unlikely to start.

Meanwhile, open powerpc has cycled back around to relevance since Red Hat
reverse-bought IBM. They've been fairly quiet about it, but:

https://www.eejournal.com/article/ibm-gives-away-powerpc-goes-open-source/

https://hackaday.com/2020/08/28/open-hardware-laptop-built-on-power-pc-isa/

https://hardware.slashdot.org/story/21/07/10/0154220/libre-socs-open-hardware-180nm-asic-submitted-to-imec-for-fabrication

And so on, and so forth. Full 64 bit multi-issue speculative execution
instruction reordering song and dance, I'm told.

(And Jeff Dionne submitted a j-core mask to Google's sky130 fab earlier this
year, that's chugging along. He's being even quieter about it...)

>> Also, this is a compiler but not an assembler or linker. Or strip,
>> nm...
>> 
>>   http://landley.net/hg/qcc/file/tip/todo/commands.txt
>>   http://landley.net/hg/qcc/file/tip/todo/todo.txt
>> 
>> (My tinycc rewrite was going to make a multiplexer out of it so it
>> ran as the appropriate tool when called by the appropriate name.
>> Alas, stopped working on that in something like 2008?)
> 
> I remember. I have been "following" you for a while ;) Possibly
> from since around the time you forked tcc and got the BSD license
> permission from Bellard.

Sorry about the slow progress. There's more to do than I've had time for...

>> Do you think it's worth feeding the chibicc guy bug reports about
>> trying to build stuff with it?
> 
> I'm not sure. The github repo hasn't been updated in 17 months, and
> there is no book to be found yet.
> 
> But I found his earlier 2020 book. In Japanese:
> 
> https://www.sigbus.info/compilerbook
> 
> Perhaps one bug report to see if he's responsive?

It's a small and clean enough codebase somebody could theoretically fork it if
necessary. MIT license is reasonable. But one architecture, no assembler, no
linker... there's a todo list.

(I do NOT have the bandwidth, there's a reason I parked my tinycc fork. Toybox
and aboriginal linux were already two projects, and mkroot _needs_ to expand
into the space aboriginal linux used to do for toybox to have a proper
greenhouse to grow to full size in. Android's great but they mostly use what's
there and don't use what isn't. A system build environment 

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

[Ivo van Poorten]

On Sat, 14 May 2022 04:31:24 -0500 Rob Landley  wrote:
> On 5/11/22 11:55, Ivo van Poorten wrote:
> > https://github.com/rui314/chibicc
> 
> Yeah, I saw your poke about that through the old qcc mailing list. :)

Haha, wasn't sure if it was still read, so I thought I'd post a link
here, too. Wider audience, etc..
 
> kconfig/conf.c:38: static char nohelp_text[] = N_("Sorry, no help
> available for this option yet.\n");
> ^ expected ','

This looks like a cpp bug, assuming N_ is a macro. 

> generated/obj/lib_args.o unknown argument: -funsigned-char
> make: *** [Makefile:19: toybox] Error 1
> 
> There are some todo items, it seems. (Also, what targets does it
> output code for? Hmmm, codegen.c looks like it's hardwired to x86?

chibicc could work like tinycc, having several codegen-*.c, and compile
separate binaries for each target. Looks like it now solely targets
x86_64.
 
> My
> whole qcc idea was to glue qemu's tcg to the tinycc front end to get
> all the targets qemu supports, but these days I think that's way
> overkill...)

Probably. x86_64, arm64 and risc-v should cover most use cases.

> Also, this is a compiler but not an assembler or linker. Or strip,
> nm...
> 
>   http://landley.net/hg/qcc/file/tip/todo/commands.txt
>   http://landley.net/hg/qcc/file/tip/todo/todo.txt
> 
> (My tinycc rewrite was going to make a multiplexer out of it so it
> ran as the appropriate tool when called by the appropriate name.
> Alas, stopped working on that in something like 2008?)

I remember. I have been "following" you for a while ;) Possibly
from since around the time you forked tcc and got the BSD license
permission from Bellard.
 
> Do you think it's worth feeding the chibicc guy bug reports about
> trying to build stuff with it?

I'm not sure. The github repo hasn't been updated in 17 months, and
there is no book to be found yet.

But I found his earlier 2020 book. In Japanese:

https://www.sigbus.info/compilerbook

Perhaps one bug report to see if he's responsive?

> A chibicc/lld pair would be interesting (apparently the same guy
> wrong both),

Yes. Only as would be missing (as as in cc/as/ld). You mentioned strip,
nm, ... (objdump?) but those are not the first priority. Perhaps ld
could even have (or already has?) an option that strip becomes (almost)
obsolete?

> but this STILL hits
> the problem that llvm's libgcc replacement is apocalyptically bad:
> 
>   https://landley.net/notes-2021.html#28-07-2021
> 
> (You wouldn't think this was hard! And yet...)
> 
> The main reason Linux ate Minix is Andrew Tanenbaum wanted a teaching
> tool, and rejected patches that complicated his simple/clear project

Totally agree. I had classes from him back when Minix 2 was a thing,
but we also got Minix 1 floppies for the Atari ST and MSDOS :) I think
it was all about the book deal in the end.

Minix 3 was a step forward, as it was written from scratch and didn't
suffer the license dependencies that Minix 2 still had, but it failed to
really catch on. On the other hand, Intel apparently put it in their
"spy" part of their CPUs ;)

> Rob

Regards,
Ivo
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

[Rob Landley]

On 5/11/22 11:55, Ivo van Poorten wrote:
> On Wed, 11 May 2022 09:04:01 -0700 enh via Toybox
>  wrote:
>> there's plenty of C++ in the GNU stuff these days; that's orthogonal.
> 
> Yes. gcc cannot compile itself anymore without g++.

I've noticed. https://twitter.com/landley/status/983057803223891969

> chibicc looks promising.
> 
> https://github.com/rui314/chibicc

Yeah, I saw your poke about that through the old qcc mailing list. :)

$ CC=chibicc HOSTCC=$CC make defconfig
chibicc -o kconfig/conf kconfig/conf.c kconfig/zconf.tab.c -DKBUILD_NO_NLS=1 \
-DPROJECT_NAME=\"ToyBox\"
kconfig/conf.c:38: static char nohelp_text[] = N_("Sorry, no help available for
this option yet.\n");

^ expected ','
make: *** [kconfig/Makefile:73: kconfig/conf] Error 1
$ make distclean defconfig
...
$ CC=chibicc HOSTCC=$CC make V=1 CPUS=1
scripts/make.sh
Generate headers from toys/*/*.c...
generated/newtoys.h Which C files to build...
Library probe
Make generated/config.h from .config.
/home/landley/toybox/pending/chibicc/chibicc scripts/mkflags.c -o 
generated/mkflags
generated/flags.h generated/globals.h
chibicc scripts/mktags.c -o generated/mktags
generated/tags.h /home/landley/toybox/pending/chibicc/chibicc
scripts/config2help.c -o generated/config2help
generated/help.h
Compile toybox
chibicc -Wall -Wundef -Wno-char-subscripts -Werror=implicit-function-declaration
-funsigned-char -I . -Os -ffunction-sections -fdata-sections
-fno-asynchronous-unwind-tables -fno-strict-aliasing -DTOYBOX_VERSION="0.8.0" -c
lib/args.c -o generated/obj/lib_args.o
unknown argument: -funsigned-char
make: *** [Makefile:19: toybox] Error 1

There are some todo items, it seems. (Also, what targets does it output code
for? Hmmm, codegen.c looks like it's hardwired to x86? My whole qcc idea was to
glue qemu's tcg to the tinycc front end to get all the targets qemu supports,
but these days I think that's way overkill...)

Also, this is a compiler but not an assembler or linker. Or strip, nm...

  http://landley.net/hg/qcc/file/tip/todo/commands.txt
  http://landley.net/hg/qcc/file/tip/todo/todo.txt

(My tinycc rewrite was going to make a multiplexer out of it so it ran as the
appropriate tool when called by the appropriate name. Alas, stopped working on
that in something like 2008?)

> A book and all.
> 
> But so did pcc (haven't heard much about it lately) and tinycc (which
> is a mess with its mob branch, and it licensing).

I forked tinycc before that whole "mob branch" thing happened, and still have
that old fork:

  https://landley.net/code/qcc

I got permission from Fabrice Bellard to use his code under a BSD license (which
I'm interpreting to mean 0BSD), although I have to cull other developers'
patches from the result. I did the basic triage work once upon a time:

  http://landley.net/hg/qcc/file/tip/todo/relicense.txt

But I've been spread too thin and just haven't had TIME to work on that.

There are 4 packages to establish a base: 1) kernel, libc, cmdline, compiler.
The compiler has to be able to successfully build all four in order to get past
the circular dependency part into build-under-yourself territory.

It's theoretically possible to substitute a simpler kernel than linux (bsd or
xv6 or a forward-ported linux 2.0 before it hulked out), but I haven't looked
too deeply at what's available there. The https://midipix.org/ guys got musl to
work on the windows native API, and the BSD guys implemented a whole "linux
emulation layer" (https://docs.freebsd.org/en/articles/linux-emulation/) so in
theory reimplementing the API is a known-ish problem. (And yes /proc and /sys
are part of said API at the moment, Linux provides no other obvious way to get
access to that information...)

Once you've got a working base booted under qemu (or on real hardware; alas
raspberry pi is TERRIBLE for this both because it loads its proprietary bios
binaries from the sd card and because its serial console is on two random gpio
pins in the hat connector rather than somewhere SANE like the USB connection
that powers the board)...

Anyway, the next thing you want to be sure the tiny/simple compiler builds is
https://github.com/JuliaComputingOSS/llvm-cbe so you can build a modern full
compiler as necessary (and thus compile all the crap written in c++ that people
tend to want; getting llvm compiled to C by that is left as an exercise for the
reader, I.E. Way down on my todo list).

Then it's just "bootstrap your way through Linux From Scratch and then Beyond
Linux From Scratch" like I did for busybox back with
http://landley.net/aboriginal/control-images/

I would be absolutely thrilled if somebody ELSE did this, but...

https://lists.linuxfoundation.org/pipermail/celinux-dev/2010-January/000292.html

Alas, Howard Aiken was right:

https://www.inc.com/greg-satell/heres-why-you-shouldnt-worry-about-people-stealing.html

Do you think it's worth feeding the chibicc guy bug reports about trying to
build stuff with it? A 

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

[Rob Landley]

On 5/12/22 12:26, enh wrote:
> 
> 
> On Thu, May 12, 2022 at 9:56 AM Rob Landley  > wrote:
> 
> On 5/11/22 11:10, enh wrote:
> >> The next version of centos does not exist. Apparently Centos has
> completely gone
> >> away. Right, I can stop caring about it then I guess?
> >
> > (that was my reaction to the recent news, yes. "fine by me", since
> > centos was _always_ the most problematic distro to support, probably
> > because it naturally attracted the kinds of folks who _wanted_ to run
> > stuff from a decade ago.)
> 
> I can move from 7 years to 10 if there's specific demand for it,  but 7 
> was
> based on a lot of experience and a certain amount of research. It's enough
> Moore's Law half lives to get you down to about 2% of the installed base, 
> but
> it's ALSO where expertise in the old stuff seems to drop out of living 
> memory.
> 
> 
> (i think i've said before, but _our_ plan is to ditch glibc for musl on the
> host, so we can just statically link and forget about _libc_ problems. what i
> don't know [because historically we've used glibc] is the extent to which 
> these
> kinds of users are relying on glibc trying to work around missing stuff on old
> kernels. aiui glibc pretty much always tries, musl tries in some cases, and
> bionic basically never tries.

I'm pretty sure the "old kernel" workarounds musl doesn't do are mostly things
that predate 3.0. (That's what
https://wiki.musl-libc.org/supported-platforms.html says anyway, I'm not sure
how up to date it is but Rich would know.)

Given that 3.0 came out in 2011 and is thus past even the TEN year support
horizon, I suspect you're good. :)

P.S. I broke down and added
https://landley.net/toybox/downloads/binaries/toolchains/latest/ to the nav bar
on the left in the toybox page. "Downloads->compilers".

I have an LLVM hexagon build, but don't have generic LLVM builds for the other
targets because the libgcc replacement in the LLVM build is a giant steaming
pile of special cases that doesn't want to build in a remotely generic way. I
got it to work for hexagon by picking apart the toolchain build qualcomm added
to the qemu test suite, but couldn't manage to genericize it to the other 
targets...

> so there might be some fallout there still, but i
> have no data yet. given that linux is free, kernel vulnerabilities are rife, 
> and
> most modern hardware supports virtualization, i'm not _super_ sympathetic to
> running old software. i have a lot more sympathy for running old hardware, but
> as someone who's running current ubuntu on an 11 year old laptop ... i'm

Mine's from 2012.

> unconvinced i'm actually _helping_ people by making it easier to stay on
> ridiculously old versions of linux. 7 years is more than enough.)

Musl theoretically supports 3.0, which is as old as your laptop.

> The old "mirror being 7 years bad luck" was from medieval observations 
> about
> people recovering from old traumas, changing behavior, and moving on with 
> their
> lives: that's approximately the time it takes a socializing group of 
> humans to
> collectively stop reacting to a cause that's no longer present. From a 
> technical
> perspective, it means past that point the relevant domain experts are no 
> longer
> immediately available. People can dig up and recreate the old ways if you 
> track
> down an ex-expert willing to put in some time, but most of them won't 
> have the
> answers off the top of their head anymore. They've stopped exercising it,
> nobody's regression testing it, have to dig something out out of a box...
> 
> yeah, testing's hard enough already without saying "any version of any distro
> shipped in the last 10 years"!

I've installed weird things like "PC Linux OS" under kvm to reproduce people's
issues, but it's nice to have SOME constraints...

> I suspect it would work if I said "gnu99" instead of "c99", but that 
> defeats the
> purpose of the exercise. (The gnu guys keep forcing you to #define gnu to 
> get
> wrappers for Linux system calls that the kernel guys introduced, like 
> "man 2
> unshare". It has nothing whatsoever to do with gnu, never did, but the 
> glibc
> guys are political propagandists.)
> 
> (to be fair, gnu11 and gnu++14 are the _gcc_ political propagandists, not 
> glibc
> :-) )

Yes and no:

https://web.archive.org/web/20080213230249/http://sources.redhat.com/ml/libc-announce/2001/msg0.html#:~:text=Stallman

They're a lot less bad about it than they used to be, but historically?

The FSF welcomed Stallman back after his Me-too-ing. They're fundamentally
incapable of moving beyond him.

> and, yeah, today's current gcc and clang both default to "gnu17" for C.

Was there anything in c17 worth knowing about? Looks like typo correction and
they deprected ATOMIC_VAR_INIT.


> Toolchain version upgrades break stuff. This is sadly not avoidable. The 
> 7 year
> 

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

[enh via Toybox]

On Thu, May 12, 2022 at 9:56 AM Rob Landley  wrote:

> On 5/11/22 11:10, enh wrote:
> >> The next version of centos does not exist. Apparently Centos has
> completely gone
> >> away. Right, I can stop caring about it then I guess?
> >
> > (that was my reaction to the recent news, yes. "fine by me", since
> > centos was _always_ the most problematic distro to support, probably
> > because it naturally attracted the kinds of folks who _wanted_ to run
> > stuff from a decade ago.)
>
> I can move from 7 years to 10 if there's specific demand for it,  but 7 was
> based on a lot of experience and a certain amount of research. It's enough
> Moore's Law half lives to get you down to about 2% of the installed base,
> but
> it's ALSO where expertise in the old stuff seems to drop out of living
> memory.
>

(i think i've said before, but _our_ plan is to ditch glibc for musl on the
host, so we can just statically link and forget about _libc_ problems. what
i don't know [because historically we've used glibc] is the extent to which
these kinds of users are relying on glibc trying to work around missing
stuff on old kernels. aiui glibc pretty much always tries, musl tries in
some cases, and bionic basically never tries. so there might be some
fallout there still, but i have no data yet. given that linux is free,
kernel vulnerabilities are rife, and most modern hardware supports
virtualization, i'm not _super_ sympathetic to running old software. i have
a lot more sympathy for running old hardware, but as someone who's running
current ubuntu on an 11 year old laptop ... i'm unconvinced i'm actually
_helping_ people by making it easier to stay on ridiculously old versions
of linux. 7 years is more than enough.)


> The old "mirror being 7 years bad luck" was from medieval observations
> about
> people recovering from old traumas, changing behavior, and moving on with
> their
> lives: that's approximately the time it takes a socializing group of
> humans to
> collectively stop reacting to a cause that's no longer present. From a
> technical
> perspective, it means past that point the relevant domain experts are no
> longer
> immediately available. People can dig up and recreate the old ways if you
> track
> down an ex-expert willing to put in some time, but most of them won't have
> the
> answers off the top of their head anymore. They've stopped exercising it,
> nobody's regression testing it, have to dig something out out of a box...
>

yeah, testing's hard enough already without saying "any version of any
distro shipped in the last 10 years"!


> Yeah yeah, nebulous social community stuff, but that's important too.
> Those last
> 3 years of support in the 10 year time horizon are the most painful for a
> REASON. (Somebody could totally do a thesis/dissertation on this if they
> wanted
> to...)
>
> >> If this does actually break somebody, I can have portability.h do:
> >> #if version < thingy
> >> #define _Noreturn __attribute__((__noreturn__))
> >> #endif
> >>
> >> But I'd rather wait for a complaint?
> >>
> >> (Also, when I try to build older versions with CFLAGS=--std=c99 to see
> where c11
> >> leaked in, even 0.8.0 won't build because of random failures like
> >> CLOCK_MONOTONIC isn't defined? Looks like gcc/glibc is being
> intentionally
> >> obstructive again. I'd rather not micromanage this the same way I
> refuse to
> >> #define gnu to get stuff out of the headers: that way lies madness...)
> >
> > interesting, i don't see that for the android build, but maybe we just
> > don't build that stuff for the host. (bionic's always [well, "since i
> > inherited it"] taken the attitude that you get all the things, all the
> > time.
>
> I suspect it would work if I said "gnu99" instead of "c99", but that
> defeats the
> purpose of the exercise. (The gnu guys keep forcing you to #define gnu to
> get
> wrappers for Linux system calls that the kernel guys introduced, like "man
> 2
> unshare". It has nothing whatsoever to do with gnu, never did, but the
> glibc
> guys are political propagandists.)
>

(to be fair, gnu11 and gnu++14 are the _gcc_ political propagandists, not
glibc :-) )

and, yeah, today's current gcc and clang both default to "gnu17" for C.


> That said, using the musl toolchain --std=c99 sort of builds-ish, and I
> can see
> that typeof() showed up in commit 5a159cceb in 2017, but to test anything
> that
> old I need commit 78289203031a backported (fixing the config2help segfault
> in
> newer toolchains)...
>
> Yes, the last commit that builds with --std=c99 is commit 77f9c7700604 in
> May
> 2017, because commit 5a159cceb introduced use of typeof(), a c11 feature.
>
> That was slightly/technically wrong of me (because 7 year time horizon,
> only
> about 5 and 1/2 years at the time), although the old toolchains I
> regression
> tested against already had typeof() support in their default standards (as
> an
> extension), so it still built on the old versions, even ones that predated
> the
> c11 standard; it 

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

[Rob Landley]

On 5/11/22 11:10, enh wrote:
>> The next version of centos does not exist. Apparently Centos has completely 
>> gone
>> away. Right, I can stop caring about it then I guess?
> 
> (that was my reaction to the recent news, yes. "fine by me", since
> centos was _always_ the most problematic distro to support, probably
> because it naturally attracted the kinds of folks who _wanted_ to run
> stuff from a decade ago.)

I can move from 7 years to 10 if there's specific demand for it,  but 7 was
based on a lot of experience and a certain amount of research. It's enough
Moore's Law half lives to get you down to about 2% of the installed base, but
it's ALSO where expertise in the old stuff seems to drop out of living memory.

The old "mirror being 7 years bad luck" was from medieval observations about
people recovering from old traumas, changing behavior, and moving on with their
lives: that's approximately the time it takes a socializing group of humans to
collectively stop reacting to a cause that's no longer present. From a technical
perspective, it means past that point the relevant domain experts are no longer
immediately available. People can dig up and recreate the old ways if you track
down an ex-expert willing to put in some time, but most of them won't have the
answers off the top of their head anymore. They've stopped exercising it,
nobody's regression testing it, have to dig something out out of a box...

Yeah yeah, nebulous social community stuff, but that's important too. Those last
3 years of support in the 10 year time horizon are the most painful for a
REASON. (Somebody could totally do a thesis/dissertation on this if they wanted
to...)

>> If this does actually break somebody, I can have portability.h do:
>> #if version < thingy
>> #define _Noreturn __attribute__((__noreturn__))
>> #endif
>>
>> But I'd rather wait for a complaint?
>>
>> (Also, when I try to build older versions with CFLAGS=--std=c99 to see where 
>> c11
>> leaked in, even 0.8.0 won't build because of random failures like
>> CLOCK_MONOTONIC isn't defined? Looks like gcc/glibc is being intentionally
>> obstructive again. I'd rather not micromanage this the same way I refuse to
>> #define gnu to get stuff out of the headers: that way lies madness...)
> 
> interesting, i don't see that for the android build, but maybe we just
> don't build that stuff for the host. (bionic's always [well, "since i
> inherited it"] taken the attitude that you get all the things, all the
> time.

I suspect it would work if I said "gnu99" instead of "c99", but that defeats the
purpose of the exercise. (The gnu guys keep forcing you to #define gnu to get
wrappers for Linux system calls that the kernel guys introduced, like "man 2
unshare". It has nothing whatsoever to do with gnu, never did, but the glibc
guys are political propagandists.)

That said, using the musl toolchain --std=c99 sort of builds-ish, and I can see
that typeof() showed up in commit 5a159cceb in 2017, but to test anything that
old I need commit 78289203031a backported (fixing the config2help segfault in
newer toolchains)...

Yes, the last commit that builds with --std=c99 is commit 77f9c7700604 in May
2017, because commit 5a159cceb introduced use of typeof(), a c11 feature.

That was slightly/technically wrong of me (because 7 year time horizon, only
about 5 and 1/2 years at the time), although the old toolchains I regression
tested against already had typeof() support in their default standards (as an
extension), so it still built on the old versions, even ones that predated the
c11 standard; it was a widely available compiler extension (like a ? : b meaning
a ? a : b) before it was standardized.

Anyway, design.html says c11 now. I should probably have about.html mention it
too, but I'm trying to redo the web page so "about.html" is the default landing
page instead of news.html, and move the intro paragraph at the start of
news.html into header.html so it's on all the pages, but about.html has its own
version and moving it into the header completely screws up the flow of the first
section of the about page requiring a largeish rewrite. :P

> there's very little [though admittedly non-zero] value to being
> able to fine-tune your standard version, but that's _far_ too
> confusing for most developers. "it just works" minimizes our support
> burden, and we have an orthogonal "what version of Android do you want
> this to _run_ on?" problem that's more than enough cognitive load for
> everyone.)

This is why I puppy-eyed Rich into adding _ALL_SOURCE to musl. Just give me all
the darn symbols the C library is providing.

>> > given that `_Noreturn` is required to be at the start, i kind of wish
>> > they'd made it imply `void`; `noreturn void` seems a bit redundant!
>>
>> stdnoreturn.h does literally nothing except #define noreturn _Noreturn
> 
> yeah, but like i said yesterday --- that's how you have your "sensible
> keyword [noreturn]" cake and also eat "don't break existing code
> 

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

[Ivo van Poorten]

On Wed, 11 May 2022 09:04:01 -0700 enh via Toybox
 wrote:
> there's plenty of C++ in the GNU stuff these days; that's orthogonal.

Yes. gcc cannot compile itself anymore without g++.

chibicc looks promising.

https://github.com/rui314/chibicc

A book and all.

But so did pcc (haven't heard much about it lately) and tinycc (which
is a mess with its mob branch, and it licensing).

Regards,
Ivo
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

[enh via Toybox]

On Wed, May 11, 2022 at 8:40 AM Rob Landley  wrote:
>
> On 5/10/22 17:08, enh wrote:
> > attached two separate patches; one to move, the other to take
> > advantage of the move.
>
> I'm reluctant to specify --std= because I've never had to before. When I 
> started
> using c99 I didn't have to specify --std=c99, and we've leaked c11 features 
> into
> the thing already and the build didn't break with the compiler defaults. I.E.
> the compiler defaults shifted long before we did, including the oldest 
> versions
> I regression tested against. When did gcc move to c11 by default... Looks like
> it was in 5.1.0, which came out in 2015:
>
> https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Standards.html
>
> Which was 7 years ago. They have since moved on to 2017 which I didn't even 
> know
> was a thing?
>
> #define __STDC_VERSION__ 201710L

yeah, noticing that for both compilers was another "yeah, maybe it's
time to stop artificially holding android's default back"...

> Now in theory sufficiently old versions of centos would have the "centos 
> people
> taking advantage of Red hat's 10 year paid support horizon" thing? Sigh, what 
> is
> the oldest version of that still supported...
>
> https://www.zdnet.com/article/centos-linux-8-is-about-to-die-what-do-you-do-next/
>
> The next version of centos does not exist. Apparently Centos has completely 
> gone
> away. Right, I can stop caring about it then I guess?

(that was my reaction to the recent news, yes. "fine by me", since
centos was _always_ the most problematic distro to support, probably
because it naturally attracted the kinds of folks who _wanted_ to run
stuff from a decade ago.)

> If this does actually break somebody, I can have portability.h do:
> #if version < thingy
> #define _Noreturn __attribute__((__noreturn__))
> #endif
>
> But I'd rather wait for a complaint?
>
> (Also, when I try to build older versions with CFLAGS=--std=c99 to see where 
> c11
> leaked in, even 0.8.0 won't build because of random failures like
> CLOCK_MONOTONIC isn't defined? Looks like gcc/glibc is being intentionally
> obstructive again. I'd rather not micromanage this the same way I refuse to
> #define gnu to get stuff out of the headers: that way lies madness...)

interesting, i don't see that for the android build, but maybe we just
don't build that stuff for the host. (bionic's always [well, "since i
inherited it"] taken the attitude that you get all the things, all the
time. there's very little [though admittedly non-zero] value to being
able to fine-tune your standard version, but that's _far_ too
confusing for most developers. "it just works" minimizes our support
burden, and we have an orthogonal "what version of Android do you want
this to _run_ on?" problem that's more than enough cognitive load for
everyone.)

> > given that `_Noreturn` is required to be at the start, i kind of wish
> > they'd made it imply `void`; `noreturn void` seems a bit redundant!
>
> stdnoreturn.h does literally nothing except #define noreturn _Noreturn

yeah, but like i said yesterday --- that's how you have your "sensible
keyword [noreturn]" cake and also eat "don't break existing code
[no-one's using _Noreturn]". if you look at the git history _for
toybox_ you can see that Apple's *headers* were already using
`noreturn`, and that's why toybox had to have
__attribute__((__noreturn__)) rather than __attribute__((noreturn))
:-)

> That's a sad, pathetic excuse for a header. As silly a _Noreturn is it's no
> sillier than __attribute__(thingy) so I think I'd rather just use the actual
> name directly. I could #define it myself if I wanted to, just as I could 
> #define
> { BEGIN and } END like the pascal guys did long ago. Not going there. Yes 
> it's a
> stupid name, but the wrapper isn't LESS stupid, and doesn't FIX anything.

(and your own #define could always include the obligatory `void` :-) )

> Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

[enh via Toybox]

On Wed, May 11, 2022 at 7:32 AM Rob Landley  wrote:
>
> On 5/10/22 13:00, enh wrote:
> > On Tue, May 10, 2022 at 10:44 AM Rob Landley  wrote:
> >>
> >> On 5/9/22 18:54, enh via Toybox wrote:
> >> > i think this question already came up recently, but mainly as a joke
> >> > before ... "how do you feel about C11?"
> >>
> >> It's comfortably past the 7 year support horizon. I haven't got anything 
> >> against
> >> C11, I just haven't needed anything from it yet?
> >>
> >> Actually, I think that typecast constant array syntax is from C11:
> >>
> >>   s = ((char *[]){"NICE", "SCHED", "ETIME", "PCPU", "VSIZE", "UNAME"})[k];
> >
> > my personal favorite is `struct type var = { .one_thing_i_care_about =
> > 123 };` with everything else guaranteed zeroed.
>
> Yup, I've been depending on that too.
>
> >> So yeah, we may already be depending on it and I should update the 
> >> design.html
> >> page...
> >>
> >> > because i actually have a specific reason to want it now. (buckle in,
> >> > because this is going to annoy you...)
> >> >
> >> > we'd seen large numbers of native crashes show up from toybox, and
> >> > oddly they were from the toybox _tests_. which is weird, because we'd
> >> > have expected the tests to _fail_ in that case, and such a problem not
> >> > to get checked in.
> >> >
> >> > (so, long-term question: should/can we improve the test suite to spot
> >> > exit-via-signal and automatically make that a FAIL?)
> >>
> >> I thought it already did ? runtest.sh line 140:
> >>
> >>   # Catch segfaults
> >>   [ $RETVAL -gt 128 ] && [ $RETVAL -lt 255 ] &&
> >> echo "exited with signal (or returned $RETVAL)" >> actual
> >>
> >> This replaces the output it's comparing with "exited with signal..." which
> >> should never match the real output, and should be printed in the diff.
> >
> > /me checks...
> >
> > ah, yeah, the trouble was it was the common pattern of a test that
> > says `command || ...` or `command && ...` which doesn't have a third
> > case of "but die completely if it was > 128".
>
> Alas, only so much I can do in the plumbing. :(
>
> The fact that || hides segfaults is something to ponder in test design. Shell
> intercepts the failure and discards failure type. Yeah, that's what we asked 
> it
> to do. Hmmm...
>
> Maybe something like having CONFIG_DEBUG replace all the default signal 
> handlers
> with:
>
>   dprintf(2, "HHH"); _exit(128+signal);
>
> Except I would be loathe to ship that, and you enable CONFIG_DEBUG by default,
> and if I made it CONFIG_MORE_DEBUG you'd just enable that.. (Which is GOING to
> cause false positive problems. Remember sigpipe. Nevertheless, it is a thing 
> we
> COULD do to catch this sort of thing. It WILL cause false positive issues 
> though.)

to be clear: we only enable CONFIG_DEBUG because we rely on various
dynamic checkers that can't predict the future and know that the
results of your computation on uninitialized data will be thrown away
later. (was that stack data? if so, it's possible that the default
zero-initialization of all stack data in android has obsoleted
that...)

we don't want "all debugging on all the time", but we do want (a) "to
fix anything that the dynamic tools find" and (b) "to blow up rather
than sweep things under the carpet". since we use dynamic checkers in
production (with the end goal being almost-free hardware enforcement
via stuff like Arm MTE), this isn't really "debug" as far as we're
concerned. CONFIG_CAREFUL might be more like it :-)

if CONFIG_DEBUG really were just for use during the tests, we'd have
no reason to turn that on. we would hit up against "always test the
binary you're going to ship" though.

like i say (and as you can see from the fact we found this), given the
[surprisingly new] "file a bug for all native crashes that happen
during test runs" infrastructure, _android_ should find all of this
stuff going forward anyway. so in the absence of an obvious good fix
for this ... "meh". i did want to point it out unless there _was_ a
good fix i was missing though, and just to explain the background of
this specific issue.

> >> *shrug* I've done uglier things with a similar commit comment. "Here's why 
> >> this
> >> is ugly: it's working around a compiler bug." Ok then.
> >
> > yeah, pretty much. (obviously another alternative is "i revert the
> > change that tickled this locally in T, and we worry about a proper fix
> > for U", but given that this still isn't fixed upstream yet, others
> > might hit it too.)
> >
> > plus i actually like some of the other C11 stuff, so even though this
> > is a _stupid_ forcing function, i'm not unhappy to have _a_ forcing
> > function :-)
> >
> > (if i didn't already say, my reasoning for moving the AOSP default to
> > C11 for U is that i feel like we're at the tipping point now where
> > "even C programmers", not known for their love of the new, are
> > starting to _assume_ C11, and we're having more and more people have
> > to manually opt in/ask why stuff 

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

[Rob Landley]

On 5/10/22 17:08, enh wrote:
> attached two separate patches; one to move, the other to take
> advantage of the move.

I'm reluctant to specify --std= because I've never had to before. When I started
using c99 I didn't have to specify --std=c99, and we've leaked c11 features into
the thing already and the build didn't break with the compiler defaults. I.E.
the compiler defaults shifted long before we did, including the oldest versions
I regression tested against. When did gcc move to c11 by default... Looks like
it was in 5.1.0, which came out in 2015:

https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Standards.html

Which was 7 years ago. They have since moved on to 2017 which I didn't even know
was a thing?

#define __STDC_VERSION__ 201710L

Now in theory sufficiently old versions of centos would have the "centos people
taking advantage of Red hat's 10 year paid support horizon" thing? Sigh, what is
the oldest version of that still supported...

https://www.zdnet.com/article/centos-linux-8-is-about-to-die-what-do-you-do-next/

The next version of centos does not exist. Apparently Centos has completely gone
away. Right, I can stop caring about it then I guess?

If this does actually break somebody, I can have portability.h do:
#if version < thingy
#define _Noreturn __attribute__((__noreturn__))
#endif

But I'd rather wait for a complaint?

(Also, when I try to build older versions with CFLAGS=--std=c99 to see where c11
leaked in, even 0.8.0 won't build because of random failures like
CLOCK_MONOTONIC isn't defined? Looks like gcc/glibc is being intentionally
obstructive again. I'd rather not micromanage this the same way I refuse to
#define gnu to get stuff out of the headers: that way lies madness...)

> given that `_Noreturn` is required to be at the start, i kind of wish
> they'd made it imply `void`; `noreturn void` seems a bit redundant!

stdnoreturn.h does literally nothing except #define noreturn _Noreturn

That's a sad, pathetic excuse for a header. As silly a _Noreturn is it's no
sillier than __attribute__(thingy) so I think I'd rather just use the actual
name directly. I could #define it myself if I wanted to, just as I could #define
{ BEGIN and } END like the pascal guys did long ago. Not going there. Yes it's a
stupid name, but the wrapper isn't LESS stupid, and doesn't FIX anything.

Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

[Rob Landley]

On 5/10/22 13:00, enh wrote:
> On Tue, May 10, 2022 at 10:44 AM Rob Landley  wrote:
>>
>> On 5/9/22 18:54, enh via Toybox wrote:
>> > i think this question already came up recently, but mainly as a joke
>> > before ... "how do you feel about C11?"
>>
>> It's comfortably past the 7 year support horizon. I haven't got anything 
>> against
>> C11, I just haven't needed anything from it yet?
>>
>> Actually, I think that typecast constant array syntax is from C11:
>>
>>   s = ((char *[]){"NICE", "SCHED", "ETIME", "PCPU", "VSIZE", "UNAME"})[k];
> 
> my personal favorite is `struct type var = { .one_thing_i_care_about =
> 123 };` with everything else guaranteed zeroed.

Yup, I've been depending on that too.

>> So yeah, we may already be depending on it and I should update the 
>> design.html
>> page...
>>
>> > because i actually have a specific reason to want it now. (buckle in,
>> > because this is going to annoy you...)
>> >
>> > we'd seen large numbers of native crashes show up from toybox, and
>> > oddly they were from the toybox _tests_. which is weird, because we'd
>> > have expected the tests to _fail_ in that case, and such a problem not
>> > to get checked in.
>> >
>> > (so, long-term question: should/can we improve the test suite to spot
>> > exit-via-signal and automatically make that a FAIL?)
>>
>> I thought it already did ? runtest.sh line 140:
>>
>>   # Catch segfaults
>>   [ $RETVAL -gt 128 ] && [ $RETVAL -lt 255 ] &&
>> echo "exited with signal (or returned $RETVAL)" >> actual
>>
>> This replaces the output it's comparing with "exited with signal..." which
>> should never match the real output, and should be printed in the diff.
> 
> /me checks...
> 
> ah, yeah, the trouble was it was the common pattern of a test that
> says `command || ...` or `command && ...` which doesn't have a third
> case of "but die completely if it was > 128".

Alas, only so much I can do in the plumbing. :(

The fact that || hides segfaults is something to ponder in test design. Shell
intercepts the failure and discards failure type. Yeah, that's what we asked it
to do. Hmmm...

Maybe something like having CONFIG_DEBUG replace all the default signal handlers
with:

  dprintf(2, "HHH"); _exit(128+signal);

Except I would be loathe to ship that, and you enable CONFIG_DEBUG by default,
and if I made it CONFIG_MORE_DEBUG you'd just enable that.. (Which is GOING to
cause false positive problems. Remember sigpipe. Nevertheless, it is a thing we
COULD do to catch this sort of thing. It WILL cause false positive issues 
though.)

>> *shrug* I've done uglier things with a similar commit comment. "Here's why 
>> this
>> is ugly: it's working around a compiler bug." Ok then.
> 
> yeah, pretty much. (obviously another alternative is "i revert the
> change that tickled this locally in T, and we worry about a proper fix
> for U", but given that this still isn't fixed upstream yet, others
> might hit it too.)
> 
> plus i actually like some of the other C11 stuff, so even though this
> is a _stupid_ forcing function, i'm not unhappy to have _a_ forcing
> function :-)
> 
> (if i didn't already say, my reasoning for moving the AOSP default to
> C11 for U is that i feel like we're at the tipping point now where
> "even C programmers", not known for their love of the new, are
> starting to _assume_ C11, and we're having more and more people have
> to manually opt in/ask why stuff doesn't "just work". linux moving
> will probably be quite a heavy thumb on that side of the scale. and in
> the C committee's defense [in contrast to the C++ committee], they're
> pretty good about not breaking stuff. literally the only problems i've
> seen have been from people who had untested and incorrect code in #ifs
> that checked for C11...)

C11 has leaked in over t he past 2-3 years. Time to update the docs and
acknowledge it...

> but, yeah, this kind of "codegen bug specific to one architecture" was
> the kind of GCC nonsense i thought LLVM's cleaner design was supposed
> to save us from :-(

It's written in C++ and you consider it cleaner?

> (to be fair, i _do_ see a lot less of this with LLVM than i used to with GCC.)

I expect that's more "lack of FSF" than anything else. And scaling 50% more buys
you one iteration of Gates' Law if you're lucky. Code complexity expands to fit
available management capability if you let it.

(David Graeber liked to explain how most work is maintenance by saying you make
a cup once but wash it a thousand times. I spend most of my effort performing
code topiary trying to make a bonsai command line by constantly PRUNING this
crap. I wanted somebody to do a proper version of Fabrice Bellad's tinycc for
similar reasons: so we have a comprehensible reference implementation everyone
can understand and regression test against. Alas, that concept only ever worked
for C, not for C++. C is not a moving target, and the whole language can be
explained in an hour.)

>> Rob

Still Rob

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

[enh via Toybox]

oh, and if you want to see the miscompile "in action", here's a
godbolt link showing that [[noreturn]] and _Noreturn work in their
respective languages, but __attribute__((__noreturn__)) is broken in C
(but not C++!): https://godbolt.org/z/T6nMoa75G

On Tue, May 10, 2022 at 3:08 PM enh  wrote:
>
> attached two separate patches; one to move, the other to take
> advantage of the move.
>
> given that `_Noreturn` is required to be at the start, i kind of wish
> they'd made it imply `void`; `noreturn void` seems a bit redundant!
>
> On Tue, May 10, 2022 at 11:00 AM enh  wrote:
> >
> > On Tue, May 10, 2022 at 10:44 AM Rob Landley  wrote:
> > >
> > > On 5/9/22 18:54, enh via Toybox wrote:
> > > > i think this question already came up recently, but mainly as a joke
> > > > before ... "how do you feel about C11?"
> > >
> > > It's comfortably past the 7 year support horizon. I haven't got anything 
> > > against
> > > C11, I just haven't needed anything from it yet?
> > >
> > > Actually, I think that typecast constant array syntax is from C11:
> > >
> > >   s = ((char *[]){"NICE", "SCHED", "ETIME", "PCPU", "VSIZE", "UNAME"})[k];
> >
> > my personal favorite is `struct type var = { .one_thing_i_care_about =
> > 123 };` with everything else guaranteed zeroed.
> >
> > > So yeah, we may already be depending on it and I should update the 
> > > design.html
> > > page...
> > >
> > > > because i actually have a specific reason to want it now. (buckle in,
> > > > because this is going to annoy you...)
> > > >
> > > > we'd seen large numbers of native crashes show up from toybox, and
> > > > oddly they were from the toybox _tests_. which is weird, because we'd
> > > > have expected the tests to _fail_ in that case, and such a problem not
> > > > to get checked in.
> > > >
> > > > (so, long-term question: should/can we improve the test suite to spot
> > > > exit-via-signal and automatically make that a FAIL?)
> > >
> > > I thought it already did ? runtest.sh line 140:
> > >
> > >   # Catch segfaults
> > >   [ $RETVAL -gt 128 ] && [ $RETVAL -lt 255 ] &&
> > > echo "exited with signal (or returned $RETVAL)" >> actual
> > >
> > > This replaces the output it's comparing with "exited with signal..." which
> > > should never match the real output, and should be printed in the diff.
> >
> > /me checks...
> >
> > ah, yeah, the trouble was it was the common pattern of a test that
> > says `command || ...` or `command && ...` which doesn't have a third
> > case of "but die completely if it was > 128".
> >
> > > > but short term, what's going on here? turns out i could reduce the
> > > > specific failing test quite significantly:
> > > >
> > > > vsoc_x86_64:/ # gzip /proc/version
> > > > gzip: /proc/version.gz: No such file or directory
> > > > Segmentation fault
> > > > 139|vsoc_x86_64:/ # ^D
> > > >
> > > > and the test passes because we manage to get that error message out
> > > > before we die :-)
> > >
> > > Uncaught signals should return 128+signum, and we test for that range and 
> > > stomp
> > > the generated output with an error message...?
> > >
> > > > why do we die? tl;dr: because clang drops the rest of the function
> > > > after the conditional "call a noreturn or a non-noreturn function"
> > > > line in xcreate_stdio:
> > > >
> > > >   if (fd == -1) ((flags_ONLY) ? perror_msg_raw : 
> > > > perror_exit_raw)(path);
> > > >
> > > > this all works fine on arm, btw; only x86-64 (tbh, i don't remember
> > > > whether i tested x86) is affected.
> > >
> > > Do you mean "drops" as in "optimizes out"? Except we only do it if (fd == 
> > > -1)...?
> >
> > yeah, all the rest of the function disappears.
> >
> > > I'm not following what's going on here.
> >
> > i don't think you should expect to ... it's a compiler bug :-)
> >
> > > > but what does any of this have to do with C11?
> > > >
> > > > well, oddly (and, yeah, we'll chase the miscompile as a bug anyway)
> > > > the best workaround i've seen (thanks here to +jamesfarrell for
> > > > finding someone to have a proper look at llvm) is to replace the
> > > > current `__attribute__((__noreturn__)`s with C11 `_Noreturn`. yeah,
> > > > you'd assume they would boil down to the same thing, but ... nope.
> > >
> > > I would very much assume it boils down to the same thing, yes?
> >
> > apparently the representation is different enough that only the
> > attribute has trouble. (and i've confirmed that via godbolt.)
> >
> > > > given that Android T is stuck with that clang (and this bug hasn't
> > > > actually been fixed upstream yet), i think our two T workaround
> > > > options are:
> > > >
> > > > 1. revert the change
> > > > [https://github.com/landley/toybox/commit/20376512ae99be103875a1605ad69a7c876b818a]
> > > > that added the attribute to the _raw() functions.
> > >
> > > Yet another reason why compilers generating unnecessary warnings makes me 
> > > sad.
> > >
> > > > 2. use _Noreturn instead, either
> > > > a) by assuming C11 because it's 2022 and even Linux is on board, 

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

[enh via Toybox]

attached two separate patches; one to move, the other to take
advantage of the move.

given that `_Noreturn` is required to be at the start, i kind of wish
they'd made it imply `void`; `noreturn void` seems a bit redundant!

On Tue, May 10, 2022 at 11:00 AM enh  wrote:
>
> On Tue, May 10, 2022 at 10:44 AM Rob Landley  wrote:
> >
> > On 5/9/22 18:54, enh via Toybox wrote:
> > > i think this question already came up recently, but mainly as a joke
> > > before ... "how do you feel about C11?"
> >
> > It's comfortably past the 7 year support horizon. I haven't got anything 
> > against
> > C11, I just haven't needed anything from it yet?
> >
> > Actually, I think that typecast constant array syntax is from C11:
> >
> >   s = ((char *[]){"NICE", "SCHED", "ETIME", "PCPU", "VSIZE", "UNAME"})[k];
>
> my personal favorite is `struct type var = { .one_thing_i_care_about =
> 123 };` with everything else guaranteed zeroed.
>
> > So yeah, we may already be depending on it and I should update the 
> > design.html
> > page...
> >
> > > because i actually have a specific reason to want it now. (buckle in,
> > > because this is going to annoy you...)
> > >
> > > we'd seen large numbers of native crashes show up from toybox, and
> > > oddly they were from the toybox _tests_. which is weird, because we'd
> > > have expected the tests to _fail_ in that case, and such a problem not
> > > to get checked in.
> > >
> > > (so, long-term question: should/can we improve the test suite to spot
> > > exit-via-signal and automatically make that a FAIL?)
> >
> > I thought it already did ? runtest.sh line 140:
> >
> >   # Catch segfaults
> >   [ $RETVAL -gt 128 ] && [ $RETVAL -lt 255 ] &&
> > echo "exited with signal (or returned $RETVAL)" >> actual
> >
> > This replaces the output it's comparing with "exited with signal..." which
> > should never match the real output, and should be printed in the diff.
>
> /me checks...
>
> ah, yeah, the trouble was it was the common pattern of a test that
> says `command || ...` or `command && ...` which doesn't have a third
> case of "but die completely if it was > 128".
>
> > > but short term, what's going on here? turns out i could reduce the
> > > specific failing test quite significantly:
> > >
> > > vsoc_x86_64:/ # gzip /proc/version
> > > gzip: /proc/version.gz: No such file or directory
> > > Segmentation fault
> > > 139|vsoc_x86_64:/ # ^D
> > >
> > > and the test passes because we manage to get that error message out
> > > before we die :-)
> >
> > Uncaught signals should return 128+signum, and we test for that range and 
> > stomp
> > the generated output with an error message...?
> >
> > > why do we die? tl;dr: because clang drops the rest of the function
> > > after the conditional "call a noreturn or a non-noreturn function"
> > > line in xcreate_stdio:
> > >
> > >   if (fd == -1) ((flags_ONLY) ? perror_msg_raw : 
> > > perror_exit_raw)(path);
> > >
> > > this all works fine on arm, btw; only x86-64 (tbh, i don't remember
> > > whether i tested x86) is affected.
> >
> > Do you mean "drops" as in "optimizes out"? Except we only do it if (fd == 
> > -1)...?
>
> yeah, all the rest of the function disappears.
>
> > I'm not following what's going on here.
>
> i don't think you should expect to ... it's a compiler bug :-)
>
> > > but what does any of this have to do with C11?
> > >
> > > well, oddly (and, yeah, we'll chase the miscompile as a bug anyway)
> > > the best workaround i've seen (thanks here to +jamesfarrell for
> > > finding someone to have a proper look at llvm) is to replace the
> > > current `__attribute__((__noreturn__)`s with C11 `_Noreturn`. yeah,
> > > you'd assume they would boil down to the same thing, but ... nope.
> >
> > I would very much assume it boils down to the same thing, yes?
>
> apparently the representation is different enough that only the
> attribute has trouble. (and i've confirmed that via godbolt.)
>
> > > given that Android T is stuck with that clang (and this bug hasn't
> > > actually been fixed upstream yet), i think our two T workaround
> > > options are:
> > >
> > > 1. revert the change
> > > [https://github.com/landley/toybox/commit/20376512ae99be103875a1605ad69a7c876b818a]
> > > that added the attribute to the _raw() functions.
> >
> > Yet another reason why compilers generating unnecessary warnings makes me 
> > sad.
> >
> > > 2. use _Noreturn instead, either
> > > a) by assuming C11 because it's 2022 and even Linux is on board, or
> > > b) in a #if that checks the C standard in use (and change the toybox
> > > Android.bp to opt in to C11, since
> > > https://android-review.googlesource.com/c/platform/build/soong/+/2043314
> > > isn't going in until Android U)
> >
> > Eh, moving to the 2011 standard 11 years later isn't a heavy lift. I remain
> > deeply sad that the committee keeps doing stupid underscore things with
> > namespaces rather than just biting the bullet and adding actual names to the
> > language. (I get to choose when I upgrade to 

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

[enh via Toybox]

On Tue, May 10, 2022 at 10:44 AM Rob Landley  wrote:
>
> On 5/9/22 18:54, enh via Toybox wrote:
> > i think this question already came up recently, but mainly as a joke
> > before ... "how do you feel about C11?"
>
> It's comfortably past the 7 year support horizon. I haven't got anything 
> against
> C11, I just haven't needed anything from it yet?
>
> Actually, I think that typecast constant array syntax is from C11:
>
>   s = ((char *[]){"NICE", "SCHED", "ETIME", "PCPU", "VSIZE", "UNAME"})[k];

my personal favorite is `struct type var = { .one_thing_i_care_about =
123 };` with everything else guaranteed zeroed.

> So yeah, we may already be depending on it and I should update the design.html
> page...
>
> > because i actually have a specific reason to want it now. (buckle in,
> > because this is going to annoy you...)
> >
> > we'd seen large numbers of native crashes show up from toybox, and
> > oddly they were from the toybox _tests_. which is weird, because we'd
> > have expected the tests to _fail_ in that case, and such a problem not
> > to get checked in.
> >
> > (so, long-term question: should/can we improve the test suite to spot
> > exit-via-signal and automatically make that a FAIL?)
>
> I thought it already did ? runtest.sh line 140:
>
>   # Catch segfaults
>   [ $RETVAL -gt 128 ] && [ $RETVAL -lt 255 ] &&
> echo "exited with signal (or returned $RETVAL)" >> actual
>
> This replaces the output it's comparing with "exited with signal..." which
> should never match the real output, and should be printed in the diff.

/me checks...

ah, yeah, the trouble was it was the common pattern of a test that
says `command || ...` or `command && ...` which doesn't have a third
case of "but die completely if it was > 128".

> > but short term, what's going on here? turns out i could reduce the
> > specific failing test quite significantly:
> >
> > vsoc_x86_64:/ # gzip /proc/version
> > gzip: /proc/version.gz: No such file or directory
> > Segmentation fault
> > 139|vsoc_x86_64:/ # ^D
> >
> > and the test passes because we manage to get that error message out
> > before we die :-)
>
> Uncaught signals should return 128+signum, and we test for that range and 
> stomp
> the generated output with an error message...?
>
> > why do we die? tl;dr: because clang drops the rest of the function
> > after the conditional "call a noreturn or a non-noreturn function"
> > line in xcreate_stdio:
> >
> >   if (fd == -1) ((flags_ONLY) ? perror_msg_raw : 
> > perror_exit_raw)(path);
> >
> > this all works fine on arm, btw; only x86-64 (tbh, i don't remember
> > whether i tested x86) is affected.
>
> Do you mean "drops" as in "optimizes out"? Except we only do it if (fd == 
> -1)...?

yeah, all the rest of the function disappears.

> I'm not following what's going on here.

i don't think you should expect to ... it's a compiler bug :-)

> > but what does any of this have to do with C11?
> >
> > well, oddly (and, yeah, we'll chase the miscompile as a bug anyway)
> > the best workaround i've seen (thanks here to +jamesfarrell for
> > finding someone to have a proper look at llvm) is to replace the
> > current `__attribute__((__noreturn__)`s with C11 `_Noreturn`. yeah,
> > you'd assume they would boil down to the same thing, but ... nope.
>
> I would very much assume it boils down to the same thing, yes?

apparently the representation is different enough that only the
attribute has trouble. (and i've confirmed that via godbolt.)

> > given that Android T is stuck with that clang (and this bug hasn't
> > actually been fixed upstream yet), i think our two T workaround
> > options are:
> >
> > 1. revert the change
> > [https://github.com/landley/toybox/commit/20376512ae99be103875a1605ad69a7c876b818a]
> > that added the attribute to the _raw() functions.
>
> Yet another reason why compilers generating unnecessary warnings makes me sad.
>
> > 2. use _Noreturn instead, either
> > a) by assuming C11 because it's 2022 and even Linux is on board, or
> > b) in a #if that checks the C standard in use (and change the toybox
> > Android.bp to opt in to C11, since
> > https://android-review.googlesource.com/c/platform/build/soong/+/2043314
> > isn't going in until Android U)
>
> Eh, moving to the 2011 standard 11 years later isn't a heavy lift. I remain
> deeply sad that the committee keeps doing stupid underscore things with
> namespaces rather than just biting the bullet and adding actual names to the
> language. (I get to choose when I upgrade to the new version, and I have to
> shuffle around strlcpy() already unless you think "don't include string.h" is 
> a
> reasonable thing for C code to avoid doing to avoid "polluting" the 
> namespace...)

well, note that (as usual) they've done _both_ to try to keep everyone happy.

#include  if you want `noreturn` rather than `_Noreturn`.

> > happy to send any/all of the above patches, but wanted to know which
> > option you dislike least...
>
> So we're working around a clang compiler bug by 

Re: [Toybox] __attribute__((__noreturn__)) vs _Noreturn

[Rob Landley]

On 5/9/22 18:54, enh via Toybox wrote:
> i think this question already came up recently, but mainly as a joke
> before ... "how do you feel about C11?"

It's comfortably past the 7 year support horizon. I haven't got anything against
C11, I just haven't needed anything from it yet?

Actually, I think that typecast constant array syntax is from C11:

  s = ((char *[]){"NICE", "SCHED", "ETIME", "PCPU", "VSIZE", "UNAME"})[k];

So yeah, we may already be depending on it and I should update the design.html
page...

> because i actually have a specific reason to want it now. (buckle in,
> because this is going to annoy you...)
> 
> we'd seen large numbers of native crashes show up from toybox, and
> oddly they were from the toybox _tests_. which is weird, because we'd
> have expected the tests to _fail_ in that case, and such a problem not
> to get checked in.
> 
> (so, long-term question: should/can we improve the test suite to spot
> exit-via-signal and automatically make that a FAIL?)

I thought it already did ? runtest.sh line 140:

  # Catch segfaults
  [ $RETVAL -gt 128 ] && [ $RETVAL -lt 255 ] &&
echo "exited with signal (or returned $RETVAL)" >> actual

This replaces the output it's comparing with "exited with signal..." which
should never match the real output, and should be printed in the diff.

> but short term, what's going on here? turns out i could reduce the
> specific failing test quite significantly:
> 
> vsoc_x86_64:/ # gzip /proc/version
> gzip: /proc/version.gz: No such file or directory
> Segmentation fault
> 139|vsoc_x86_64:/ # ^D
> 
> and the test passes because we manage to get that error message out
> before we die :-)

Uncaught signals should return 128+signum, and we test for that range and stomp
the generated output with an error message...?

> why do we die? tl;dr: because clang drops the rest of the function
> after the conditional "call a noreturn or a non-noreturn function"
> line in xcreate_stdio:
> 
>   if (fd == -1) ((flags_ONLY) ? perror_msg_raw : perror_exit_raw)(path);
> 
> this all works fine on arm, btw; only x86-64 (tbh, i don't remember
> whether i tested x86) is affected.

Do you mean "drops" as in "optimizes out"? Except we only do it if (fd == 
-1)...?

I'm not following what's going on here.

> but what does any of this have to do with C11?
> 
> well, oddly (and, yeah, we'll chase the miscompile as a bug anyway)
> the best workaround i've seen (thanks here to +jamesfarrell for
> finding someone to have a proper look at llvm) is to replace the
> current `__attribute__((__noreturn__)`s with C11 `_Noreturn`. yeah,
> you'd assume they would boil down to the same thing, but ... nope.

I would very much assume it boils down to the same thing, yes?

> given that Android T is stuck with that clang (and this bug hasn't
> actually been fixed upstream yet), i think our two T workaround
> options are:
> 
> 1. revert the change
> [https://github.com/landley/toybox/commit/20376512ae99be103875a1605ad69a7c876b818a]
> that added the attribute to the _raw() functions.

Yet another reason why compilers generating unnecessary warnings makes me sad.

> 2. use _Noreturn instead, either
> a) by assuming C11 because it's 2022 and even Linux is on board, or
> b) in a #if that checks the C standard in use (and change the toybox
> Android.bp to opt in to C11, since
> https://android-review.googlesource.com/c/platform/build/soong/+/2043314
> isn't going in until Android U)

Eh, moving to the 2011 standard 11 years later isn't a heavy lift. I remain
deeply sad that the committee keeps doing stupid underscore things with
namespaces rather than just biting the bullet and adding actual names to the
language. (I get to choose when I upgrade to the new version, and I have to
shuffle around strlcpy() already unless you think "don't include string.h" is a
reasonable thing for C code to avoid doing to avoid "polluting" the 
namespace...)

> happy to send any/all of the above patches, but wanted to know which
> option you dislike least...

So we're working around a clang compiler bug by using a C11 name for an
__attribute__(blah) because the compiler miscompiles one and doesn't miscompile
the other (even though they SHOULD be synonyms)?

*shrug* I've done uglier things with a similar commit comment. "Here's why this
is ugly: it's working around a compiler bug." Ok then.

Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net