Re: programi parsing question

[Phlip]

Scott Lurndal wrote:

>if((fd = open(_PATH_UTMP , O_RDONLY)) < 0)

The open system call is defined to return '-1' on failure, not any
negative number. So the above check is incorrect. This can
cause problems with mmap, lseek and other system calls whose return
values, if declared or cast as signed, while legal are negative.

mmap() should always be checked against MAP_FAILED, and lseek return
should always be compared with the expected value (i.e. the offset
arg for SEEK_SET, and the expected offset for the other SEEK_* variants).

Would it also cause a problem if your file descriptors go "around the horn", and
exceed some platform-specific limit, such as 0x80000000? They would "go
negative" when expressed as signed integers...

It's good practice to always test for the defined return code
(which in most cases is -1, not < 0).

Does some relatively standard .h file define a good constant there?

--
Phlip

[fjblurt]

[Followups to c.u.p since this subthread is getting Unix-specific]

On Aug 6, 8:08 pm, Phlip <phlip2...@gmai l.comwrote:

Scott Lurndal wrote:

if((fd = open(_PATH_UTMP , O_RDONLY)) < 0)

The open system call is defined to return '-1' on failure, not any
negative number. So the above check is incorrect. This can
cause problems with mmap, lseek and other system calls whose return
values, if declared or cast as signed, while legal are negative.

mmap() should always be checked against MAP_FAILED, and lseek return
should always be compared with the expected value (i.e. the offset
arg for SEEK_SET, and the expected offset for the other SEEK_* variants).

Would it also cause a problem if your file descriptors go "around the horn", and
exceed some platform-specific limit, such as 0x80000000? They would "go
negative" when expressed as signed integers...

That's guaranteed not to happen. A file descriptor is always a non-
negative integer. So a 32-bit machine wouldn't be allowed to have
more than 2^31 open file descriptors.

So for 'open' in particular, testing for < 0 is the same as testing
for -1, since it promises never to return any other negative value.
As Scott correctly points out, though, there are other functions for
which this is not the case, and so it can be argued it's better to
form the habit of checking for the "error" value (usually -1, but not
always) specifically.

On the other hand, though, testing for < 0 is rather idiomatic. And
another common convention (though not for Unix system calls) is for a
function to be able to return any of several negative values on error,
in which case you must test for < 0. It is common for kernels to use
this convention, because they are inherently multi-threaded and can't
conveniently use something like errno. The case where the return
value is an address can complicate this approach. I believe the Linux
kernel dealt with this issue by guaranteeing that the highest page of
the address space would never be mapped, so that the values -1 through
-4096 could be used for error codes without fear of conflicting with
addresses.

It's good practice to always test for the defined return code
(which in most cases is -1, not < 0).

Does some relatively standard .h file define a good constant there?

I don't believe so.

[CBFalconer]

Phlip wrote:

Scott Lurndal wrote:

>>if((fd = open(_PATH_UTMP , O_RDONLY)) < 0)

.... snip ...

>

>It's good practice to always test for the defined return code
(which in most cases is -1, not < 0).

Does some relatively standard .h file define a good constant there?

Please don't delete attributions for quoted material.

No standard .h file describes 'open', because open is not a
standard C defined routine. This does not apply to fopen, which
opens a FILE*.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[vippstar]

On Aug 7, 7:10 am, CBFalconer <cbfalco...@yah oo.comwrote:

Phlip wrote:

Scott Lurndal wrote:

>if((fd = open(_PATH_UTMP , O_RDONLY)) < 0)

... snip ...

It's good practice to always test for the defined return code
(which in most cases is -1, not < 0).

Does some relatively standard .h file define a good constant there?

Please don't delete attributions for quoted material.

No standard .h file describes 'open', because open is not a
standard C defined routine. This does not apply to fopen, which
opens a FILE*.

Also note that _PATH_UTMP is an invalid identifier in standard C,
since it's reserved for the implementation.

[santosh]

vi******@gmail. com wrote:

On Aug 7, 7:10 am, CBFalconer <cbfalco...@yah oo.comwrote:

>Phlip wrote:

Scott Lurndal wrote:

>>if((fd = open(_PATH_UTMP , O_RDONLY)) < 0)

... snip ...

>It's good practice to always test for the defined return code
(which in most cases is -1, not < 0).

Does some relatively standard .h file define a good constant there?

Please don't delete attributions for quoted material.

No standard .h file describes 'open', because open is not a
standard C defined routine. This does not apply to fopen, which
opens a FILE*.

Also note that _PATH_UTMP is an invalid identifier in standard C,
since it's reserved for the implementation.

But the code need not have defined _PATH_UTMP. It could be just using
it.

[Keith Thompson]

vi******@gmail. com writes:

On Aug 7, 7:10 am, CBFalconer <cbfalco...@yah oo.comwrote:

>Phlip wrote:

Scott Lurndal wrote:

>>if((fd = open(_PATH_UTMP , O_RDONLY)) < 0)

... snip ...

>It's good practice to always test for the defined return code
(which in most cases is -1, not < 0).

Does some relatively standard .h file define a good constant there?

Please don't delete attributions for quoted material.

No standard .h file describes 'open', because open is not a
standard C defined routine. This does not apply to fopen, which
opens a FILE*.

Also note that _PATH_UTMP is an invalid identifier in standard C,
since it's reserved for the implementation.

No and yes, respectively. As it happens, _PATH_UTMP is defined by the
implementation (in one of the non-C-standard headers included by the
code we're discussing).

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Rainer Weikusat]

CBFalconer <cb********@yah oo.comwrites:

Phlip wrote:

>Scott Lurndal wrote:

>>>if((fd = open(_PATH_UTMP , O_RDONLY)) < 0)

... snip ...

>>

>>It's good practice to always test for the defined return code
(which in most cases is -1, not < 0).

Does some relatively standard .h file define a good constant there?

Please don't delete attributions for quoted material.

No standard .h file describes 'open', because open is not a
standard C defined routine.

That should have been 'no standardized C-header' (the C-standard does
not require that 'a header' corresponds with 'a file') The IEEE Std
1003.1 defined header <fcntl.his supposed to contain a prototype for
open.

[Phlip]

CBFalconer wrote:

Please don't delete attributions for quoted material.

If they are not important to understand one post, alone, they are still
accessible in modern newsreaders' threading systems. Nobody is stealing anyone's
verbiage.

[Phlip]

vi******@gmail. com wrote:

Also note that _PATH_UTMP is an invalid identifier in standard C,
since it's reserved for the implementation.

Yet open() _is_ the implementation. It's just not (apparently) in the narrowest
C Standard.

[vippstar]

On Aug 7, 3:01 pm, Phlip <phlip2...@gmai l.comwrote:

vipps...@gmail. com wrote:

Also note that _PATH_UTMP is an invalid identifier in standard C,
since it's reserved for the implementation.

Yet open() _is_ the implementation. It's just not (apparently) in the narrowest
C Standard.

open is the implementation? What are you trying to say?
open is POSIX, it was in older UNIX systems and it's mentioned in K&R,
but it's NOT mentioned or defined in the C standard.