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 n
Bruce Korb 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 comp
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" i
Paul Eggert 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.
N
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 use
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 s
Paul Eggert 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.
>
>
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__) c
Bruce Korb 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=b1fe20c24ccb3804
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
Bruce Korb 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
On 2013-11-10 Bruce Korb 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
On 2013-11-11 Harlan Stenn 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
Hi Andreas,
Andreas Metzler writes:
> On 2013-11-11 Harlan Stenn 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.
>
>
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 debi
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.
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.
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
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
19 matches
Mail list logo
