Professional Web Applications Themes

Errno.h and EOK constant - UNIX Programming

Hello, I can't figure out while I can't use the contant EOK even though I included the file <errno.h>. Some DOC on the internet says that EOK should be in errno.h, like here: http://www.qnx.com/developers/docs/momentics621_docs/neutrino/lib_ref/e/errno.html#id7 But some other doc says that it's NOT there, like here: http://www.opengroup.org/onlinepubs/007904975/basedefs/errno.h.html I'm sure it's a subtle difference maybe between Linux and Unix or whatever (gcc version???), but it's very confusing when you are just beginning to code under Linux. Any help would be appreciated, for now I'll use "0" insead of EOK. ------- Guillaume...

  1. #1

    Default Errno.h and EOK constant

    Hello,

    I can't figure out while I can't use the contant EOK even though I included
    the file <errno.h>. Some DOC on the internet says that EOK should be in
    errno.h, like here:

    http://www.qnx.com/developers/docs/momentics621_docs/neutrino/lib_ref/e/errno.html#id7

    But some other doc says that it's NOT there, like here:

    http://www.opengroup.org/onlinepubs/007904975/basedefs/errno.h.html

    I'm sure it's a subtle difference maybe between Linux and Unix or whatever
    (gcc version???), but it's very confusing when you are just beginning to
    code under Linux. Any help would be appreciated, for now I'll use "0" insead
    of EOK.


    -------
    Guillaume


    Guillaume Guest

  2. #2

    Default Re: Errno.h and EOK constant

    Guillaume Métayer wrote:
     

    That's _the_ reference. EOK is not portable and happens only to be
    available as a convenience. If no error occured, there is no need to check
    the errno value (and you shouldn't), so the value EOK is useless.

    Regards,
    Daniel
    Daniel Guest

  3. #3

    Default Re: Errno.h and EOK constant



    "Guillaume Métayer" wrote:
     

    You could always do something like

    #ifndef EOK
    #define EOK <whatever value you want>
    #endif

    (You would want this after all the #includes to avoid trouble).

    You might also note, in case you are using something like this in errno,
    that most Unix systems do not update errno unless there is in fact
    an an error. Thus, for example, Solaris would have no use for EOK.

    Many systems do define something as GO, or OK, or whatever to
    define the value that functions return to their callers in case of no
    error, but there is no value of errno that officially designates this
    condition.

    Speaking only for myself,

    Joe Durusau



    joe Guest

  4. #4

    Default Re: Errno.h and EOK constant


    "Guillaume Métayer" <com> wrote in message
    news:ezK_b.126775$videotron.net...
     

    I'm not sure how you would use this. In every case where it's legal to
    check 'errno', it's not legal for 'errno' to contain EOK. So how do you use
    it? Can you post some code?

    DS



    David Guest

  5. #5

    Default Re: Errno.h and EOK constant

    On Tue, 24 Feb 2004 12:14:39 -0500,
    joe durusau <com> wrote:

     
    >
    >You could always do something like
    >
    >#ifndef EOK
    >#define EOK <whatever value you want>
    >#endif
    >
    >(You would want this after all the #includes to avoid trouble).
    >
    >You might also note, in case you are using something like this in errno,
    >that most Unix systems do not update errno unless there is in fact
    >an an error. Thus, for example, Solaris would have no use for EOK.
    >[/ref]

    On the contrary, normal library functions can and sometimes do modify
    errno without returning an error. Remember that any syscall may set errno
    on unix and not all of these errors will make the library function fail.
    There may also be old unix versions where a library functions returns an
    error without modifying errno.

    There are a few cases where ANSI C prescribes that errno is set to non zero
    if and only if an error occured. These are mostly mathematical functions
    as defined in math.h. For these functions testing errno is the only way
    to detect that an error occurred.


    Villy
    Villy Guest

  6. #6

    Default Re: Errno.h and EOK constant

    "Guillaume Métayer" <com> wrote: 

    That URL is for QNX. QNX is not a Unix OS.
     

    But it does *not* say what you are reading into it! It isn't
    that EOK cannot be there, just that it is not required to be
    there.

    "APPLICATION USAGE

    Additional error numbers may be defined on conforming
    systems; see the System Interfaces volume of
    IEEEStd1003.1-2001."

    If QNX, or any other POSIX conforming OS wishes to have an EOK
    they are allowed to. You as a programmer might want to be very
    leary of using it if portability is a requirement.
     

    First, you are reading QNX standards and then attempting to
    write for Unix... and for Linux in specific. That won't fly.
    Second, if you use EOK, no matter how you define it, in the way
    illustrated for QNX you will have a problem with porting your
    code to Unix. That is because while Unix does not guarantee the
    errno is set to any particular value when a system call
    succeeds, it also does not guarantee that errno is untouched.

    --
    Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
    Ukpeagvik (Barrow, Alaska) com
    Floyd Guest

  7. #7

    Default Re: Errno.h and EOK constant

    Thanks to all,

    Okay, I won't use EOK :-) Some people asked WHY I would use it. Well, it's
    for code readability. I don't think it makes much sens to code like this:

    if (pthread_create(blabla)) {
    // I'm here cuz there's an error!
    }

    Humans will expect functions to return a non zero value when it's
    SUCCESSFUL. So I would rather have something in my code like this:

    if (pthread_create(blabla) != EOK) {
    // I'm here cuz there's an error!
    }

    It's just easier to read, and you don't need to be a Linux/Unix geez to
    understand easily what's going on. :-)



    -----
    Guillaume



    "Floyd Davidson" <com> wrote in message
    news:com... [/ref]
    included 
    >
    >http://www.qnx.com/developers/docs/momentics621_docs/neutrino/lib_ref/e/err[/ref]
    no.html#id7 
    >
    > But it does *not* say what you are reading into it! It isn't
    > that EOK cannot be there, just that it is not required to be
    > there.
    >
    > "APPLICATION USAGE
    >
    > Additional error numbers may be defined on conforming
    > systems; see the System Interfaces volume of
    > IEEE Std 1003.1-2001."
    >
    > If QNX, or any other POSIX conforming OS wishes to have an EOK
    > they are allowed to. You as a programmer might want to be very
    > leary of using it if portability is a requirement.
    > [/ref]
    whatever [/ref]
    insead 
    >
    > First, you are reading QNX standards and then attempting to
    > write for Unix... and for Linux in specific. That won't fly.
    > Second, if you use EOK, no matter how you define it, in the way
    > illustrated for QNX you will have a problem with porting your
    > code to Unix. That is because while Unix does not guarantee the
    > errno is set to any particular value when a system call
    > succeeds, it also does not guarantee that errno is untouched.
    >
    > --
    > Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
    > Ukpeagvik (Barrow, Alaska) com[/ref]


    Guillaume Guest

  8. #8

    Default Re: Errno.h and EOK constant

    In article <XlJ%b.51442$videotron.net>,
    "Guillaume Métayer" <com> wrote:
     

    Most system calls and many library functions return -1 on error, so the
    common coding style is:

    if (function_name(...) == -1) {
    // I'm here cuz there's an error!
    }

    If you don't like exposing this, a popular strategy is to wrap it in a
    macro.

    --
    Barry Margolin, mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    Barry Guest

  9. #9

    Default Re: Errno.h and EOK constant


    "Guillaume Métayer" <com> wrote in message
    news:XlJ%b.51442$videotron.net...

     


    I agree with you personally. I prefer '!=0' on such comparisons.

     


    Except that's wrong. Read the POSIX specification of 'pthread_create'.

     


    It may be easier to read, but it's not portable. The code is only
    correct if EOK is zero. No law requires EOK to be zero. So since your code
    only works with zero, why not put a zero there?

    DS




    David Guest

  10. #10

    Default Re: Errno.h and EOK constant

    "Guillaume Métayer" <com> writes:
     

    Why? Perl programmers, yes, but humans, no :-)
     
     


    And what is the difference with:

    if (pthread_create(blabla) != 0)


    Remember, don't use non booleans as if they are booleans.

    In our corporate C-style, you are not allowed to use non-boolean
    values in if statements without "reducing" them to booleans using
    a comparison.

    The reaons for this is that there are a number of functions which
    return pointers (NULL returns indicates failures) and functions
    which return an error indication (there's are many ways to fail)
    or 0 (there's one way to succeed). By forcing explicit
    comparisions the code becomes more readable[1].


    if (<ptrexpression> != NULL)
    /* success */

    if (<boolean>)
    /* success */

    if (<typical syscall> == 0)
    /* success */

    etc.

    Casper

    [1] Though by far the most redeeming factor of a corporate C-style is that
    it makes it *MUCH* more easier to read other people's code; for all the
    rest it could almost be a random set of rules.
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.
    Casper Guest

  11. #11

    Default Re: Errno.h and EOK constant

    Casper H.S. Dik <com> wrote:
     
     

    Is that enforced by checking with a tool? Some compilers do warn about
    this, but of course gcc can be easily fooled by just adding parentheses.

    (Coding standards that cannot be checked mechanically are arguably not much
    better than no standard at all).
     

    ;-)

    --
    Thomas E. ey
    http://invisible-island.net
    ftp://invisible-island.net
    Thomas Guest

  12. #12

    Default Re: Errno.h and EOK constant


    "Thomas ey" <radix.net> wrote in message
    news:supernews.com...
     

    I could not disagree more. In fact, I'll go as far as to argue that
    coding standards that can be fixed mechanically are not much better than no
    standard at all. Anything that can be checked mechanically can be fixed
    mechanically, so why bother your programmers with wasting valuable human
    time worrying about it?

    Here's an example of the type of coding standard you apparently approve
    of:

    "There must be at least three words of comment for every twenty lines of
    code."

    Here's an example of the type of coding standard I approve of:

    "Comments must be used where it is not readily apparent what the code
    does and must explain what the purpose of the code is."

    Again, your kind of coding standard:

    "Each source module must consist of no more than 2,000 lines."

    And mine:

    "Each source module must contain a logical unit of code. That is, all of
    the code in one module must together perform a common function."

    Which type do you think is more important to follow?

    DS



    David Guest

  13. #13

    Default Re: Errno.h and EOK constant


    Thomas ey <radix.net> writes:
     

    >
    > Is that enforced by checking with a tool? Some compilers do warn about
    > this, but of course gcc can be easily fooled by just adding parentheses.
    >
    > (Coding standards that cannot be checked mechanically are arguably not much
    > better than no standard at all).

    >
    > ;-)[/ref]

    I don't think mechanical checks are well-suited to
    matters of aesthetics. For example, I like to be able
    to do things like the following:

    x = (foo && foo->bar && foo->bar->faz) ? foo->bar->faz->x : NULL;

    I don't think that explicitly comparing pointers
    to NULL would make this more readable.

    -SEan



    Sean Guest

  14. #14

    Default Re: Errno.h and EOK constant

    Thomas ey <radix.net> writes:
     

    Much is, but not all.
     

    Indeed; a lot is mechanically checked and the rest should be caught
    by code reviewers.

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.
    Casper Guest

  15. #15

    Default Re: Errno.h and EOK constant

    "David Schwartz" <com> writes:
     


    The examples you quote are more of a "semantic" standard than a
    "syntactic" standard. Both are important; and mechanically fixing
    source code is a non-starter. "To be able to read the code, you
    must first run it through ``ident''". I don't think so.

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.
    Casper Guest

  16. #16

    Default Re: Errno.h and EOK constant

    David Schwartz <com> wrote:
     
     [/ref]
     

    hmm - what's that term for an argument where someone alleges something
    false to prove a point (you're doing it - apparently underemployed).

    --
    Thomas E. ey
    http://invisible-island.net
    ftp://invisible-island.net
    Thomas Guest

Similar Threads

  1. errno 13
    By Marcia in forum UNIX Programming
    Replies: 5
    Last Post: February 9th, 04:59 AM
  2. subclassing Errno::
    By Joel in forum Ruby
    Replies: 7
    Last Post: December 8th, 08:13 PM
  3. propagating errno from c extensions
    By Ara.T.Howard in forum Ruby
    Replies: 3
    Last Post: December 5th, 08:47 AM
  4. shmdt: errno = 22
    By sharad in forum Informix
    Replies: 1
    Last Post: July 21st, 05:57 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139