[9fans] X11

[9fans] X11

[Steve Simon]

I have rebuilt equis with the change in ape's select
and it seems to work fine (tested with xlock and xterm only).

this was not quite straightforward due to changes in ape, and
the compiler becomming a little stricter.

On this subject, what is the general feeling on integer
type'ed functions which call exit() before falling off the
end of the function?

This is fairly common in X11 and I have just added a return 0 on
the end to push the code through the compiler, but should the
compiler be taught about this case?

if so, it gets a bit nasty as this feature is named
exit() under ape and exits() in native plan9.

Personally I think falling of the end of a function
is a bug and should be  fixed, but perhaps it should
just be a warning rather than an error to make
building foreign code simpler.

-Steve

Re: [9fans] X11

[Charles Forsyth]

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

ANSI C has a "_Noreturn" attribute that I started to implement,
but I think I might fall back to a #pragma, which would be quicker to do.



On 28 February 2013 14:15, Steve Simon <steve@quintile.net> wrote:

> I have rebuilt equis with the change in ape's select
> and it seems to work fine (tested with xlock and xterm only).
>
> this was not quite straightforward due to changes in ape, and
> the compiler becomming a little stricter.
>
> On this subject, what is the general feeling on integer
> type'ed functions which call exit() before falling off the
> end of the function?
>
> This is fairly common in X11 and I have just added a return 0 on
> the end to push the code through the compiler, but should the
> compiler be taught about this case?
>
> if so, it gets a bit nasty as this feature is named
> exit() under ape and exits() in native plan9.
>
> Personally I think falling of the end of a function
> is a bug and should be  fixed, but perhaps it should
> just be a warning rather than an error to make
> building foreign code simpler.
>
> -Steve
>
>

[-- Attachment #2: Type: text/html, Size: 1554 bytes --]

Re: [9fans] X11

[dexen deVries]

On Thursday 28 of February 2013 14:21:08 Charles Forsyth wrote:
> ANSI C has a "_Noreturn" attribute that I started to implement,
> but I think I might fall back to a #pragma, which would be quicker to do.

another quick hack:

#define exit(status) do { exit(status); return 0; } while (0)

with do{}while() guarding against treating it as an expression.


-- 
dexen deVries

[[[↓][→]]]

Re: [9fans] X11

[Joel C. Salomon]

On Thu, Feb 28, 2013 at 12:19 PM, dexen deVries <dexen.devries@gmail.com> wrote:
> #define exit(status) do { exit(status); return 0; } while (0)

What does kenc do with a void function attempting to return 0?

—Joel

Re: [9fans] X11

[Steve Simon]

> What does kenc do with a void function attempting to return 0?

t.c:6 incompatible types: "VOID" and "INT" for op "RETURN"

-Steve

Re: [9fans] X11

[Federico G. Benavento]

thanks steve

On Thu, Feb 28, 2013 at 4:46 PM, Steve Simon <steve@quintile.net> wrote:
>> What does kenc do with a void function attempting to return 0?
>
> t.c:6 incompatible types: "VOID" and "INT" for op "RETURN"
>
> -Steve
>



--
Federico G. Benavento

Re: [9fans] X11

[Comeau At9Fans]

On Thu, Feb 28, 2013 at 1:10 PM, Joel C. Salomon <joelcsalomon@gmail.com> wrote:
>
> On Thu, Feb 28, 2013 at 12:19 PM, dexen deVries <dexen.devries@gmail.com> wrote:
> > #define exit(status) do { exit(status); return 0; } while (0)
> What does kenc do with a void function attempting to return 0?

incompatible types: "VOID" and "INT" for op "RETURN"

There isn't a perfect solution considering existing code etc but
similarly can be diagnosed in Steve's case, more along the lines of:

warning: missing return statement at end of non-void function "foo"

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] X11 [was APE select and awkward Python subprocess PIPEfitting]

[Jeff Sickel]

I've submitted a patch, ape-select, that just removes the
offending EBADF.  If there's a desire to up the FD_SETSIZE
to 1024 like everyone else, we should address that as a
separate patch and modernize the <sys/select.h> in the
process.

-jas

Re: [9fans] X11 [was APE select and awkward Python subprocess PIPEfitting]

[Charles Forsyth]

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

On 28 February 2013 23:02, Jeff Sickel <jas@corpus-callosum.com> wrote:

> that just removes the
> offending EBADF
>

it should generate EBADF for any bit set in any of the fd_sets when that
bit doesn't correspond to an open file descriptor.
the mistake was producing EBADF on a very specific condition associated
with an *open* file descriptor

[-- Attachment #2: Type: text/html, Size: 730 bytes --]