programi parsing question - Unix

This is a discussion on programi parsing question - Unix ; On Aug 6, 5:49 am, CBFalconer wrote: > santosh wrote: > > CBFalconer wrote: > >> fjbl...@yahoo.com wrote: > > >>> void fooB(void) { > >>> int fd = open(...); > >>> if (fd > >>> fail(); > >>> } ...

+ Reply to Thread
Page 4 of 6 FirstFirst ... 2 3 4 5 6 LastLast
Results 61 to 80 of 113

Thread: programi parsing question

  1. Re: programi parsing question

    On Aug 6, 5:49 am, CBFalconer wrote:
    > santosh wrote:
    > > CBFalconer wrote:
    > >> fjbl...@yahoo.com wrote:

    >
    > >>> void fooB(void) {
    > >>> int fd = open(...);
    > >>> if (fd < 0) {
    > >>> fail();
    > >>> }
    > >>> }

    >
    > >> Considering the crosspost, I won't complain about using the
    > >> non-standard open in place of fopen. However it is inappropriate
    > >> on comp.programming.

    >
    > > You surely mean comp.lang.c?

    >
    > No. My last sentence referred to the subject, not the open. My
    > fault for failing to be sufficiently specific. The question about
    > formatting was relevant on c.l.c.


    Insofar as this is a discussion about programming style, which applies
    to any language which allows variables to be initialized, it seemed to
    me that it was still on-topic for comp.programming. I agree that the
    behavior of historical versions of C is not.

    Non-c.u.p readers worried about the `open' function may read it as an
    arbitrary function returning `int', which has significant side
    effects, and for which a negative return value indicates some
    unspecified sort of "failure". The choice of 'fd' for the variable
    holding its return value is likewise an arbitrary choice. Any
    similarity to actual functions, living or dead, is purely
    coincidental.

  2. Re: programi parsing question

    fjblurt@yahoo.com wrote:

    > On Aug 6, 5:49 am, CBFalconer wrote:
    >> santosh wrote:
    >> > CBFalconer wrote:
    >> >> fjbl...@yahoo.com wrote:

    >>
    >> >>> void fooB(void) {
    >> >>> int fd = open(...);
    >> >>> if (fd < 0) {
    >> >>> fail();
    >> >>> }
    >> >>> }




    > Non-c.u.p readers worried about the `open' function may read it as an
    > arbitrary function returning `int', which has significant side
    > effects, [ ... ]


    Since these side effects have not been specified, nor are derivable from
    anything in the C Standard, the function effectively invokes undefined
    behaviour, and there is very little that can be said about the program,
    from that point onwards. Therefore the previous "non-portable" verdict
    now becomes "undefined" and thus, "no comment". :-)




  3. Re: programi parsing question

    santosh writes:
    > fjblurt@yahoo.com wrote:
    >
    >> On Aug 6, 5:49 am, CBFalconer wrote:
    >>> santosh wrote:
    >>> > CBFalconer wrote:
    >>> >> fjbl...@yahoo.com wrote:
    >>>
    >>> >>> void fooB(void) {
    >>> >>> int fd = open(...);
    >>> >>> if (fd < 0) {
    >>> >>> fail();
    >>> >>> }
    >>> >>> }

    >
    >
    >
    >> Non-c.u.p readers worried about the `open' function may read it as an
    >> arbitrary function returning `int', which has significant side
    >> effects, [ ... ]

    >
    > Since these side effects have not been specified, nor are derivable from
    > anything in the C Standard, the function effectively invokes undefined
    > behaviour,


    Something which can be invoked is still necessarily defined.
    Indepedently of this, your statement means any use of an identifier
    not defined by the C-standard implies that the behaviour of the
    program using the identifier must be undefined, or shorter, that
    programming in C is not possible.

    Follow-up ignored for obvious reasons. Ludcicrous claims about C are
    (at best) on topic in clc.


  4. Re: programi parsing question

    Rainer Weikusat wrote:

    > santosh writes:
    >> fjblurt@yahoo.com wrote:
    >>
    >>> On Aug 6, 5:49 am, CBFalconer wrote:
    >>>> santosh wrote:
    >>>> > CBFalconer wrote:
    >>>> >> fjbl...@yahoo.com wrote:
    >>>>
    >>>> >>> void fooB(void) {
    >>>> >>> int fd = open(...);
    >>>> >>> if (fd < 0) {
    >>>> >>> fail();
    >>>> >>> }
    >>>> >>> }

    >>
    >>
    >>
    >>> Non-c.u.p readers worried about the `open' function may read it as
    >>> an arbitrary function returning `int', which has significant side
    >>> effects, [ ... ]

    >>
    >> Since these side effects have not been specified, nor are derivable
    >> from anything in the C Standard, the function effectively invokes
    >> undefined behaviour,

    >
    > Something which can be invoked is still necessarily defined.
    > Indepedently of this, your statement means any use of an identifier
    > not defined by the C-standard implies that the behaviour of the
    > program using the identifier must be undefined, or shorter, that
    > programming in C is not possible.


    I suppose you didn't not my smiley at the end?

    > Follow-up ignored for obvious reasons. Ludcicrous claims about C are
    > (at best) on topic in clc.


    Hmm, seems my newsreader added followups to c.u.p automatically. Am
    setting followups to clc, since this thread long ago ceased to be
    topical on cup.


  5. Re: programi parsing question

    fjblurt@yahoo.com wrote, On 06/08/08 05:38:
    > Crossposting this to comp.lang.c because it's become relevant.
    >
    > Our story so far, for c.l.c people:
    >
    > There is a discussion about the stylistic advantages and disadvantages
    > of the following two snippets:
    >
    > void foo (void) {
    > int fd;
    > if ((fd = open(...)) < 0) {
    > fail();
    > }
    > }
    >
    > versus
    >
    > void foo (void) {
    > int fd = open(...);
    > if (fd < 0) {
    > fail();
    > }
    > }
    >
    > Phlip prefers the latter, and claims that the former gained popularity
    > because early versions of C did not guarantee the order in which
    > initializations occurred, or had other problems, and therefore
    > initializations in declarations were discouraged.


    I also prefer the latter but cannot comment on the reasons why the
    former is often used. I refer the latter for the following reasons:

    I like initialising on declaration, no chance of using it uninitialised

    I like separating out assignment from test for readability

    This is purely personal preference. It is not something I would normally
    comment on either way when looking at code on comp.lang.c (although if
    providing an alternative piece of code I might use my preference).



    > For an assignment like our example that involves a nontrivial function
    > call, I think most people would not expect to see it in an
    > initializer,


    Well, they would be surprised by some of my code then :-)

    > because oftentimes nontrivial function calls will require
    > more computations to be done first, even though this example happens
    > not to.




    struct vector required_thrust(struct pos mypos) {
    int x = funcky_function();
    int y = clever_stuff();
    int z = get_altitude();
    struct target_vector = calc_relative_pos(mypos,x,y,z)

    /* calculate and return thrust vector */
    }

    The "more computations to be done first" are not always a problem.
    --
    Flash Gordon

  6. Re: programi parsing question

    K-mart Cashier writes:
    >On Aug 5, 7:39 am, Phlip wrote:
    >> K-mart Cashier wrote:
    >> > int main(void)
    >> > {
    >> > int fd;
    >> > struct utmp log;
    >> > char line[UT_LINESIZE + 1];

    >>
    >> > if((fd = open(_PATH_UTMP, O_RDONLY)) < 0){
    >> > fprintf(stderr, "can't open file\n");
    >> > exit(1);
    >> > }

    >>
    >> C literature often shows a penchant for cramming lines together. I would have
    >> gone with:
    >>
    >> struct utmp log = {0};
    >> int fd = open(_PATH_UTMP, O_RDONLY);
    >>
    >> if(fd < 0){
    >> fprintf(stderr, "can't open file\n");
    >> exit(1);
    >> }
    >>
    >> Next, isn't fd well-defined as -1 if open() fails?
    >>
    >> Next, I would pass _PATH_UTMP into the "can't open file" line, to give the user
    >> a clue _what_ file can't open.
    >>
    >> > while(read(fd, &log, sizeof(log)) == sizeof(log)){

    >>
    >> assert(log.ut_name[UT_LINESIZE - 1] == 0);
    >>
    >> > strncpy(line, log.ut_name, UT_NAMESIZE);
    >> > line[UT_LINESIZE] = '\0';
    >> > printf("%s\n", line);
    >> > }

    >>
    >> Does my assertion work? If I had invented this UTMP system, I would enforce a
    >> well-defined '\0' at the end of a line. Sometimes APIs shouldn't do that.
    >>
    >> If this API does not, then my -1 is incorrect, and your +1 is correct. But
    >> couldn't you use
    >>
    >> printf("%*s\n", UT_LINESIZE, log.ut_name);
    >>
    >> to avoid the extra buffer and copy?
    >>
    >> --
    >> Phlip

    >
    >
    >doing something like
    >
    > if((fd = open(_PATH_UTMP, O_RDONLY)) < 0)
    >
    >is a common found in both "The C Programming Language" by K & R and
    >the FreeBSD source code.


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

    Doesn't matter how many times you read it in print, it is still
    bad practice.

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

    It's also good practice to remove side-effects from conditional
    statements, so:

    fd = open(_PATH_UTMP, O_RDONLY, 0);
    if (fd == -1) {
    ... error case
    }

    scott

  7. Re: programi parsing question

    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

  8. Re: programi parsing question

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

    On Aug 6, 8:08 pm, Phlip wrote:
    > 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.


  9. Re: programi parsing question

    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]:
    Try the download section.


  10. Re: programi parsing question

    On Aug 7, 7:10 am, CBFalconer wrote:
    > 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.


  11. Re: programi parsing question

    vippstar@gmail.com wrote:

    > On Aug 7, 7:10 am, CBFalconer wrote:
    >> 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.


  12. Re: programi parsing question

    vippstar@gmail.com writes:
    > On Aug 7, 7:10 am, CBFalconer wrote:
    >> 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_Keith) kst-u@mib.org
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

  13. Re: programi parsing question

    On Aug 7, 11:05 am, santosh wrote:
    > vipps...@gmail.com wrote:
    > > On Aug 7, 7:10 am, CBFalconer wrote:
    > >> 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.


    The standard doesn't define _PATH_UTMP. So how could that code ever
    use it?

  14. Re: programi parsing question

    CBFalconer writes:
    > 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 is supposed to contain a prototype for
    open.

  15. Re: programi parsing question

    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.


  16. Re: programi parsing question

    vippstar@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.

  17. Re: programi parsing question

    On Aug 7, 3:00 pm, Phlip wrote:
    > 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.



    Just don't remove them. Not removing something takes less time than
    removing something.

  18. Re: programi parsing question

    On Aug 7, 3:01 pm, Phlip wrote:
    > 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.



  19. Re: programi parsing question

    Phlip wrote:
    > vippstar@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.


    No, open() is not in ANY C implementation.

    Some useful references about C:

    (C-faq)

    (C99)
    (C99, txt)
    (C-library}
    (GNU docs)


    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]:
    Try the download section.



  20. Re: programi parsing question

    Phlip wrote:
    > 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.


    Among other things, they identify the writer. This enables the
    reader to evaluate the accuracy. It is also easier to leave them
    than to remove them.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]:
    Try the download section.



+ Reply to Thread
Page 4 of 6 FirstFirst ... 2 3 4 5 6 LastLast