On 11/14/13 16:46, Paul Eggert wrote:
Yes, that sounds right. If user code employs SCM_NORETURN in that position and you therefore you can't change SCM_NORETURN to mean _Noreturn, it might be simpler to keep SCM_NORETURN the way it is for backwards compatibility. But you can change all its uses in Guile to be _Noreturn at the start of the declaration, where _Noreturn is defined the Gnulib way.
Actually, internally to Guile I do not care in the slightest what gets used. The problem I face is that the Guile headers were written with the presumption that the token "noreturn" is not #defined to something else. I seriously doubt there are a lot of developers out there writing Guile call out functions with the SCM_NORETURN attribute, so fretting a lot about it is unlikely to be especially useful. What is crucial is fixing the headers so they do not break. That's been done. I do think it is also important to know that stable distributions do not jump on the next major release until it has proven to be stable. And, yes, often times current releases of other tools get built for "stable" platforms. That means my current stuff needs to build against the 1.8.x releases of Guile. In fact, it gets built against 1.6.x releases of Guile. That's why I have hundreds of lines of Guile compatibility cruft -- just to cope with changes. Attached is a shell script that I think I can distribute and forget about. My hope is that I can distribute the thing for the next decade while the "__attribute__ ((__noreturn__))" variation propagates everywhere. It gets invoked from the Makefile.am thus: diff --git a/autoopts/Makefile.am b/autoopts/Makefile.am index 3f2f3ad..137ec51 100644 --- a/autoopts/Makefile.am +++ b/autoopts/Makefile.am @@ -164,4 +164,10 @@ install-data-hook: .NOTPARALLEL: +if GL_GENERATE_STDNORETURN_H +$(STDNORETURN_H) : libguile/__scm.h +libguile/__scm.h : + $(SHELL) $(srcdir)/fix-guile.sh $(LIBGUILE_CFLAGS) +endif +
fix-guile.sh
Description: application/shellscript
