Compilation under HPUX or any other commercial Unix

[thomas...@gmx.at]

Hello,
Does someone here have access to HPUX or any other commercial Unix
variant? I have an Open Source project and want to find out if it
compiles and works under HPUX or other Unix variants. Several years
ago I used HPUX to develop my project, but now I have no access to
HPUX. A short time ago I added some stuff, which uses elements from
struct FILE. Struct FILE is defined in <stdio.h>. I know this is
sommething not considered portable. Therefore I would like to check,
if it compiles flawlessly on different operating systems.

Please help me.
The Open Source project is Seed7 and its latest version (currently
seed7_05_20120520.tgz) can be downloaded from:

http://sourceforge.net/projects/seed7/files

The *.tgz archive can be easily unpacked with tar. How this is done
is explained here:

http://seed7.sourceforge.net/faq.htm#uncompress

To compile Seed7 you only need two tools: Make and a C compiler. In
the optimal case you just switch to the seed7/src directory and do:

make depend
make

Probably some warnings and errors will show up. Can you please send
me this warnings and errors.

I would also be interested in the file stdio.h from HPUX, and other
commercial Unix systems. It is an include file for C, so there are
probably no copyright issues.

Many many thanks in advance for your effort.

Regards,
Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[Volker Birk]

thomas...@gmx.at wrote:
> I have an Open Source project and want to find out if it
> compiles and works under HPUX or other Unix variants.

Hi,

maybe this can be helpful for HP-UX:

<http://hpux.connect.org.uk/hppd/answers/2-1.html>

For other Unix variants I would ask the respective manufacturers.

Yours,
VB.
--
"Warum machen wir den Massenmörder Breivik zum Popstar des Bösen?"
"Weil eine Million Sarrazin-Buchkäufer schlechter aufs Gruppenfoto passen."
Friedrich Küppersbusch in <https://www.taz.de/Die-Woche/!91993/>

[Casper H.S. Dik]

thomas...@gmx.at writes:

>Does someone here have access to HPUX or any other commercial Unix
>variant? I have an Open Source project and want to find out if it
>compiles and works under HPUX or other Unix variants. Several years
>ago I used HPUX to develop my project, but now I have no access to
>HPUX. A short time ago I added some stuff, which uses elements from
>struct FILE. Struct FILE is defined in <stdio.h>. I know this is
>sommething not considered portable. Therefore I would like to check,
>if it compiles flawlessly on different operating systems.

Which fields are you using and what for?

(E.g., under Solaris you can't use any fields in 64 bit programs and
you can no longer use the _file field in 32 bit Solaris.)

Casper

[Fritz Wuehler]

Volker Birk <bum...@dingens.org> wrote:

> thomas...@gmx.at wrote:
> > I have an Open Source project and want to find out if it
> > compiles and works under HPUX or other Unix variants.

What is your open source project about and where is the source?

[Noob]

Casper H.S. Dik wrote:

> Thomas wrote:
>
>> Does someone here have access to HPUX or any other commercial Unix

cf. perhaps http://www.unixporting.com/remote-accounts.html

>> variant? I have an Open Source project and want to find out if it
>> compiles and works under HPUX or other Unix variants. Several years
>> ago I used HPUX to develop my project, but now I have no access to
>> HPUX. A short time ago I added some stuff, which uses elements from
>> struct FILE. Struct FILE is defined in <stdio.h>. I know this is

>> something not considered portable. Therefore I would like to check,

>> if it compiles flawlessly on different operating systems.
>
> Which fields are you using and what for?

I'm curious too.

[Noob]

Fritz Wuehler wrote:

> What is your open source project about and where is the source?

Are you being serious? He used to advertize his software at
least once a month.

[Fritz Wuehler]

Oh sorry. I am new here.

[thomas...@gmx.at]

On Thursday, May 24, 2012 1:03:28 PM UTC+2, Fritz Wuehler wrote:
> Volker Birk <bum...@dingens.org> wrote:

> > Thomas Mertes wrote:
> > > I have an Open Source project and want to find out if it
> > > compiles and works under HPUX or other Unix variants.
>
> What is your open source project about and where is the source?

It is an interpreter and a compiler for a
programming language. The description is here:

http://seed7.sourceforge.net

and the source can be downloaded from:

http://sourceforge.net/projects/seed7/files

[thomas...@gmx.at]

On Thursday, May 24, 2012 11:30:43 AM UTC+2, Casper H. S. Dik wrote:

> Thomas Mertes writes:
>
> >Does someone here have access to HPUX or any other commercial Unix
> >variant? I have an Open Source project and want to find out if it
> >compiles and works under HPUX or other Unix variants. Several years
> >ago I used HPUX to develop my project, but now I have no access to
> >HPUX. A short time ago I added some stuff, which uses elements from
> >struct FILE. Struct FILE is defined in <stdio.h>. I know this is
> >sommething not considered portable. Therefore I would like to check,
> >if it compiles flawlessly on different operating systems.
>
> Which fields are you using and what for?

To find out if getc() would block or not. The details follow below.

One of the things that FILE * does is buffering. So when you call
getc() you might get a character, which is already in the buffer or
you might get a character, which is read from the underlying file
descriptor just when you call getc(). Reading from the buffer will
never block, but reading from the file descriptor might block.
Keep in mind: The file descriptor might be a pipe a socket or a
terminal. And of cause: Checking the buffer will not work, when
other threads read from the same file.

The reason for this: I found situations where it is really helpful
to know in advance, if getc() will block or not.

I had the idea to define a Seed7 function, named inputReady(), which
tells you, if reading one character from a Seed7 file would block or
not. For Seed7 sockets (which are based on file descriptors) this
function can be defined easily with poll() or select(). But for
FILE * a different logic is needed. To do this I defined the C macro
read_buffer_empty(). Under Linux read_buffer_empty() is defined as:

#define read_buffer_empty(fp) ((fp)->_IO_read_ptr >= (fp)->_IO_read_end)

This is exactly the same condition as is used in the macro
_IO_getc_unlocked(), which is defined in <libio.h>. For other
OS / compiler / runtime library combinations I was also able to find
the condition, which decides if a read buffer is empty. To do this
it was necessary to know which elements of FILE are used in getc()
or some macro, with the same logic. During 'make depend' a program
checks the different possible read_buffer_empty() macros and chooses
a working one.

If you are interested, how this is done, look into the file
"seed7/chkccomp.c".

With read_buffer_empty() and poll() the function inputReady can be
written. A simplified version of the C function filInputReady(),
which implements inputReady() is:

int filInputReady (FILE *aFile)
{
int file_no;
struct pollfd pollFd[1];
int poll_result;
int result;

/* filInputReady */
if (!read_buffer_empty(aFile)) {
result = 1;
} else {
file_no = fileno(aFile);
if (file_no != -1) {
pollFd[0].fd = file_no;
pollFd[0].events = POLLIN;
poll_result = os_poll(pollFd, 1, 0);
if (unlikely(poll_result < 0)) {
raise_error(FILE_ERROR);
result = 0;
} else {
result = poll_result == 1 && (pollFd[0].revents & POLLIN);
} /* if */
} else {
raise_error(FILE_ERROR);
result = 0;
} /* if */
} /* if */
return result;
} /* filInputReady */

> (E.g., under Solaris you can't use any fields in 64 bit programs and
> you can no longer use the _file field in 32 bit Solaris.)

The FILE struct probably still contains the information. Mayby it is
defined in a different header file.

[Rainer Weikusat]

thomas...@gmx.at writes:
> On Thursday, May 24, 2012 11:30:43 AM UTC+2, Casper H. S. Dik wrote:
>> Thomas Mertes writes:
>>
>> >Does someone here have access to HPUX or any other commercial Unix
>> >variant? I have an Open Source project and want to find out if it
>> >compiles and works under HPUX or other Unix variants. Several years
>> >ago I used HPUX to develop my project, but now I have no access to
>> >HPUX. A short time ago I added some stuff, which uses elements from
>> >struct FILE. Struct FILE is defined in <stdio.h>. I know this is
>> >sommething not considered portable. Therefore I would like to check,
>> >if it compiles flawlessly on different operating systems.
>>
>> Which fields are you using and what for?

[...]

> The reason for this: I found situations where it is really helpful
> to know in advance, if getc() will block or not.

But you can't know that it advance because data might become availble
in the time between the check and the time you are using the
information (in slightly pathological situations, already available
data might also go away again). There is one (and only one) way to
ensure that a read wont' block: Make the file descriptor you're trying
to read from non-blocking. Also, if you're poking around in the
internal of stdio, you should probably just write your own buffering
layer instead (that's not really complicated, especially when
omitting the more idiotic interfaces, fread and fwrite) or include a
stdio implementations that's compatible with your code in it.

[thomas...@gmx.at]

Am Freitag, 25. Mai 2012 12:03:58 UTC+2 schrieb Rainer Weikusat:

> Thomas Mertes writes:
> > On Thursday, May 24, 2012 11:30:43 AM UTC+2, Casper H. S. Dik wrote:
> >> Thomas Mertes writes:
> >>
> >> >Does someone here have access to HPUX or any other commercial Unix
> >> >variant? I have an Open Source project and want to find out if it
> >> >compiles and works under HPUX or other Unix variants. Several years
> >> >ago I used HPUX to develop my project, but now I have no access to
> >> >HPUX. A short time ago I added some stuff, which uses elements from
> >> >struct FILE. Struct FILE is defined in <stdio.h>. I know this is
> >> >sommething not considered portable. Therefore I would like to check,
> >> >if it compiles flawlessly on different operating systems.
> >>
> >> Which fields are you using and what for?
>
> [...]
>
> > The reason for this: I found situations where it is really helpful
> > to know in advance, if getc() will block or not.
>
> But you can't know that it advance because data might become availble
> in the time between the check and the time you are using the
> information (in slightly pathological situations, already available
> data might also go away again).

No, when something is buffered in a FILE it cannot go away (as long
as no other thread reads from the FILE).

When it is possible to read from a FILE without blocking, this
situation will not change. The other way around is of cause
possible: A character may become available after the check. But this
can happen also when you use file descriptors and poll().

> There is one (and only one) way to
> ensure that a read wont' block: Make the file descriptor you're trying
> to read from non-blocking.

Which function makes a file descriptor (fd) non-blocking?

AFAIK a read() from a non-blocking file descriptor, when no
characters are available just returns 0 (Zero characters
successfully read).

Do you suggest to switch the fd to non-blocking and then read from
FILE? In this case I ask myself: How could I distinguish a normal
char read or a char delivered from the FILE buffer from a char,
which was read non-blocking from the fd? What does getc() deliver in
this case? Maybe in this case getc() delivers EOF. This would lead
to code like (not tested):

file_no = fileno(aFile);
if (file_no != -1) {

... Make file_no non-blocking ...
ch = getc(aFile);
if (ch == EOF) {
result = 0;
} else {
ungetc(aFile, ch);
result = 1;
} /* if */
... Make file_no blocking again ...

} else {
raise_error(FILE_ERROR);
result = 0;
} /* if */

Could this work?

> Also, if you're poking around in the
> internal of stdio, you should probably just write your own buffering
> layer instead

Of cause. But I really would prefer to use the FILE interface.
Poking around is overstated. To keep the picture: I am just peeking
around. :-) BTW: In former times getc() used to be a macro, which
contained just the same condition I use for read_buffer_empty().

> (that's not really complicated, especially when
> omitting the more idiotic interfaces, fread and fwrite)

The Seed7 runtime library uses fread() and fwrite(), so this is not
an option.

> or include a
> stdio implementations that's compatible with your code in it.

For three different C libraries it was easy to find a solution for
the read_buffer_empty macro. Thank you for you suggestions, but I
really don't want to code everything myself.

I think that it really helps to know when there are chars buffered
in the FILE.

If someone has access to HPUX or other proprietary operating
systems: Could you help me to define the macro read_buffer_empty,
which determines if getc() cannot read from the internal buffer, but
needs to read from the underlying file descriptor.

If you can find the getc macro (or some similar macro) in <stdio.h>
the condition there could be used to define read_buffer_empty.

[Richard Kettlewell]

thomas...@gmx.at writes:
> Does someone here have access to HPUX or any other commercial Unix
> variant? I have an Open Source project and want to find out if it
> compiles and works under HPUX or other Unix variants. Several years
> ago I used HPUX to develop my project, but now I have no access to
> HPUX. A short time ago I added some stuff, which uses elements from
> struct FILE. Struct FILE is defined in <stdio.h>. I know this is
> sommething not considered portable. Therefore I would like to check,
> if it compiles flawlessly on different operating systems.

The field you want is spelled __cnt on at least one HPUX machine. But I
agree with Rainer; your strategy here is completely wrong and you'd
better off writing your own IO layer with the semantics you want.

--
http://www.greenend.org.uk/rjk/

[Geoff Clare]

thomas...@gmx.at wrote:

> Am Freitag, 25. Mai 2012 12:03:58 UTC+2 schrieb Rainer Weikusat:
>
>> There is one (and only one) way to
>> ensure that a read wont' block: Make the file descriptor you're trying
>> to read from non-blocking.
>
> Which function makes a file descriptor (fd) non-blocking?

int flags = fcntl(fd, F_GETFL);
fcntl(fd, F_SETFL, flags|O_NONBLOCK);

(plus error checking)

> AFAIK a read() from a non-blocking file descriptor, when no
> characters are available just returns 0 (Zero characters
> successfully read).

Historically, that was true for the O_NDELAY flag. With the POSIX
O_NONBLOCK flag, read() returns -1 and sets errno to EAGAIN.

> Do you suggest to switch the fd to non-blocking and then read from
> FILE? In this case I ask myself: How could I distinguish a normal
> char read or a char delivered from the FILE buffer from a char,
> which was read non-blocking from the fd? What does getc() deliver in
> this case? Maybe in this case getc() delivers EOF.

You could have found this information easily in your getc() man page
or in the online POSIX standard.

On end-of-file getc() returns EOF and feof() on the stream is true.
On error getc() returns EOF and sets errno, and ferror() on the stream
is true. The code looks something like this:

int ch = getc(fp);
int err = errno;
if (ch == EOF)
{
if (feof(fp))
{
/* ... handle end of file ... */
}
else if (err == EAGAIN)
{
/* ... no data available ... */
}
else
{
/* ... handle other errors ... */
}
}

--
Geoff Clare <net...@gclare.org.uk>

[Rich Gray]

thomas...@gmx.at wrote:
> Hello,
> Does someone here have access to HPUX or any other commercial Unix
> variant?

You might ask in comp.sys.hp.hpux.

[Rainer Weikusat]

thomas...@gmx.at writes:
> Am Freitag, 25. Mai 2012 12:03:58 UTC+2 schrieb Rainer Weikusat:
>> Thomas Mertes writes:

[...]

>>> The reason for this: I found situations where it is really helpful
>>> to know in advance, if getc() will block or not.
>>
>> But you can't know that it advance because data might become availble
>> in the time between the check and the time you are using the
>> information (in slightly pathological situations, already available
>> data might also go away again).
>
> No, when something is buffered in a FILE it cannot go away (as long
> as no other thread reads from the FILE).
>
> When it is possible to read from a FILE without blocking, this
> situation will not change.

Unless the documented purpose of a certain member of a FILE structure
(if it is a structure) is what you would like it to be in this
respect, any value of that could be used for anything by the actual
implementation. And this means if there isn't some kind of interface
which can be used to query the amount of ready-to-read data buffered
for this stream, it is not possible to tell if such data is really
available and will still be available by the time the next
'input-fetching something' is invoked.

[...]

>> There is one (and only one) way to ensure that a read wont' block:
>> Make the file descriptor you're trying to read from non-blocking.

[...]

> Do you suggest to switch the fd to non-blocking and then read from
> FILE?

I suggest that the existing facilities intended to deal with this
situation should be used.

[...]

>> Also, if you're poking around in the internal of stdio, you should
>> probably just write your own buffering layer instead
>
> Of cause. But I really would prefer to use the FILE interface.
>
> Poking around is overstated. To keep the picture: I am just peeking
> around. :-)

You're poking around inside of it in order to be able to peek at some
information stdio is supposed to hide from programs using it.

[...]

>> (that's not really complicated, especially when
>> omitting the more idiotic interfaces, fread and fwrite)
>
> The Seed7 runtime library uses fread() and fwrite(), so this is not
> an option.

Buffered streams are ill-suited for dealing with input or output
operations based on units larger than a single character/ byte (except
if the size of the internal buffer happens to be an integral multiple
of the input unit size). Technically, as soon as said I/O unit size is
larger than one, there's already a buffering layer on top of the stdio
buffering involved.

>> or include a stdio implementations that's compatible with your code
>> in it.
>
> For three different C libraries it was easy to find a solution for
> the read_buffer_empty macro. Thank you for you suggestions, but I
> really don't want to code everything myself.

If you want an I/O buffering layer with specific semantics and these
semantics aren't already provided, you either have to write one (and
this is really not complicated) or include one whose code you can
modifiy such that it matches your requirements if you want a reliably
working solution which can be used by third-parties with no intent to
modify the seed7 code itself. Otherwise, you're effectively forcing
users of your code to stick with system-provided software that is
known to work with it. This problem is even more severe if the sources
of said system software are not readily available and consequently,
each and every vendor-provided patch that's installed may break some
or all seed7-applications and the only way to determine if this has
happened is retesting all of them every time.

At least in my opinion, a requirement like this means that the
software which requires it may be an interesting toy to play around
with but certainly not something which can or should be used for
serious development.

[Mark]

+1
--
(\__/) M.
(='.'=) If a man stands in a forest and no woman is around
(")_(") is he still wrong?

[thomas...@gmx.at]

On Friday, May 25, 2012 1:27:03 PM UTC+2, Richard Kettlewell wrote:

> Thomas Mertes writes:
> > Does someone here have access to HPUX or any other commercial Unix
> > variant? I have an Open Source project and want to find out if it
> > compiles and works under HPUX or other Unix variants. Several years
> > ago I used HPUX to develop my project, but now I have no access to
> > HPUX. A short time ago I added some stuff, which uses elements from
> > struct FILE. Struct FILE is defined in <stdio.h>. I know this is
> > sommething not considered portable. Therefore I would like to check,
> > if it compiles flawlessly on different operating systems.
>
> The field you want is spelled __cnt on at least one HPUX machine.

Is it really __cnt with 2 underscores before cnt?
I am just asking, because there are implementations
of FILE which use _cnt (with one underscore). For
this case the macro read_buffer_empty is defined as

#define read_buffer_empty(fp) ((fp)->_cnt <= 0)

Does this mean that

#define read_buffer_empty(fp) ((fp)->__cnt <= 0)

will work for HPUX?

> But I
> agree with Rainer; your strategy here is completely wrong and you'd
> better off writing your own IO layer with the semantics you want.

Ok, but I really want to avoid that effort if it is possible.

And I am also hoping that library designes recognize that
the usual FILE interface has NOT all functionality needed.
So maybe the GNU people are motivated to do a GNU extension
and others will copy this feature... :-)

[Rainer Weikusat]

thomas...@gmx.at writes:
> On Friday, May 25, 2012 1:27:03 PM UTC+2, Richard Kettlewell wrote:

[...]

>> But I agree with Rainer; your strategy here is completely wrong and
>> you'd better off writing your own IO layer with the semantics you
>> want.
>
> Ok, but I really want to avoid that effort if it is possible.

Why wouldn't it be possible? The question is really 'do you want your
code to be used', IOW, do you want to provide something which is not
just a 'cleverly implemented' academic toy? If not (as is apparently
the case), there's no problem with this approach (except that you are
decidedly trying to avoid a relatively insignificant one-time
effort in favor of a conceptually neverending porting nightmare for
you and anyone who might use the code nevertheless which is IMHO
stupid).

[thomas...@gmx.at]

On Wednesday, May 30, 2012 11:55:25 PM UTC+2, Rainer Weikusat wrote:

> Thomas Mertes.at writes:
> > On Friday, May 25, 2012 1:27:03 PM UTC+2, Richard Kettlewell wrote:
>
> [...]
>
> >> But I agree with Rainer; your strategy here is completely wrong and
> >> you'd better off writing your own IO layer with the semantics you
> >> want.
> >
> > Ok, but I really want to avoid that effort if it is possible.
>
> Why wouldn't it be possible?

Of cause it is possible to write file buffering. I just want to
avoid the effort.

What is so hard to understand about this.

I KNOW how to write a buffering layer, but i prefer to use the FILE
implementation that comes with the C library, when it is possible to
do so. I do this on purpose. The C library is usually well designed,
well optimized and debugged and takes all corner cases, like
threads, locking, different file types, buffer sizes, different
buffering strategies (line, full and no buffering), and efficient
reading of data blocks into account. All this file buffering
features are needed by the Seed7 runtime library.

I have a lot of other things to do, but I would gladly accept
patches for a buffering module with all the required functionality.

BTW.: Seed7 can be easily ported to a lot of platforms. It is
designed to be portable. Don't tell horror stories about
portability, unless you can provide some evidence.

Tell me about real porting problems and send me a list of
compilation errors, then I will gladly support you to fix them.
I did this in the past for FreeBSD, OS X (32-bit and 64-bit) and
DJGPP. No "porting nightmare" whatsoever.

And finally: I started this thread, because I care about
portability.

Question for Richard Kettlewell or Mark:

Does HPUX really use __cnt (with 2 underlines)?

In that case I could use:

#define read_buffer_empty(fp) ((fp)->__cnt <= 0)

[Rainer Weikusat]

thomas...@gmx.at writes:
> On Wednesday, May 30, 2012 11:55:25 PM UTC+2, Rainer Weikusat wrote:
>> Thomas Mertes.at writes:
>> > On Friday, May 25, 2012 1:27:03 PM UTC+2, Richard Kettlewell wrote:
>>
>> [...]
>>
>> >> But I agree with Rainer; your strategy here is completely wrong and
>> >> you'd better off writing your own IO layer with the semantics you
>> >> want.
>> >
>> > Ok, but I really want to avoid that effort if it is possible.
>>
>> Why wouldn't it be possible?
>
> Of cause it is possible to write file buffering. I just want to
> avoid the effort.

This juxtaposition makes no sense. As I already wrote, if seed7 is
essentially intended to be proof-of-concept style demonstration,
there's no reason why you shouldn't take every conceivable
implementation shortcut.

> What is so hard to understand about this.
>
> I KNOW how to write a buffering layer, but i prefer to use the FILE
> implementation that comes with the C library, when it is possible to
> do so.

It isn't possible *except* if you hijack a sufficiently portable 'FILE
implementation' from a suitable place and include that with your code.

[...]

> BTW.: Seed7 can be easily ported to a lot of platforms. It is
> designed to be portable.

Some parts of it, presumably, except that I feel inclined to take this
statement with a sizeable barrel of salt: Since you quite apparently
don't even understand why 'poking around inside the internal parts of
some kind of "abstract" facility' is a problem *for users of your
code* there's no reason to assume that you aren't doing this
everywhere consciously were you believe that it 'saves work' and
presumably, unconciously all over the place as well.

And there is, as I also already wrote, nothing wrong with
that. It just means that you're implementation isn't fit for practical
use except in very controlled situations.

[thomas...@gmx.at]

On Thursday, May 31, 2012 3:17:38 PM UTC+2, Rainer Weikusat wrote:

> Thomas Mertes writes:
> > I KNOW how to write a buffering layer, but i prefer to use the FILE
> > implementation that comes with the C library, when it is possible to
> > do so.
>
> It isn't possible *except* if you hijack a sufficiently portable 'FILE
> implementation' from a suitable place and include that with your code.

This portable 'FILE implementation' will not fit to external
libraries. A foreign function from an external library will probably
use FILE * parameters from <stdio.h>. Representing files from the
portable 'FILE implementation' as FILE * parameters from <stdio.h>
will probably need much more 'poking around inside the internal
parts of the <stdio.h> FILE facility'. Not every library is open
source and it makes no sense to rewrite every external library,
so that it fits to the portable 'FILE implementation'. There are
definite advantages in using the FILE implementation from <stdio.h>.

Only one experimental file function uses internal information from
the FILE struct. This experimental function is currently only used
in a private test program (which is not released) All other functions
don't use any internal part from the FILE implementation. Before
removing the experimental state of this function I plan to add tests
to the chk... programs, which will check the correct behaviour.
The chk... programs check the correct behaviour of the Seed7
interpreter, compiler and runtime library. Currently the chk...
programs contain 38881 lines of code.

> [...]
>
> > BTW.: Seed7 can be easily ported to a lot of platforms. It is
> > designed to be portable.
>

> Some parts of it, presumably, ...

Seed7 is ported as a whole, not part by part. When it is compiled
there are feature tests, which explore the properties of the C
compiler and its libraries. The code is adjusted with macros to
different platforms.

> except that I feel inclined to take this

> statement with a sizeable barrel of salt: ...

Is is not good for health to consume that much salt.

> Since you quite apparently
> don't even understand

You have no clue what I understand. Please soften your language.

> why 'poking around inside the internal parts of

> some kind of "abstract" facility' ...

"Abstact" facility is exaggerated.
In all classic <stdio.h> headers the FILE struct was not an
abstract facility. It was always defined with all its elements.
This elements and the getc macro were even documented in manuals,
but with the hint, that the elements and the macros were
implementation dependend and that your implementation will probably
use different elements and different macros definitions. Writing
the FILE struct elements in <stdio.h> was absolutely necessary,
since getc was implemented as macro. Nowerdays OO concepts like
abstraction are more familiar, but this does not change history.

> is a problem *for users of your

> code* ...

As I said the code is tested with 38881 lines in test programs.
If you ever tried Seed7 you would know that.

> there's no reason to assume that you aren't doing this
> everywhere consciously were you believe that it 'saves work' and
> presumably, unconciously all over the place as well.

You sound like SCO. You believe that there is something...

> And there is, as I also already wrote, nothing wrong with
> that. It just means that you're implementation isn't fit for practical
> use except in very controlled situations.

The situation is controlled with feature tests before the
compilation starts and with check programs after the
compilation was finished.

[Rainer Weikusat]

thomas...@gmx.at writes:
> In all classic <stdio.h> headers the FILE struct was not an
> abstract facility. It was always defined with all its elements.
> This elements and the getc macro were even documented in manuals,

According to the nice facility available here,

http://www.freebsd.org/docs/man.html

this statement is wrong for UNIX(*) V7, 2.8BSD, 4.3BSD Reno, OSF1
V4.0/Alpha, ULTRIX 4.2 and SunOS 4.1.3.

[Rainer Weikusat]

thomas...@gmx.at writes:
> In all classic <stdio.h> headers the FILE struct was not an
> abstract facility. It was always defined with all its elements.
> This elements and the getc macro were even documented in manuals,

According to the nice facility available here,

http://www.freebsd.org/docs/man.html

this statement is wrong for UNIX(*) V7, 2.8BSD, 4.3BSD Reno, OSF1

V4.0/Alpha, ULTRIX 4.2 and SunOS 4.1.3 (for the getc manpage).

[thomas...@gmx.at]

On Thursday, May 31, 2012 8:11:42 PM UTC+2, Rainer Weikusat wrote:

What about:
K&R "The C programming language" from 1978
chapter 8 "THE UNIX SYSTEM INTERFACE"
subchapter 8.5 "An Implementation of Fopen and Getc"
on page 165: Definition of struct _iobuf, which
defines the type FILE:

typedef struct _iobuf {
char *_ptr; /* next character position */
int _cnt; /* number of characters left */
char *_base; /* location of buffer */
int _flag; /* mode of file access */
int _fd; /* file descriptor */
} FILE;

on page 166: Definition of the macro getc:

#define getc(p) (--(p)->_cnt >= 0 \
? *(p)->_ptr++ & 0377 : _fillbuf(p))

ANSI C version of "The C programming language" from 1988
chapter 8 "The UNIX System Interface"
subchapter 8.5 "An Implementation of Fopen and Getc"
on page 176: Definition of struct _iobuf, which
defines the type FILE:

typedef struct _iobuf {
int cnt; /* character left */
char *ptr; /* next character position */
char *base; /* location of buffer */
int flag; /* mode of file access */
int fd; /* file descriptor */
} FILE;

on page 176: Definition of the macro getc:

define getc(p) (--(p)->cnt >= 0 \
? (unsigned char) *(p)->ptr++ : _fillbuf(p))

[Rainer Weikusat]

thomas...@gmx.at writes:
> On Thursday, May 31, 2012 8:11:42 PM UTC+2, Rainer Weikusat wrote:
>> Thomas Mertes writes:
>> > In all classic <stdio.h> headers the FILE struct was not an
>> > abstract facility. It was always defined with all its elements.
>> > This elements and the getc macro were even documented in manuals,
>>
>> According to the nice facility available here,
>>
>> http://www.freebsd.org/docs/man.html
>>
>> this statement is wrong for UNIX(*) V7, 2.8BSD, 4.3BSD Reno, OSF1
>> V4.0/Alpha, ULTRIX 4.2 and SunOS 4.1.3.
>
> What about:
> K&R "The C programming language" from 1978
> chapter 8 "THE UNIX SYSTEM INTERFACE"

That's not 'a manual' of anything but a textbook supposed to teach the
C programming language.

> subchapter 8.5 "An Implementation of Fopen and Getc"
> on page 165: Definition of struct _iobuf, which
> defines the type FILE:

As such, it contains all kinds of example code. Even the assumption
that the 1978 version contained the actual UNIX(*) source code of that
time is essentially based on nothing, although this seems somewhat
likely.

[James Waldby]

On Wed, 30 May 2012 15:55:58 -0700, thomas.mertes wrote:
> On Wednesday, May 30, 2012 11:55:25 PM UTC+2, Rainer Weikusat wrote:
>> Thomas Mertes.at writes:
>> > On Friday, May 25, 2012 1:27:03 PM UTC+2, Richard Kettlewell wrote:
...
>> >> But I agree with Rainer; your strategy here is completely wrong and
>> >> you'd better off writing your own IO layer with the semantics you
>> >> want.
>> >
>> > Ok, but I really want to avoid that effort if it is possible.
>>
>> Why wouldn't it be possible?
>
> Of cause it is possible to write file buffering. I just want to
> avoid the effort.

...

Thomas, most of your English is correct, but your frequent incorrect
and inappropriate use of "of cause" rather than "of course" is quite
grating.

--
jiw

[thomas...@gmx.at]

Thank you for the hint. I will try to improve my English.
I just checked the Seed7 homepage and it seems that it
does not contain the wrong phrase. But it probably
contains other errors...

Can you do me a favour?
Please do a quick check of the Seed7 homepage for
severe errors, like the one above?

Thanks in advance, for your effort.

[Rainer Weikusat]

thomas...@gmx.at writes:

[...]

> Can you do me a favour?
> Please do a quick check of the Seed7 homepage for
> severe errors, like the one above?

Don't know if you consider this to be a 'severe error' but
Linux, UNIX(*) and Windows are all names and should be capitalized.
Also, the front page seems to be violating the Open Group trademark
usage policy, cf

http://www.unix.org/trademark.html

[thomas...@gmx.at]

On Friday, June 1, 2012 5:02:35 PM UTC+2, Rainer Weikusat wrote:

> Thomas Mertes writes:
>
> [...]
>
> > Can you do me a favour?
> > Please do a quick check of the Seed7 homepage for
> > severe errors, like the one above?
>
> Don't know if you consider this to be a 'severe error' but
> Linux, UNIX(*) and Windows are all names and should be capitalized.

Thank you for the hint.

Some time ago I changed the capitalization of operating
system names. Obviously I forgot this page. The change
will be effective today (2012-06-03), with the new release.

> Also, the front page seems to be violating the Open Group trademark
> usage policy, cf
>
> http://www.unix.org/trademark.html

Thank you again.
Somwhere I read that UNIX(TM) is trademarked, but Unix
can be used as general Name for Unix-like operating
systems. So for the moment I will leave this as Unix,
but I consider the trademark stuff as an open issue.

Can you please, have a look at other parts of the
homepage also?

This would be very helpful.
Thank you in advance, for your effort.

[thomas...@gmx.at]

Am Mittwoch, 23. Mai 2012 11:51:03 UTC+2 schrieb thomas...@gmx.at:
> Hello,

> Does someone here have access to HPUX or any other commercial Unix
> variant?

Thanks to all, who helped with this issue, especially to
Rainer Weikusat, Geoff Clare, Richard Kettlewell and Marc.
Yesterday I released a new version and I mentioned you in the
change log, to honor your effort. The new version is available here:

http://sourceforge.net/projects/seed7/files

When someone has access to HPUX or other "exotic" platforms:
Please try to compile Seed7 and report the result.
Just change to the directory seed7/src and do

make depend
make

when errors occur, please send them to me.
When everything works ok please go to seed7/prg and do

hi chk_all

This should check the hi (Seed7) interpreter and its libraries
(checks for the inputReady function, discussed in this thread are
currently missing, but will be added when the function is considered
mature). Please report when chk_all reports errors.

Concerning inputReady discussed in this thread:
I assume that the FILE element to be checked is __cnt under HPUX.
I was also able to create a function, which does not use an element
from FILE, by making the file descriptor (fd) non-blocking.
Unfortunately when EOF would be the next character the two solutions
poll() and reading non-blocking work different. Poll does not force
the other process to end, so it delivers: No character available.
Reading non-blocking actually reads EOF, so the result is:
A character is available.

So the two solutions don't deliver the same result.
BTW: This happens with pipes and with pty.
Maybe someone has an idea.

[Geoff Clare]

thomas...@gmx.at wrote:

> I was also able to create a function, which does not use an element
> from FILE, by making the file descriptor (fd) non-blocking.
> Unfortunately when EOF would be the next character the two solutions
> poll() and reading non-blocking work different. Poll does not force
> the other process to end, so it delivers: No character available.
> Reading non-blocking actually reads EOF, so the result is:
> A character is available.
>
> So the two solutions don't deliver the same result.
> BTW: This happens with pipes and with pty.
> Maybe someone has an idea.

It's hard to know where the problem lies because your description
suffers from a misconception. There is no "EOF character" in
received input. EOF is a condition/state/event, not a character.
(A common source of this confusion is that there is an "EOF character"
in the terminal settings, but when the terminal driver receives that
character it results in read() returning zero to indicate the EOF
condition.)

For a pipe you will not get an EOF condition unless all writers have
closed the pipe. If the pipe is open for writing but has no data
available for reading, the return value of getc() will be equal to
the macro EOF, but in this case it doesn't mean an EOF condition has
occurred, it means an error has occurred. You can distinguish between
them by checking feof(fp). If feof(fp) is false you can tell which
error occurred by examining errno - if there is no data available it
will be EAGAIN.

For a pty much the same is true but there is an added complication
of which mode the slave side is in. In non-canonical mode there
are MIN and TIME settings which can result in read() returning 0
when O_NONBLOCK is clear. When O_NONBLOCK is set, POSIX says it
"does not specify whether the setting of O_NONBLOCK takes precedence
over MIN or TIME settings". See section 11.1.7 in the XBD volume
of POSIX/SUS for the details.

--
Geoff Clare <net...@gclare.org.uk>

[Nobody]

On Wed, 06 Jun 2012 13:37:40 +0100, Geoff Clare wrote:

> (A common source of this
> confusion is that there is an "EOF character" in the terminal settings,
> but when the terminal driver receives that character it results in read()
> returning zero to indicate the EOF condition.)

Actually, it results in read() returning whatever data is currently in the
buffer; read() will only return 0 if the EOF character is entered when the
input buffer is empty (e.g after a newline or after an EOF).

[Geoff Clare]

Correct. I left out that complication because the OP was already
confused about this stuff. I should probably have included a note
that what I wrote was a simplification.

--
Geoff Clare <net...@gclare.org.uk>