Very Computer

I've been working on this real-time audio engine partly
on SGI and partly under Linux ... in conjunction with a
professor.

There is a function defined:

double foo() {
        ...
        if (something)
                return NULL;    
        ...

Quote:}

Any input would be great.

Thanks,

DT
--
David Topper (me)
Research Assistant
Columbia University Center for Computer Music
Student of Computer Music, Science, Art & Life
http://www.panix.com/~topper

Quote:

>I've been working on this real-time audio engine partly
>on SGI and partly under Linux ... in conjunction with a
>professor.

>There is a function defined:

>double foo() {
>        ...
>        if (something)
>                return NULL;    
>        ...
>}

>The IRIX CC compiler allows this wheras gcc/g++ does not.
>I NEED TO BE ABLE TO DO THIS

Quote:>... or else rewrite major parts
>of the code.  

Quote:>Part of this return function is needed to inter-
>face with a parser that calls pointer to functions ... accessed
>by that value.

--
James Youngman       VG Gas Analysis Systems |The trouble with the rat-race
 Before sending advertising material, read   |is, even if you win, you're
http://www.law.cornell.edu/uscode/47/227.html|still a rat.

Hi Dave...

        Yes... I have to agree with the others... the NULL in C++ is defined as 0
and your compiler cast 0 to (double) 0 in the return...

Regards
Brian

Quote:> I've been working on this real-time audio engine partly
> on SGI and partly under Linux ... in conjunction with a
> professor.

> There is a function defined:

> double foo() {
>    ...
>    if (something)
>            return NULL;    
>    ...
> }

> The IRIX CC compiler allows this wheras gcc/g++ does not.
> I NEED TO BE ABLE TO DO THIS ... or else rewrite major parts
> of the code.  Part of this return function is needed to inter-
> face with a parser that calls pointer to functions ... accessed
> by that value.

> Any input would be great.

> Thanks,

> DT
> --
> David Topper (me)
> Research Assistant
> Columbia University Center for Computer Music
> Student of Computer Music, Science, Art & Life
> http://www.panix.com/~topper

: I've been working on this real-time audio engine partly
: on SGI and partly under Linux ... in conjunction with a
: professor.

: There is a function defined:

: double foo() {
:       ...
:       if (something)
:               return NULL;    
:       ...
: }

: The IRIX CC compiler allows this wheras gcc/g++ does not.
: I NEED TO BE ABLE TO DO THIS ... or else rewrite major parts
: of the code.  Part of this return function is needed to inter-
: face with a parser that calls pointer to functions ... accessed
: by that value.

I think you're a little bit confused about NULL.  Quoting stddef.h (or
various other include files):

        #define NULL 0

There is nothing special about NULL: it is just 0.  If you return NULL
from a function that returns a double, you're just returning 0.  I
suspect this is not what you think you're doing.  The reason that gcc
is complaining is that its version of stddef.h has:

        #define NULL ((void *)0)

Without pulling out my C standard, I'm not sure if one or the other of
these definitions of NULL is "wrong".  The gcc one is less likely to
be misused.

I'm afraid I don't see how this has anything to do with passing
pointers to functions.

-- Dave Hinds

Quote:> I'm afraid I don't see how this has anything to do with passing
> pointers to functions.

If it's a pointer to function you want, then foo () has to return a
pointer to a function. If it's success or failure, try a boolean
function. If some kindly C++ guru could clear up for a poor PhD student
who's short on documentation whether bool is actually a part of C++?
Borland (as usual) isn't clear whether it's something they added because
they felt like it or it's a proper part of the language. I'm thinking
along the lines here of

bool foo (double *result)
{
  ...
  if (something)
    return false;
  ...
  /* some processing, set *result to be the (double) result of the
     processing */

  return true;

Quote:}

double fooSays;

...

if (foo (&fooSays))
{
  /* do some processing using fooSays */

Quote:}

Quote:}

jim
--

Come and see me -
I'm the same boy I used to be

The value of NULL is compiler dependent (and defined in standard
include files such as stdlib.h).  It often works out to be zero
but that is not guaranteed.  So include a standard header file
that defines NULL or change your return statement to return 0;

Quote:

> The IRIX CC compiler allows this wheras gcc/g++ does not.

NULL is often used as an error code by functions that return
a pointer to an object.  For example, malloc() will return a
NULL pointer if it can't allocate memory.  Returning
(double) NULL strikes me as screwy.  If NULL is (effectively)
zero, your function will return zero if there is an error or
when it actually should return zero.  If you need to tell those
two cases apart, you're in trouble.

Quote:> I NEED TO BE ABLE TO DO THIS ... or else rewrite major parts
> of the code.  Part of this return function is needed to inter-
> face with a parser that calls pointer to functions ... accessed
> by that value.

I realise this means rewriting parts of your code.  You should
be able to do that with any decent text editor;  simply change
the argument list of your function and replace every occurrence
of  "return NULL;"  with "errorcode = 1; return 0.0;".
Or rewrite your parser so it catches some exception that
you throw instead --- that'd probably be easier.

- <Automagically appended trailer>
Robert O'Dowd                   Phone   : +61 9 550 1618
DSTO Bldg A51, HMAS Stirling    Fax     : +61 9 550 1577

Rockingham, Western Australia, 6168            

Disclaimer: Opinions above are MINE and may be worth what you paid for
them.

To avoid such abuses, GNU defines NULL as '((void*)0)'.  To work round
this simply.

#undef NULL
#define NULL 0

There appears to be a religious war about whether NULL should be '0'
or '((void*) 0)'.  However I don't think even people who argue that
NULL should be '0' would consider it right to use it in a floating
point context.

The reason other environments define it as '0' not '((void*)0)' is due
IMHO to an overly pedantic reading of the ANSI C++ standard.  It
states that implicit convertion from void* to another pointer type is
forbidden.  But so is convertion from an integer under *usual*
circumstances!  If an exception can be made for the numeric constant
'0' why not for '((void*)0)'?

I'm firmly on the GNU side of this particular war.

--

 .  _\\__[oo       from       | Phones: +44 121 471 3789 (home)

.  l___\\    /~~) /~~[  /   [ | PGP-fp: D7 03 2A 4B D8 3A 05 37...
 # ll  l\\  ~~~~ ~   ~ ~    ~ | http://wcl-l.bham.ac.uk/~bam/

: in defining NULL to be 0 rather than (void*) 0.  NULL must be a
: constant integral expression that evaluates to 0; "0" satisfies
: that requirement, and "(void*) 0" does not.

        Question 5.6 from the comp.lang.c FAQ
(ftp://rtfm.mit.edu/pub/usenet/comp.lang.c/C-FAQ-list):

5.6:    If NULL were defined as follows:

                #define NULL ((char *)0)

        wouldn't that make function calls which pass an uncast NULL
        work?

A:      Not in general.  The problem is that there are machines which
        use different internal representations for pointers to different
        types of data.  The suggested definition would make uncast NULL
        arguments to functions expecting pointers to characters work
        correctly, but pointer arguments of other types would still be
        problematical, and legal constructions such as

                FILE *fp = NULL;

        could fail.

        Nevertheless, ANSI C allows the alternate definition

                #define NULL ((void *)0)

        for NULL.  Besides potentially helping incorrect programs to
        work (but only on machines with homogeneous pointers, thus
        questionably valid assistance), this definition may catch
        programs which use NULL incorrectly (e.g. when the ASCII NUL
        character was really intended; see question 5.9).

        References: Rationale Sec. 4.1.5.

The answer to question 5.9 includes the following text:

        NULL should *not* be used when another kind of 0 is required,
        even though it might work, because doing so sends the wrong
        stylistic message.  (Furthermore, ANSI allows the definition of
        NULL to be ((void *)0), which will not work at all in non-
        pointer contexts.)  In particular, do not use NULL when the
        ASCII null character (NUL) is desired.  Provide your own
        definition

                #define NUL '\0'

        if you must.

Quote:>         Nevertheless, ANSI C allows the alternate definition

>                 #define NULL ((void *)0)

>         for NULL.  Besides potentially helping incorrect programs to
>         work (but only on machines with homogeneous pointers, thus
>         questionably valid assistance), this definition may catch
>         programs which use NULL incorrectly (e.g. when the ASCII NUL
>         character was really intended; see question 5.9).

>         References: Rationale Sec. 4.1.5.

server.physiol.ucl.ac.uk says...

This means that on many machines people now define null as 0 for C++.

g++ however tries to be nice to you, but does this in an inconsistant way
- there are places where (void*)0 is an error (as required by DWP), and
other places where it isn't.  It should do one or the other *and* should
with -ansi -pedantic give an error for using (void*)0 as a "null" pointer
- except for void pointers of course :-)

Quote:> If it's a pointer to function you want, then foo () has to return a
> pointer to a function. If it's success or failure, try a boolean
> function. If some kindly C++ guru could clear up for a poor PhD student
> who's short on documentation whether bool is actually a part of C++?
> Borland (as usual) isn't clear whether it's something they added because
> they felt like it or it's a proper part of the language. I'm thinking
> along the lines here of

> bool foo (double *result)

Hmm, while technically legal this is not the C++ way of doing things.  
Try -

bool foo (double& result)

Quote:> {
>   ...
>   if (something)
>     return false;
>   ...
>   /* some processing, set *result to be the (double) result of the
>      processing */

>   return true;
> }

Quote:> Then you would call this with

> double fooSays;

> ...

> if (foo (&fooSays))

Quote:> {
>   /* do some processing using fooSays */
> }
> else
> {
>   /* do error handling for foo */
> }

IIRC something like this is also considered to be the null pointer -

char* pX = (char*)(2 - 1 - 1);  // Set pX to null pointer

g++ leaves NULL as (void*)0 through historical reasons - however I
suspect it won't in future.  Currently it does inconsistent checking
depending on where the value is used.  This results in an error
sometimes, but not all times.  It should probably support (void*)0 for
backwards compatability, and when -ansi -pedantic is supplied give an
error.

Personally I'd never compiler code without -ansi -pedantic supplied.

If you talk to the people involved with the GNU compiler I don't believe
that any conscious decisions have been made to take one approach or the
other, except that making a standards conforming compiler is the most
important priority.

Rohan