Re: There is no returning

Re: There is no returning

[Bruce Korb]

On 11/10/13 00:13, Harlan Stenn wrote:
> Bruce,
>
> I'm seeing build errors on psp-fb1 with the guile headers as well, and autogen-5.18.2.

Errors like this:

> /usr/bin/gcc-4.6 -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I.. -I../autoopts \
>   -g -O2 -MT autogen-ag.o -MD -MP -MF .deps/autogen-ag.Tpo -c -o autogen-ag.o \
>`test -f 'ag.c' || echo './'`ag.c
> In file included from /usr/include/libguile.h:40:0,
>                  from autogen.h:60,
>                  from ag.c:7:
> /usr/include/libguile/error.h:39:24: error: expected ')' before '__attribute__'
> /usr/include/libguile/error.h:39:24: error: expected ',' or ';' before ')' token

The cause seems to be a bad interaction between gnulib's stdnoreturn module
and the Guile headers.  I'm chasing that now.

> # 28 "/usr/include/libguile/error.h" 3 4
> extern SCM scm_system_error_key;
> extern SCM scm_num_overflow_key;
> extern SCM scm_out_of_range_key;
> extern SCM scm_args_number_key;
> extern SCM scm_arg_type_key;
> extern SCM scm_memory_alloc_key;
> extern SCM scm_misc_error_key;
>
>
>
> extern void scm_error (SCM key, const char *subr, const char *message,
>    SCM args, SCM rest) __attribute__ ((__attribute__ ((__noreturn__))));

from the generated stdnoreturn.h:

> /* The definition of _Noreturn is copied here.  */
> #if !defined _Noreturn && __STDC_VERSION__ < 201112
> # if (3 <= __GNUC__ || (__GNUC__ == 2 && 8 <= __GNUC_MINOR__) \
>       || 0x5110 <= __SUNPRO_C)
> #  define _Noreturn __attribute__ ((__noreturn__))
> # elif 1200 <= _MSC_VER
> #  define _Noreturn __declspec (noreturn)
> # else
> #  define _Noreturn
> # endif
> #endif
[...]
> # define noreturn _Noreturn

And looking into Guile sources:

> $ find /usr/include/libguile -type f|xargs grep -Ei '^#define.*noreturn'
> /usr/include/libguile/__scm.h:#define SCM_NORETURN __attribute__ ((noreturn))

So "noreturn" gets #define-d to:  __attribute__ ((__noreturn__))
and SCM_NORETURN is:  __attribute__ ((noreturn))

Too clever by way more than half.  The correct fix is not obvious to me.
It seems like the correct attribute spelling is:  __attribute__ ((__noreturn__))
but the Guile code spells it in a way whereby gnulib "fixes" the thing.

No way out.

Re: There is no returning

[Paul Eggert]

A better solution, if you want to be portable to
MSVC, is to use _Noreturn instead of noreturn.
This is for reasons described in stdnoreturn.in.h.

'_Noreturn' is a bit ugly; if you don't care about
MSVC, then __attribute__((__noreturn__)) is
a good way to go.

Re: There is no returning

[Bruce Korb]

On 11/10/13 12:41, Paul Eggert wrote:
> A better solution, if you want to be portable to
> MSVC, is to use _Noreturn instead of noreturn.
> This is for reasons described in stdnoreturn.in.h.
>
> '_Noreturn' is a bit ugly; if you don't care about
> MSVC, then __attribute__((__noreturn__)) is
> a good way to go.

Hi Paul,

Thanks.  As mentioned in the GCC pages, using the prefix/suffix
of "__" is the right way to go -- for Guile.  For me, I control
neither the gnulib variation on stdnoreturn.h nor the libguile/__scm.h
headers.  So rather than unwinding "noreturn" attributes for
functions that do not return, I'll hack up some really ugly stuff:

This:

> if GL_GENERATE_STDNORETURN_H
> $(STDNORETURN_H) : libguile/__scm.h
> libguile/__scm.h :
> 	$(SHELL) $(srcdir)/fix-guile.sh $(LIBGUILE_CFLAGS)
> endif

Plus this:

> guile_scm_h=
>
> while test $# -gt 0
> do
>     case "$1" in
>     -I )
>         test -f $2/libguile/__scm.h && {
>             guile_scm_h=$2/libguile/__scm.h
>             break
>         }
>         ;;
>     -I* )
>         f=${1#-I}
>         test -f $f/libguile/__scm.h && {
>             guile_scm_h=$f/libguile/__scm.h
>             break
>         }
>         ;;
>     esac
>     shift
> done
>
> test -z "$guile_scm_h" && {
>     guile_scm_h=/usr/include/libguile/__scm.h
>     test -f $guile_scm_h || {
>         echo "The Guile header __scm.h cannot be found"
>         exit 1
>     } 1>&2
> }
>
> test -d libguile || mkdir libguile || {
>     echo "cannot make libguile directory"
>     exit 1
> } 1>&2
>
> sed $'/^#define[ \t]SCM_NORETURN/s/RETURN..*/RETURN _Noreturn/' \
>     $guile_scm_h > libguile/__scm.h

Re: There is no returning

[Bruce Korb]

On 11/10/13 12:25, Bruce Korb wrote:
> headers.  So rather than unwinding "noreturn" attributes for
> functions that do not return, I'll hack up some really ugly stuff:

That almost works -- I have to make my own copy of libguile.h, too,
to trick the compiler into seeing my __scm.h before Guile's.

Harlan, Andreas, without fixes from Guile, I do not see any way
out except to create my own copies of libguile.h and __scm.h,
fixing the latter.  The latest "pre" will do this.  Please
see if it works for you.

Thanks! Regards, Bruce

http://autogen.sourceforge.net/data/autogen-5.18.3pre4.tar.xz

Re: There is no returning

[Harlan Stenn]

Bruce,

Thanks a bunch!

First, I don't understand what's going on with libguile.h and __scm.h,
but it seems really strange/wrong to me that the ones that get installed
need *any* tweaking to work.

Second, I tried the latest autogen 'pre' and it built and 'make check'
went fine on freebsd and debian, and it built fine under Solaris but we
had two "check" failures - I'll send those to you later.

H

Re: There is no returning

[Andreas Metzler]

On 2013-11-11 Harlan Stenn <stenn@ntp.org> wrote:
[...]
> Second, I tried the latest autogen 'pre' and it built and 'make check'
> went fine on freebsd and debian, and it built fine under Solaris but we
> had two "check" failures - I'll send those to you later.

Hello,
Which compiler did you use for building? You'll only see the problem if
the system provides no stdnoreturn.h. Therefore you' won't see the
problem with gcc >= 4.7.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: There is no returning

[Harlan Stenn]

Hi Andreas,

Andreas Metzler writes:
> On 2013-11-11 Harlan Stenn <stenn@ntp.org> wrote:
> [...]
> > Second, I tried the latest autogen 'pre' and it built and 'make check'
> > went fine on freebsd and debian, and it built fine under Solaris but we
> > had two "check" failures - I'll send those to you later.
> 
> Hello,
> Which compiler did you use for building? You'll only see the problem if
> the system provides no stdnoreturn.h. Therefore you' won't see the
> problem with gcc >= 4.7.

On one solaris box, gcc-4.2.0.  On another solaris box, gcc-4.3.3.

On the debian box, gcc-4.7.2.  On the FreeBSD box, gcc-3.4.6.

All boxes had compile problems in the same area before Bruce's fix.

H

Re: There is no returning

[Andreas Metzler]

On 2013-11-10 Bruce Korb <bkorb@gnu.org> wrote:
[...]
> Harlan, Andreas, without fixes from Guile, I do not see any way
> out except to create my own copies of libguile.h and __scm.h,
> fixing the latter.  The latest "pre" will do this.  Please
> see if it works for you.

> Thanks! Regards, Bruce

Hello,
I quick check on my local system seems to have worked. I have uploaed
to Debian/experimental to get some more exposure.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: There is no returning

[Mark H Weaver]

Bruce Korb <bkorb@gnu.org> writes:

> On 11/10/13 12:41, Paul Eggert wrote:
>> A better solution, if you want to be portable to
>> MSVC, is to use _Noreturn instead of noreturn.
>> This is for reasons described in stdnoreturn.in.h.
>>
>> '_Noreturn' is a bit ugly; if you don't care about
>> MSVC, then __attribute__((__noreturn__)) is
>> a good way to go.
>
> Hi Paul,
>
> Thanks.  As mentioned in the GCC pages, using the prefix/suffix
> of "__" is the right way to go -- for Guile.

FYI, I recently made precisely that change to the stable-2.0 branch,
which will become Guile 2.0.10:

http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=36c40440078c005cd5e239cca487d29f6f60007d;hp=b1fe20c24ccb380420ea1ffdc7f249224072dcdc

    Regards,
      Mark

Re: There is no returning

[Bruce Korb]

On 11/13/13 23:52, Mark H Weaver wrote:
>>> '_Noreturn' is a bit ugly; if you don't care about
>>> MSVC, then __attribute__((__noreturn__)) is
>>> a good way to go.
>>
>> Hi Paul,
>>
>> Thanks.  As mentioned in the GCC pages, using the prefix/suffix
>> of "__" is the right way to go -- for Guile.
>
> FYI, I recently made precisely that change to the stable-2.0 branch,
> which will become Guile 2.0.10:
>
> http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=36c40440078c005cd5e239cca487d29f6f60007d;hp=b1fe20c24ccb380420ea1ffdc7f249224072dcdc

Thank you, Mark!  Would you be willing to also do it for 1.8.x?
Many "stable" distros will take _years_ to advance to 2.x, but
for me I guess does not matter.  I have to copy and edit Guile
headers in order to build at all.

My technique is to blindly replace anything after "SCM_NORETURN"
with "_Noreturn" on any line #define-ing SCM_NORETURN.
This is _always_ done when GL_GENERATE_STDNORETURN_H is defined
at "configure" time.  That means I will be doing this in perpetuity,
unless I can get clear instructions about how to detect
that it is no longer necessary.

I think a better patch would be for Guile to defer to _Noreturn
whenever that is #define-d and _otherwise_ do what you do.
That way, if gnulib is in the mix, it is a gnulib job to
figure out the right value for SCM_NORETURN/_Noreturn.
The token "_Noreturn" is in the reserved-for-the-implementation
name space, so conforming applications should not be defining that
on their own.

Regards, Bruce

Re: There is no returning

[Mark H Weaver]

Bruce Korb <bkorb@gnu.org> writes:

> On 11/13/13 23:52, Mark H Weaver wrote:
>> FYI, I recently made precisely that change to the stable-2.0 branch,
>> which will become Guile 2.0.10:
>>
>> http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=36c40440078c005cd5e239cca487d29f6f60007d;hp=b1fe20c24ccb380420ea1ffdc7f249224072dcdc
>
> Thank you, Mark!  Would you be willing to also do it for 1.8.x?

I'm sorry, but 1.8.x is long dead.  The last release was nearly 3 years
ago, and almost no work has been done on it since then.  In the
meantime, probably on the order of hundreds of bug fixes have been
applied to 2.0 and never backported to 1.8.  At this point, it would be
a major effort to produce a new 1.8.x release that we wouldn't be
ashamed of.  No one has volunteered to do that work.  There are many far
more important things to work on, and not enough people to do it all.

Guile 2.0 was released over 2.5 years ago, and is now in all the major
distros, including Debian stable, the last few Ubuntu and Fedora
releases, etc.  Please, let's move on.

> Many "stable" distros will take _years_ to advance to 2.x,

I guess you mean the enterprise distros like RHEL, CentOS, etc.  Do you
think many users of those distros will want to use the latest autogen
release?

> MY technique is to blindly replace anything after "SCM_NORETURN"
> with "_Noreturn" on any line #define-ing SCM_NORETURN.

Looking at C11, it appears that _Noreturn belongs before the function
return type, whereas __attribute__ (__noreturn__) and SCM_NORETURN goes
after the formal parameter list.  So I don't see how your proposed
workaround can work properly.  Am I missing something?

     Regards,
       Mark

Re: There is no returning

[Paul Eggert]

Mark H Weaver wrote:
> Looking at C11, it appears that _Noreturn belongs before the function
> return type, whereas __attribute__ (__noreturn__) and SCM_NORETURN goes
> after the formal parameter list.  So I don't see how your proposed
> workaround can work properly.

__attribute__ (__noreturn__) can be at the start of a declaration.
So, for example, Gnulib does this, and it seems to work well in practice:

#if ! (defined _Noreturn \
       || (defined __STDC_VERSION__ && 201112 <= __STDC_VERSION__))
# if (3 <= __GNUC__ || (__GNUC__ == 2 && 8 <= __GNUC_MINOR__) \
      || 0x5110 <= __SUNPRO_C)
#  define _Noreturn __attribute__ ((__noreturn__))
# elif defined _MSC_VER && 1200 <= _MSC_VER
#  define _Noreturn __declspec (noreturn)
# else
#  define _Noreturn
# endif
#endif

Re: There is no returning

[Mark H Weaver]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Mark H Weaver wrote:
>> Looking at C11, it appears that _Noreturn belongs before the function
>> return type, whereas __attribute__ (__noreturn__) and SCM_NORETURN goes
>> after the formal parameter list.  So I don't see how your proposed
>> workaround can work properly.
>
> __attribute__ (__noreturn__) can be at the start of a declaration.

Ah, that's good!  So perhaps we should just import the relevant gnulib
module and convert all existing uses of SCM_NORETURN to use _Noreturn
instead.  What do you think?

However, it should be noted that in all existing Guile releases, uses of
SCM_NORETURN are always placed after the formal parameter list, so
Bruce's proposed workaround would effectively put _Noreturn after the
formal parameter list as well.  I guess it would work if _Noreturn
happens to be defined as __attribute__ ((__noreturn__)), but not in the
general case.

     Thanks,
       Mark

Re: There is no returning

[Paul Eggert]

Mark H Weaver wrote:
> Ah, that's good!  So perhaps we should just import the relevant gnulib
> module and convert all existing uses of SCM_NORETURN to use _Noreturn
> instead.  What do you think?

I think it'll work; at least, _Noreturn has worked for Gnulib fairly well
since we introduced it in summer 2011.

> Bruce's proposed workaround would effectively put _Noreturn after the
> formal parameter list as well.  I guess it would work if _Noreturn
> happens to be defined as __attribute__ ((__noreturn__)), but not in the
> general case.

Yes, that sounds right.  If user code employs SCM_NORETURN in that position
and you therefore you can't change SCM_NORETURNto 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.

Re: There is no returning

[Bruce Korb]

[-- Attachment #1: Type: text/plain, Size: 1966 bytes --]

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
+


[-- Attachment #2: fix-guile.sh --]
[-- Type: application/x-shellscript, Size: 912 bytes --]

Re: There is no returning

[Ludovic Courtès]

Paul Eggert <eggert@cs.ucla.edu> skribis:

> A better solution, if you want to be portable to
> MSVC, is to use _Noreturn instead of noreturn.
> This is for reasons described in stdnoreturn.in.h.
>
> '_Noreturn' is a bit ugly; if you don't care about
> MSVC, then __attribute__((__noreturn__)) is
> a good way to go.

Not sure what you mean by “ugly”, but ‘_Noreturn’ has the huge advantage
of being a reserved identifier per POSIX (info "(libc) Reserved Names"),
while ‘noreturn’ is not.

What would you think of sticking to the standard and less problematic
‘_Noreturn’ identifier in Gnulib?

(I also agree that it’s better for Guile’s public headers to use
‘__noreturn__’, but using ‘noreturn’ was not completely silly either.)

Thanks,
Ludo’.

Re: There is no returning

[Bruce Korb]

On 11/17/13 13:18, Ludovic Courtès wrote:
> What would you think of sticking to the standard and less problematic
> ‘_Noreturn’ identifier in Gnulib?
>
> (I also agree that it’s better for Guile’s public headers to use
> ‘__noreturn__’, but using ‘noreturn’ was not completely silly either.)

"noreturn" is a C11 keyword and does not need #define-ing, except as
a C11 compatibility thing.  When you #include <stdnoreturn.h>, that
token should work as expected.  gnulib makes that available.

Re: There is no returning

[Ludovic Courtès]

Bruce Korb <bkorb@gnu.org> skribis:

> On 11/17/13 13:18, Ludovic Courtès wrote:
>> What would you think of sticking to the standard and less problematic
>> ‘_Noreturn’ identifier in Gnulib?
>>
>> (I also agree that it’s better for Guile’s public headers to use
>> ‘__noreturn__’, but using ‘noreturn’ was not completely silly either.)
>
> "noreturn" is a C11 keyword

Well it’s a macro from <stdnoreturn.h>, but the keyword is _Noreturn.
As ugly as it may look, ‘_Noreturn’ was chose to avoid name clashes.

> When you #include <stdnoreturn.h>, that token should work as expected.
> gnulib makes that available.

Right, I had overlooked the standardization of <stdnoreturn.h>.
Sorry for the noise!

Ludo’.

Re: There is no returning

[Paul Eggert]

Ludovic Courtès wrote:

> What would you think of sticking to the standard and less problematic
> ‘_Noreturn’ identifier in Gnulib?

That's what Gnulib does already.  Other than the stdnoreturn module
itself, Gnulib modules always use _Noreturn rather than
noreturn.  This is not merely because of namespace issues;
it's also because noreturn doesn't work well with MSVC
(the Gnulib workaround for this turns 'noreturn' into a no-op).