Xref:	news-dnh.mv.net comp.os.msdos.djgpp:1808
Path:	news-dnh.mv.net!mv!news.sprintlink.net!in2.uu.net!EU.net!i2unix!news.mclink.it!news
From:	mc5686 AT mclink DOT it (Mauro Condarelli)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: BUG IN V2??
Date:	Sun, 27 Aug 1995 22:32:03 GMT
Organization:	MC-link The World On Line
Lines:	92
References:	<DDIqou DOT Jtz AT jade DOT mv DOT net>
Nntp-Posting-Host:	192.106.166.228
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway:	from newsgroup comp.os.msdos.djgpp

Bora Ertung <BERTUNG AT gab DOT unt DOT edu> wrote:

>Date sent:      Mon, 14 Aug 95 15:18 MDT
>From:           mat AT ardi DOT com (Mat Hostetter)
>To:             bertung AT gab DOT unt DOT edu (Bora Ertung )
>Subject:        Re: BUG IN V2??

>>>>>> "Bora" == Bora Ertung <bertung AT gab DOT unt DOT edu> writes:

>    Bora> wowww..It is not suppose to be a bug at all. Because it
>    Bora> works fine with gcc for unix. But, 'fopen' may return 'null'
>    Bora> if 'filename' is 'null' instead of saying 'Abort!' because
>    Bora> of the 'null' filename.  And of course it is pretty logical
>    Bora> to catch null pointer assingments.  But, It was working with
>    Bora> official version of the djgpp.May be I am just dreaming.

>fopen(NULL, "r") is a programming error, period. 
>                                         ^^^^^^^

>-Mat

>I wasnt abnactious in my posting. But lemme try to tell why I thougth
>it could be a bug for fopen. First of all this is not a programming 
>error ,but you look so high about saying that. fopen is a library
>function , is not a keyword like (for, while, etc.) so anything 
>that you do with it could not be a programming error.It could be a 
>function call error. Second, I could pass NULL to a pointer if I want. 
>If function denies that this is not my problem, this is the function's 
>problem. I could assign pointers as NULL in a function argument. 
>Function may not act that NULL is an unexpected argument input. All 
>commercial compilers and gcc for unix and also djgpp official accepts 
>fopen(NULL,"r"). 
>      ^^^^ you know(?) this is a pointer like FILE *something;
>and you said that something=NULL is a programming error :).

>P.S. If you dont know the answer quite well, better not try to answer
>it. I understand the egos of human nature about being so high to
>answer anything in his so called knowledge about it. NO OFFENCE.
I tend to agree with you (even if i'm not sur i fully understood your prose).
The technical problem is that there is no error checking (for NULL filename pointer) right
down to the _put_path2() function, which is the one which transfers the filename from
protected to real mode memory.  There the check simply calls abort() (and i think it's too
late to try recovery there).
I think that said error condition should be checked in the lowest possible level which
still returns an error code, i.e. in the _open()/_creat() functions. 
Doing error checking at a higher level leads to useless code duplication.

==================================================== --- patch follows ...
diff -ur E:\DJGPP\SRC\LIBC\DOS\IO/_creat.c ./_creat.c
--- E:\DJGPP\SRC\LIBC\DOS\IO/_creat.c   Sun May 28 02:41:36 1995
+++ ./_creat.c  Sun Aug 27 16:42:08 1995
@@ -12,6 +12,11 @@
 {
   __dpmi_regs r;

+  if (!filename)
+  {
+    errno = EINVAL;
+    return -1;
+  }
   _put_path(filename);
   r.h.ah = 0x3c;
   r.x.cx = attrib;
diff -ur E:\DJGPP\SRC\LIBC\DOS\IO/_open.c ./_open.c
--- E:\DJGPP\SRC\LIBC\DOS\IO/_open.c    Sun May 28 02:41:30 1995
+++ ./_open.c   Sun Aug 27 16:42:08 1995
@@ -13,6 +13,11 @@
 {
   __dpmi_regs r;

+  if (!filename)
+  {
+    errno = EINVAL;
+    return -1;
+  }
   _put_path(filename);
   r.h.ah = 0x3d;
   r.h.al = oflag;
==================================================== ... patch end -------

IMHO Library functions should always try to protect themselves from user foolishness and
give meaningful (???) errors.
Aborting should be last resource when we've gone too far to undo.
I mean: it is appropriate to call abort() in _put_path2(), just as a failsafe, but if
_put_path2() is called from a lib function, we should guarentee args are meaningful.

>Bora Ertung
>UNT advanced visualization and computation lab.

Best Regards
Mauro Condarelli (mc5686 AT mclink DOT it)

- Raw text -