Re: Always provide exit() & friends prototypes.

[Jonathan Larmour <jifl at eCosCentric dot com>]

Sergei Organov wrote:
> Jonathan Larmour <jifl@eCosCentric.com> writes:
> > Sergei Organov wrote:
> > > Jonathan Larmour <jifl@eCosCentric.com> writes:
> > > > Sergei Organov wrote:
> > > > > Hello,
> > > > >
> > > > > A short patch below ensures exit(), etc. prototypes are provided in
> > > > > <stdlib.h> even when CYGINT_ISO_EXIT is undefined.
> > > > >
> > > > > For me it solves the problem that I don't wish to use libc_startup
> > > > > package, but do use exit()/abort() routines in applications. So the
> > > > > situation is that application itself provides implementation of those
> > > > > functions, while their declarations are expected to be found in the
> > > > > <stdlib.h>.
> > > > Then you should add your own package and implement CYGINT_ISO_EXIT;
> > > Even if I can't think of an implementation? A package that provides
> > > empty or CYG_FAIL'ing exit()? Why?
> > Then fix your code not to use it :-), or "#define exit(x)" in an
> > application header or something. I think it's much more valuable to
> > more eCos users that people who call functions that are not included
> > due to configuration choices that they have made get it picked up
> > straight away at compile time.
> >
> > > > or declare them in your own application-specific header.
> > > Not an option. Almost any C code on this planet expects to find exit()
> > > declaration in the <stdlib.h>.
> > Only because they assume it is a conforming implementation, meaning
> > there's a real implementation.
>
> IMHO most of the code that calls exit(), calls it just to exit
> application, whatever that actually means, and they only assume that
> this call will never return back.

What's the point if the real function may not exist? And the existence of 
it is outside of eCos's knowledge or control?

(By the way, there's also nothing stopping you providing your own stdlib.h 
at the head of your application include path).

> > What we're talking about here is a non-conforming implementation (due
> > to deliberate configuration choices by the programmer).
>
> Yes, sure, but what is your point? Are you saying that eCos provides
> conforming implementation whenever exit() is declared in <stdlib.h>? 

I mean that it's up to the user to decide if they want a conforming 
implementation or not. If they don't and have selected a configuration 
accordingly then it would be incorrect to expect to find an exit() 
declaration in <stdlib.h>. Unless they have chosen the configuration to 
include it.

> What about the case when, say, CYGFUN_LIBC_ATEXIT is set to 0? Is eCos
> implementation still conforming? If not, why exit() is still defined in
> <stdlib.h> in this case? Moreover, declaration of atexit() that in this
> case lacks definition, is still there as well.

Yeah, the behaviour of atexit() there is not great.

> > > > Only OS definitions should go in <stdlib.h>.
> > > The contents of <stdlib.h> is specified by the C standard, and exit() is
> > > standard declaration that should be there in <stdlib.h> according to the
> > > C standard. Currently (at some configuration options) eCos provides
> > > non-standard <stdlib.h> and non-standard libc. I'd vote for standard
> > > <stdlib.h> and non-standard libc (missing exit() definition) instead,
> > I vote no declaration if there is no definition, in order to pick up
> > configuration misunderstandings as soon as possible.
>
> Well, let's then think why there is no definition in the first place? 
> eCos has the definition for exit(), and in fact it in no way depends on
> existence of some thread called "main" that invokes "main()" routine, so
> exit() existence should not depend on the presence/absence of the
> libc_startup package.

I think you are reading too much into the name of libc_startup. Without 
CYGSEM_LIBC_STARTUP_MAIN_THREAD (or CYGSEM_LIBC_STARTUP_MAIN_INITCONTEXT) 
enabled no main() startup is provided. As the more verbose package 
description says it is a package for "ISO environment startup/termination". 
If you don't want to use the functionality it provides, that's up to you.

I'm not saying what's there is entirely faultless and bug-free. For example 
I see it implements CYGINT_ISO_MAIN_STARTUP regardless, rather than only if 
CYGINT_LIBC_STARTUP_CONTEXT is implemented.

> Anyway, I still believe something is definitely wrong here in its
> current state.

There might be. But I don't think your suggested fix would be a move in the 
right direction.

> Trying to look at things from your POV, I think that there should be
> separate single libc_exit package that implements "CYGINT_ISO_EXIT", and
> that other packages could then "require" it. Though from my POV, there
> is absolutely no need for this complexity, -- eCos can easily always
> provide its current exit() instead. What's wrong about the latter?

I think a separate package would be overkill. But I wouldn't be averse to 
more flexibility in the configuration within the libc_startup package.

> > as well as of course those packages which do have consistent CDL
> > "requires" statements.
>
> Of course. Could you please tell the name of at least one package that
> "requires" CYGINT_ISO_EXIT?

Well, that or respond correctly to its macro definition (or absence 
thereof). There are a few.

> The less dependencies you have, -- the better, right? Dependencies that
> are absolutely non-obvious are bad. Dependency on CYGINT_ISO_EXIT to be
> able to call *standard* exit() function is absolutely non-obvious,
> that's why nobody calling exit() would even think that he now depends on
> something.

It's a configurable system. They should. Although not for application 
developers - for them it's a case of choosing the right configuration in 
the first place. And if you include libc_startup in your config, you get 
exit() - both declaration and definition.

> Worse yet, depending on CYGINT_ISO_EXIT currently implies dependency
> on libc_startup, that is very confusing and IMHO is plain wrong.

Don't read too much into the abbreviated package name.

> No. My case is not specific in any way. Please try to do what you suggest
> for those ~200 occurrences of exit() in the eCos source tree first, then
> I'll re-consider your suggestion.

How would declaring these without a definition help in any way whatsoever? 
People were sloppy in the CDL - it happens, especially with importing large 
amounts of third party code.  That's what needs to be fixed.

(Also, from my own searches I think that number is a large overestimate - a 
zillion microwindows demos applications don't really count, and files to be 
built only on the host system reduce that number considerably. I don't 
expect the number to be zero - I expect it to be in the 10s, affecting only 
a small number of packages. But I don't think talking about specific 
numbers helps anyone, so I won't prolong it).

> In addition, please take into account that unlike eCos sources, it's not
> an option in applications to depend on *non-standard* CYGINT_ISO_EXIT
> define to be able to call *standard* function.

Application developers must choose their configuration appropriately for 
their application. And if they use exit() without it being included in 
their config, they should rightly expect a compile error.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
 >>>> Visit us on stand 810 at The Embedded Systems Show 2007, NEC <<<<
 >>>> Oct 17-18 Birmingham, UK http://www.edaexhibitions.com/ess/  <<<<
------["The best things in life aren't things."]------      Opinions==mine