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)
|
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?