returning a value from a constructor

[Steve Holle]

It might have helped if I'd given you a little context here.  This all 
started because we needed a bigger serial queue and didn't want to rebuild 
RTEMS, a particularly long and fragile process under cygwin as you know, so 
we pulled some of the code out of termios.c and read.c to resize the buffer 
and compile it in our source.  I'm sure there is a more elegant way to do 
all this.

Oh, also, we have hacked a custom char_available out of the termios code 
that only checked to see if a char is available without blocking.  Again, 
there is probably a much more elegant way to do this.  Please don't 
consider this anything like a bug report or criticism of the way the code 
was written.  I was mainly making an observation in case someone else  runs 
into a similar error.

At 01:47 PM 2/18/2005, Joel Sherrill <joel at OARcorp.com> wrote:
>Steve Holle wrote:
>>We ran into an interesting problem today.  We tried to call the following 
>>rtems_libio functions from a c++ constructor :
>>       rtems_libio_check_fd( fd );
>>       iop = rtems_libio_iop( fd );
>>       rtems_libio_check_is_open(iop);
>>The first and third generated the following errors :
>>/tcb2/rlc/source/char_available.c:55: returning a value from a constructor
>>/tcb2/rlc/source/char_available.c:57: returning a value from a constructor
>>This baffled us for a time until we realized that these two functions 
>>were actually macros that contained returns for failure.  We solved the 
>>problem by calling a subroutine that called the two functions.  If the 
>>two functions were actually subroutines instead of macros the code would 
>>have compiled.
>
>
>This took me a second to figure out what was going on.
>They are actually in libio_.h which is intended to be helper macros for 
>the implementation of the section 2 system calls.  Are you getting 
>visibility of this macro through an intentionally public .h file?
>
>Or are you directly including libio_.h?
>
>
>>I know this would be a huge job and probably not worth the time but it 
>>would be helpful if it was easy to tell macros from subroutines.  One 
>>method I've seen in the past is that all macros are capitalized.
>
>That is one way.
>
>
>>Just wanted to get this into the archive in case someone else runs into 
>>this problem.
>>Steve Holle
>>Link Communications, Inc.
>>1035 Cerise Rd.
>>Billings, MT  59101
>>sholle at link-comm.com
>
>
>--
>Joel Sherrill, Ph.D.             Director of Research & Development
>joel at OARcorp.com                 On-Line Applications Research
>Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (256) 722-9985

Steve Holle
Link Communications, Inc.
1035 Cerise Rd.
Billings, MT  59101
sholle at link-comm.com