Escape via unhygienic macros Phil Hofer (03 Jul 2019 23:31 UTC)
Re: Escape via unhygienic macros John Cowan (04 Jul 2019 03:59 UTC)
Re: Escape via unhygienic macros Marc Nieper-Wißkirchen (04 Jul 2019 05:57 UTC)
Re: Escape via unhygienic macros John Cowan (04 Jul 2019 17:03 UTC)
Re: Escape via unhygienic macros Phil Hofer (04 Jul 2019 19:02 UTC)
Re: Escape via unhygienic macros John Cowan (04 Jul 2019 18:55 UTC)
(missing)
Fwd: Escape via unhygienic macros Marc Nieper-Wißkirchen (08 Jul 2019 12:21 UTC)
Re: Escape via unhygienic macros Marc Nieper-Wißkirchen (08 Jul 2019 12:38 UTC)
Re: Escape via unhygienic macros John Cowan (08 Jul 2019 16:28 UTC)
Re: Escape via unhygienic macros Lassi Kortela (04 Jul 2019 19:45 UTC)
Re: Escape via unhygienic macros Lassi Kortela (04 Jul 2019 19:56 UTC)
Re: Escape via unhygienic macros John Cowan (08 Jul 2019 04:57 UTC)
Re: Escape via unhygienic macros Marc Nieper-Wißkirchen (04 Jul 2019 20:27 UTC)
Re: Escape via unhygienic macros Lassi Kortela (14 Jul 2019 15:41 UTC)
Re: Escape via unhygienic macros John Cowan (14 Jul 2019 17:59 UTC)

Re: Escape via unhygienic macros Lassi Kortela 04 Jul 2019 19:56 UTC

Another type of security solution is "if people want to do something
stupid, offer a ready-made alternative that is less stupid than the one
they would make themselves". Functions like strlcpy() and strlcat() fall
into this category. I'm thinking of Marc's comments (which are good) and
can't decide whether this SRFI is that type of solution. In principle,
it's indeed better to have a bespoke little language that can only
generate safe programs, but how many people have the skills to craft a
language that is more airtight than the language this SRFI would provide?