Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not OK: perl v5.7.0 +DEVEL7928 on os2-64int-ld 2.30 (UNINSTALLED) #2917

Closed
p5pRT opened this issue Nov 29, 2000 · 7 comments
Closed

Not OK: perl v5.7.0 +DEVEL7928 on os2-64int-ld 2.30 (UNINSTALLED) #2917

p5pRT opened this issue Nov 29, 2000 · 7 comments

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Nov 29, 2000

Migrated from rt.perl.org#4804 (status was 'resolved')

Searchable as RT4804$

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 29, 2000

From @ysth

Still struggling with -Duseperlio...
Trying to compile with -Dfpostype=off_t to work around the perlio.c
(get|set)pos compilation problems, I get a new error​:

perlio.c​: In function `PerlIOStdio_close'​:
perlio.c​:1455​: `SOL_SOCKET' undeclared (first use in this function)
perlio.c​:1455​: (Each undeclared identifier is reported only once
perlio.c​:1455​: for each function it appears in.)
perlio.c​:1455​: `SO_TYPE' undeclared (first use in this function)

Here's a patch (though you may want to check USE_SOCKS instead)​:

Inline Patch
--- perlio.c.orig	Wed Nov 29 14:50:22 2000
+++ perlio.c	Wed Nov 29 14:54:38 2000
@@ -1449,12 +1449,16 @@
 IV
 PerlIOStdio_close(PerlIO *f)
 {
+#ifdef HAS_SOCKET
  int optval, optlen = sizeof(int);
+#endif
  FILE *stdio = PerlIOSelf(f,PerlIOStdio)->stdio;
- return(
-   (getsockopt(PerlIO_fileno(f), SOL_SOCKET, SO_TYPE, (char *)&optval, &optlen) < 0) ?
-       fclose(stdio) :
-       close(PerlIO_fileno(f)));
+ return
+#ifdef HAS_SOCKET
+   (getsockopt(PerlIO_fileno(f), SOL_SOCKET, SO_TYPE, (char *)&optval, &optlen) >= 0) ?
+       close(PerlIO_fileno(f)) :
+#endif
+       fclose(stdio);
 }
 
 IV
End of Patch.

Then I got stuck on os2.c​:

os2.c​: In function `do_spawn_ve'​:
os2.c​:625​: warning​: assignment from incompatible pointer type
os2.c​:625​: parse error before `_fopen_'
os2.c​:629​: parse error before `_fgets_'
os2.c​:651​: parse error before `_fclose_'
os2.c​:675​: `s1' undeclared (first use in this function)
os2.c​:675​: (Each undeclared identifier is reported only once
os2.c​:675​: for each function it appears in.)
os2.c​:698​: `scr' undeclared (first use in this function)
os2.c​:708​: `file' undeclared (first use in this function)
os2.c​:784​: `err' undeclared (first use in this function)
os2.c​:628​: label `panic_file' used but not defined
os2.c​:572​: label `finish' used but not defined
os2.c​: At top level​:
os2.c​:787​: parse error before `}'
os2.c​:810​: warning​: parameter names (without types) in function declaration
os2.c​:810​: warning​: data definition has no type or storage class
os2.c​:811​: parse error before `2'
os2.c​:811​: warning​: data definition has no type or storage class
os2.c​: In function `my_tmpfile'​:
os2.c​:2139​: parse error before `_fopen_'

I tried changing it to use PerlIO calls but stopped when I found
no fgets replacement. What's up with this?

Perl Info

Flags:
    category=install
    severity=none

Site configuration information for perl v5.7.0:

Configured by sthoenna at Mon Nov 27 13:59:30 PST 2000.

Summary of my perl5 (revision 5.0 version 7 subversion 0) configuration:
  Platform:
    osname=os2, osvers=2.30, archname=os2-64int-ld
    uname='os2 efn.org 2 2.30 i386  '
    config_args='-de -Dprefix=d:/perl -Dusedevel -Duse64bitint -Duselongdouble -Aoptimize=-DDEBUGGING'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=define use64bitall=undef uselongdouble=define
  Compiler:
    cc='gcc', ccflags ='-Zomf -Zmt -DDOSISH -DOS2=2 -DEMBED -I. -D_EMX_CRT_REV_=63',
    optimize='-O2 -fomit-frame-pointer -malign-loops=2 -malign-jumps=2 -malign-functions=2 -s -DDEBUGGING',
    cppflags='-Zomf -Zmt -DDOSISH -DOS2=2 -DEMBED -I. -D_EMX_CRT_REV_=63'
    ccversion='', gccversion='2.8.1', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long long', ivsize=8, nvtype='long double', nvsize=12, Off_t='off_t', lseeksize=4
    alignbytes=4, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags ='-Zexe -Zomf -Zmt -Zcrtdll -Zstack 32000'
    libpth=d:/emx/lib d:/emx/lib/mt
    libs=-lsocket -lm -lbsd
    perllibs=-lsocket -lm -lbsd
    libc=d:/emx/lib/mt/c_import.lib, so=dll, useshrplib=true, libperl=libperl.lib
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-Zdll', lddlflags='-Zdll -Zomf -Zmt -Zcrtdll -s'

Locally applied patches:
    DEVEL7928


@INC for perl v5.7.0:
    lib
    d:/perl/lib/5.7.0/os2-64int-ld
    d:/perl/lib/5.7.0
    d:/perl/lib/site_perl/5.7.0/os2-64int-ld
    d:/perl/lib/site_perl/5.7.0
    d:/perl/lib/site_perl
    .


Environment for perl v5.7.0:
    HOME=d:\home\sthoenna
    LANG=en_us
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR=sthoenna
    PATH=d:\bin;C:\OS2;d:\perl\bin;C:\OS2\SYSTEM;C:\OS2\INSTALL;C:\;C:\OS2\MDOS;C:\OS2\APPS;C:\MMOS2;d:\os2apps\util;d:\DOSAPPS\UTIL;c:\sio;D:\WINDOWS;d:\pdksh;d:\emx\bin;d:\emacs\19.33\bin;d:\ispell
    PERL_BADLANG (unset)
    PERL_SH_DIR=d:\BIN
    SHELL (unset)


@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 30, 2000

From [Unknown Contact. See original ticket]

<sthoenna@​efn.org> writes​:

This is a build failure report for perl from sthoenna@​efn.org,
generated with the help of perlbug 1.33 running under perl v5.7.0.

-----------------------------------------------------------------
[Please enter your report here]

Still struggling with -Duseperlio...
Trying to compile with -Dfpostype=off_t to work around the perlio.c
(get|set)pos compilation problems, I get a new error​:

perlio.c​: In function `PerlIOStdio_close'​:
perlio.c​:1455​: `SOL_SOCKET' undeclared (first use in this function)
perlio.c​:1455​: (Each undeclared identifier is reported only once
perlio.c​:1455​: for each function it appears in.)
perlio.c​:1455​: `SO_TYPE' undeclared (first use in this function)

I hope that that horrible SOCKS hackery has gone in recent snapshot.

Then I got stuck on os2.c​:

Which is where you should get stuck - and I do a bit as well.
I expect os2.c (like Win32 used to and vms.c still does) has implcit assumptions
that PerlIO "is" a FILE * and trys to use system's stdio on it.
It cannot do that any more.

The 1st step is

#define PERLIO_NOT_STDIO 0

at the top before including <perl.h>.
That magic allows file to see both stdio/FILE * and perlio/PerlIO *.
Then on a case-by-case basis try and figure out what the code really
wants.

os2.c​: In function `do_spawn_ve'​:
os2.c​:625​: warning​: assignment from incompatible pointer type

Here it is just taking a quick look at the file. So it could
either continue to use FILE * or switch to PerlIO *.

os2.c​:625​: parse error before `_fopen_'
os2.c​:629​: parse error before `_fgets_'
os2.c​:651​: parse error before `_fclose_'
os2.c​:675​: `s1' undeclared (first use in this function)
os2.c​:675​: (Each undeclared identifier is reported only once
os2.c​:675​: for each function it appears in.)
os2.c​:698​: `scr' undeclared (first use in this function)
os2.c​:708​: `file' undeclared (first use in this function)
os2.c​:784​: `err' undeclared (first use in this function)
os2.c​:628​: label `panic_file' used but not defined
os2.c​:572​: label `finish' used but not defined
os2.c​: At top level​:
os2.c​:787​: parse error before `}'
os2.c​:810​: warning​: parameter names (without types) in function declaration
os2.c​:810​: warning​: data definition has no type or storage class
os2.c​:811​: parse error before `2'
os2.c​:811​: warning​: data definition has no type or storage class
os2.c​: In function `my_tmpfile'​:

os2.c​:2139​: parse error before `_fopen_'

One needs to follow PerlIO_tmpfile() through perlio.h and iperlsys.h
etc. I suspect though that this is just a question of the
#define above so you can _see_ fopen().

my_tmpfile() is either not called or

I tried changing it to use PerlIO calls but stopped when I found
no fgets replacement. What's up with this?

There is a Perl_sv_gets() which is similar but uses $/ rather than '\n'
and reads to an SV *.
Or just PerlIO_read() a the whole arrray and then look for '\n' your
self.

So - try the #define - it may be sufficient.

[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags​:
category=install
severity=none
---
Site configuration information for perl v5.7.0​:

Configured by sthoenna at Mon Nov 27 13​:59​:30 PST 2000.

Summary of my perl5 (revision 5.0 version 7 subversion 0) configuration​:
Platform​:
osname=os2, osvers=2.30, archname=os2-64int-ld
uname='os2 efn.org 2 2.30 i386 '
config_args='-de -Dprefix=d​:/perl -Dusedevel -Duse64bitint -Duselongdouble -Aoptimize=-DDEBUGGING'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=undef uselongdouble=define
Compiler​:
cc='gcc', ccflags ='-Zomf -Zmt -DDOSISH -DOS2=2 -DEMBED -I. -D_EMX_CRT_REV_=63',
optimize='-O2 -fomit-frame-pointer -malign-loops=2 -malign-jumps=2 -malign-functions=2 -s -DDEBUGGING',
cppflags='-Zomf -Zmt -DDOSISH -DOS2=2 -DEMBED -I. -D_EMX_CRT_REV_=63'
ccversion='', gccversion='2.8.1', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long long', ivsize=8, nvtype='long double', nvsize=12, Off_t='off_t', lseeksize=4
alignbytes=4, usemymalloc=y, prototype=define
Linker and Libraries​:
ld='gcc', ldflags ='-Zexe -Zomf -Zmt -Zcrtdll -Zstack 32000'
libpth=d​:/emx/lib d​:/emx/lib/mt
libs=-lsocket -lm -lbsd
perllibs=-lsocket -lm -lbsd
libc=d​:/emx/lib/mt/c_import.lib, so=dll, useshrplib=true, libperl=libperl.lib
Dynamic Linking​:
dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-Zdll', lddlflags='-Zdll -Zomf -Zmt -Zcrtdll -s'

Locally applied patches​:
DEVEL7928

---
@​INC for perl v5.7.0​:
lib
d​:/perl/lib/5.7.0/os2-64int-ld
d​:/perl/lib/5.7.0
d​:/perl/lib/site_perl/5.7.0/os2-64int-ld
d​:/perl/lib/site_perl/5.7.0
d​:/perl/lib/site_perl
.

---
Environment for perl v5.7.0​:
HOME=d​:\home\sthoenna
LANG=en_us
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR=sthoenna
PATH=d​:\bin;C​:\OS2;d​:\perl\bin;C​:\OS2\SYSTEM;C​:\OS2\INSTALL;C​:\;C​:\OS2\MDOS;C​:\OS2\APPS;C​:\MMOS2;d​:\os2apps\util;d​:\DOSAPPS\UTIL;c​:\sio;D​:\WINDOWS;d​:\pdksh;d​:\emx\bin;d​:\emacs\19.33\bin;d​:\ispell
PERL_BADLANG (unset)
PERL_SH_DIR=d​:\BIN
SHELL (unset)

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 30, 2000

From @ysth

Nick Ing-Simmons <nik@​tiuk.ti.com> wrote​:

<sthoenna@​efn.org> writes​:

This is a build failure report for perl from sthoenna@​efn.org,
generated with the help of perlbug 1.33 running under perl v5.7.0.

-----------------------------------------------------------------
[Please enter your report here]

Still struggling with -Duseperlio...
Trying to compile with -Dfpostype=off_t to work around the perlio.c
(get|set)pos compilation problems, I get a new error​:

perlio.c​: In function `PerlIOStdio_close'​:
perlio.c​:1455​: `SOL_SOCKET' undeclared (first use in this function)
perlio.c​:1455​: (Each undeclared identifier is reported only once
perlio.c​:1455​: for each function it appears in.)
perlio.c​:1455​: `SO_TYPE' undeclared (first use in this function)

I hope that that horrible SOCKS hackery has gone in recent snapshot.

It just got added in 7855 and modified in 7922. 7930 was Wednesday's snapshot.

Then I got stuck on os2.c​:

Patch (for now--I need to look at the my_tmpfile situation more)​:

Inline Patch
--- os2/os2.c.orig	Sun Oct 22 12:37:54 2000
+++ os2/os2.c	Thu Nov 30 11:45:22 2000
@@ -21,6 +21,7 @@
 #include <process.h>
 #include <fcntl.h>
 
+#define PERLIO_NOT_STDIO 0
 #include "EXTERN.h"
 #include "perl.h"
 
@@ -605,8 +606,9 @@
 		char *scr = find_script(PL_Argv[0], TRUE, NULL, 0);
 
 		if (scr) {
-		    FILE *file;
-		    char *s = 0, *s1;
+		    PerlIO *file;
+                    SSize_t rd;
+		    char *s = 0, *s1, *s2;
 		    int l;
 
                     l = strlen(scr);
@@ -622,14 +624,18 @@
                     Safefree(scr);
                     scr = scrbuf;
 
-		    file = fopen(scr, "r");
+		    file = PerlIO_open(scr, "r");
 		    PL_Argv[0] = scr;
 		    if (!file)
 			goto panic_file;
-		    if (!fgets(buf, sizeof buf, file)) { /* Empty... */
 
+		    rd = PerlIO_read(file, buf, sizeof buf-1);
+		    buf[rd]='\0';
+		    if ((s2 = strchr(buf, '\n')) != NULL) *++s2 = '\0';
+
+		    if (!rd) { /* Empty... */
 			buf[0] = 0;
-			fclose(file);
+			PerlIO_close(file);
 			/* Special case: maybe from -Zexe build, so
 			   there is an executable around (contrary to
 			   documentation, DosQueryAppType sometimes (?)
@@ -648,7 +654,7 @@
 			} else
 			    goto longbuf;
 		    }
-		    if (fclose(file) != 0) { /* Failure */
+		    if (PerlIO_close(file) != 0) { /* Failure */
 		      panic_file:
 			Perl_warner(aTHX_ WARN_EXEC, "Error reading \"%s\": %s", 
 			     scr, Strerror(errno));
End of Patch.

Which is where you should get stuck - and I do a bit as well.
I expect os2.c (like Win32 used to and vms.c still does) has implcit assumptions
that PerlIO "is" a FILE * and trys to use system's stdio on it.
It cannot do that any more.

The 1st step is

#define PERLIO_NOT_STDIO 0

Thanks. I had looked at perlio.h but for some reason I was trying to
figure out a way to make it take the fakesdio.h path and didn't find
one :(.

On to the next problem​:

[D​:\perl-current]miniperl -we"print qq​:\n​:"|od -tc
0000000 \r \r \n
0000003

Suggestions for where to look for where the extra \r comes from?

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 1, 2000

From [Unknown Contact. See original ticket]

Yitzchak Scott-Thoennes <sthoenna@​efn.org> writes​:

On to the next problem​:

[D​:\perl-current]miniperl -we"print qq​:\n​:"|od -tc
0000000 \r \r \n
0000003

Suggestions for where to look for where the extra \r comes from?

Okay, now we are in really messy bit.
With USE_PERLIO the intent is to open the "numeric" file handle in
binary mode, and do CRLF processing in a "crlf" layer.

For standard handles (e.g. stdout above) which are already open then
PerlIOBuf_fdopen() is supposed to call PerlLIO_setmode() to
make them binary. It is possible that such things don't work everywhere.
It is also possible that the PerlLIO_setmode() abstraction is not
setup for OS/2 the way it is for Win32 - i.e. you may have a special
"binmode()" rather than Win32's "setmode()".

One other thing - all these tricks are gated by O_BINARY != O_TEXT
test. UNIX has them both 0, Win32 has them both != 0 and != each other.

The other possibility is that you are getting stdio layer and I have
not looked into that as closely. (I have not decided yet whether
to let stdio do its own textmode processing, or force a 'b' into
open string (e.g. "rb") and add crlf layer on top.) Currently the
code just lets it do its own thing.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 1, 2000

From @ysth

Nick Ing-Simmons <nik@​tiuk.ti.com> wrote​:

Yitzchak Scott-Thoennes <sthoenna@​efn.org> writes​:

On to the next problem​:

[D​:\perl-current]miniperl -we"print qq​:\n​:"|od -tc
0000000 \r \r \n
0000003

Suggestions for where to look for where the extra \r comes from?

Okay, now we are in really messy bit.
With USE_PERLIO the intent is to open the "numeric" file handle in
binary mode, and do CRLF processing in a "crlf" layer.

For standard handles (e.g. stdout above) which are already open then
PerlIOBuf_fdopen() is supposed to call PerlLIO_setmode() to
make them binary. It is possible that such things don't work everywhere.
It is also possible that the PerlLIO_setmode() abstraction is not
setup for OS/2 the way it is for Win32 - i.e. you may have a special
"binmode()" rather than Win32's "setmode()".

I have setmode, in a couple flavours​:


#include <stdio.h> [emx]

int _fsetmode (FILE *stream, const char *mode);

  Change the text/binary mode of a stream. MODE must point either
  to "b" or to "t". _fsetmode() is usually used to switch stdin or
  stdout to binary mode.

  Return value​:

  0 success

  -1 error

  Restrictions​:

  Do not call _fsetmode() on a stream with non-empty buffer. If
  there is data in the buffer (either data to be read or data to be
  written), call fflush() before _fsetmode(). Otherwise, future
  behavior of the stream will be undefined.

  See also​: fopen()


#include <io.h> [PC]
#include <fcntl.h>

int setmode (int handle, int mode);

  Change the text/binary mode of a file handle. MODE must be either
  O_BINARY or O_TEXT.

  Note​: Use _fsetmode() to change the mode of a stream.

  Return value​:

  If there's an error, setmode() returns -1 and sets errno to EBADF
  or EINVAL otherwise setmode() returns the previous mode, that is,
  O_BINARY or O_TEXT.

  See also​: _fsetmode(), open()


#include <stdio.h> [UNIX]

FILE *fdopen (int handle, const char *mode);

  Create a stream for the file handle HANDLE. The flags in the mode
  string pointed to by MODE should match the mode used for opening
  the file handle HANDLE. If b or t is used in the mode string, the
  handle will be changed using setmode() to O_BINARY or O_TEXT mode,
  respectively. If neither b nor t is used, the translation mode is
  not changed. You should not rely on this behavior​: always specify
  the desired translation mode.

  Return value​:

  fdopen() returns a new stream. On error, fdopen() returns NULL.

  See also​: fopen(), open()


One other thing - all these tricks are gated by O_BINARY != O_TEXT
test. UNIX has them both 0, Win32 has them both != 0 and != each other.

[D​:\emx\include]fgrep -e O_TEXT -e O_BINARY sys/fcntl.h
#define O_TEXT 0x10
#define O_BINARY 0x0100

The other possibility is that you are getting stdio layer and I have

How do I ask for no stdio layer?

not looked into that as closely. (I have not decided yet whether
to let stdio do its own textmode processing, or force a 'b' into
open string (e.g. "rb") and add crlf layer on top.) Currently the
code just lets it do its own thing.

Seems like if XS is to be allowed to expect PerlIO_open (or fopen
#define'd to PerlIO_open) to default to textmode, you can't default to
"b" at that level. But perl-level open should ask for binary mode and
add a crlf layer?? And probably similarly with switching the std*
handles/streams to binmode at startup and adding a crlf layer. Also
note the following (emxlib.doc​:)
- Initially, sockets are in binary mode. Use setmode() to switch to
  text mode. Text mode applies to read() and write(), only. recv()
  and send() always use binary mode.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 2, 2000

From [Unknown Contact. See original ticket]

Yitzchak Scott-Thoennes <sthoenna@​efn.org> writes​:

Nick Ing-Simmons <nik@​tiuk.ti.com> wrote​:

Okay, now we are in really messy bit.
With USE_PERLIO the intent is to open the "numeric" file handle in
binary mode, and do CRLF processing in a "crlf" layer.

For standard handles (e.g. stdout above) which are already open then
PerlIOBuf_fdopen() is supposed to call PerlLIO_setmode() to
make them binary. It is possible that such things don't work everywhere.
It is also possible that the PerlLIO_setmode() abstraction is not
setup for OS/2 the way it is for Win32 - i.e. you may have a special
"binmode()" rather than Win32's "setmode()".

I have setmode, in a couple flavours​:

------------------------------------------------------------------------------
#include <stdio.h> [emx]

int _fsetmode (FILE *stream, const char *mode);

We don't need that one (yet).

#include <io.h> [PC]
#include <fcntl.h>

int setmode (int handle, int mode);

Change the text/binary mode of a file handle. MODE must be either
O_BINARY or O_TEXT.

Note​: Use _fsetmode() to change the mode of a stream.

Return value​:

If there's an error, setmode() returns -1 and sets errno to EBADF
or EINVAL otherwise setmode() returns the previous mode, that is,
O_BINARY or O_TEXT.

That is the one we want.

One other thing - all these tricks are gated by O_BINARY != O_TEXT
test. UNIX has them both 0, Win32 has them both != 0 and != each other.

[D​:\emx\include]fgrep -e O_TEXT -e O_BINARY sys/fcntl.h
#define O_TEXT 0x10
#define O_BINARY 0x0100

The other possibility is that you are getting stdio layer and I have

How do I ask for no stdio layer?

No stdio should be the default with O_TEXT and O_BINARY like that​:

perlio.c has​:

  if (O_BINARY != O_TEXT)
  {
  av_push(PerlIO_layer_av,SvREFCNT_inc(PerlIO_find_layer(PerlIO_crlf.name,0)));
  }
  else
  {
  if (PerlIO_stdio.Set_ptrcnt)
  {
  av_push(PerlIO_layer_av,SvREFCNT_inc(PerlIO_find_layer(PerlIO_stdio.name,0)));
  }

Seems like if XS is to be allowed to expect PerlIO_open (or fopen
#define'd to PerlIO_open) to default to textmode, you can't default to
"b" at that level. But perl-level open should ask for binary mode and
add a crlf layer??

Exactly.

nd probably similarly with switching the std*
handles/streams to binmode at startup and adding a crlf layer. Also
note the following (emxlib.doc​:)
- Initially, sockets are in binary mode. Use setmode() to switch to
text mode. Text mode applies to read() and write(), only. recv()
and send() always use binary mode.

Seems like what you have is basically the same as Win32 (as I might expect).
So the question is why this​:

PerlIO *
PerlIOBuf_fdopen(PerlIO_funcs *self, int fd, const char *mode)
{
PerlIO_funcs *tab = PerlIO_default_btm();
int init = 0;
PerlIO *f;
if (*mode == 'I')
  {
  init = 1;
  mode++;
  }
#if O_BINARY != O_TEXT
/* do something about failing setmode()? --jhi */
PerlLIO_setmode(fd, O_BINARY);
#endif

Is not doing the right thing.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 3, 2000

From @ysth

Nick Ing-Simmons <nick@​ing-simmons.net> wrote​:

So the question is why this​:

PerlIO *
PerlIOBuf_fdopen(PerlIO_funcs *self, int fd, const char *mode)
{
PerlIO_funcs *tab = PerlIO_default_btm();
int init = 0;
PerlIO *f;
if (*mode == 'I')
{
init = 1;
mode++;
}
#if O_BINARY != O_TEXT
/* do something about failing setmode()? --jhi */
PerlLIO_setmode(fd, O_BINARY);
#endif

Is not doing the right thing.

At this point, O_BINARY != O_TEXT, but in iperlsys.h these are not yet
defined so PerlLIO_setmode is defined to 0. It seems perl.h includes
iperlsys.h earlier for OS2 than for other os's (maybe so os2ish.h can
redefine things??).

One fix would be to remove the define to 0. In the sources I have,
PerlLIO_setmode seems to only be used in ifdef __CYGWIN__, WIN32, or
some DOSISH. (Or O_BINARY != O_TEXT, of course).

Inline Patch
--- iperlsys.h.orig	Wed Nov 29 14:13:58 2000
+++ iperlsys.h	Sat Dec  2 23:51:56 2000
@@ -667,12 +667,7 @@
 #define PerlLIO_open3(file, flag, perm)	open((file), (flag), (perm))
 #define PerlLIO_read(fd, buf, count)	read((fd), (buf), (count))
 #define PerlLIO_rename(old, new)	rename((old), (new))
-#if O_BINARY != O_TEXT
 #define PerlLIO_setmode(fd, mode)	setmode((fd), (mode))
-#else
-/* Until we have a "host" on UNIX to supply a stub #define it out */
-#define PerlLIO_setmode(fd, mode)	0
-#endif
 #define PerlLIO_tmpnam(str)		tmpnam((str))
 #define PerlLIO_umask(mode)		umask((mode))
 #define PerlLIO_unlink(file)		unlink((file))
End of Patch.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.