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: 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 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 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)