Like Tree9Likes

returning an error code from a function that has a pointer return type

This is a discussion on returning an error code from a function that has a pointer return type within the C Programming forums, part of the General Programming Boards category; Originally Posted by tieske Those arguments can be overcome, the array has consecutive elements, hence pointer arithmetic can be used ...

  1. #16
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,302
    Quote Originally Posted by tieske
    Those arguments can be overcome, the array has consecutive elements, hence pointer arithmetic can be used ;
    I believe that using <= or >= to compare pointers that do not point to elements of the same array (or one past the end thereof; or to the same object) results in undefined behaviour.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  2. #17
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,415
    O_o

    That only overcomes one of those arguments and only by changing the rules.

    If you were to add "report a specific error condition" back you would still need a linear scan.

    Of course, you can fix that. Of course, I can tell you how that fix is also broken. We could play that game forever. That's why this is so sickening. It is broken in such a profound way that every attempt to fix it will only change the flavor of its "brokeness".

    This concept of yours is extremely brittle and broken beyond belief because everything you try to fix it just paints the curtains when the foundation is flawed.

    Again, I actually congratulate you on the concept. The concept is broken beyond belief. Willingness to pursue an insane concept is solid win.

    Soma

  3. #18
    Registered User
    Join Date
    Apr 2012
    Posts
    7
    Quote Originally Posted by laserlight View Post
    I believe that using <= or >= to compare pointers that do not point to elements of the same array (or one past the end thereof; or to the same object) results in undefined behaviour.
    That is wat the example does? or am I missing something. As long as all the errorcodes are defined using the same array, it works.

  4. #19
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,302
    Quote Originally Posted by tieske
    That is wat the example does? or am I missing something. As long as all the errorcodes are defined using the same array, it works.
    Well, in that case, why return a pointer? You might as well return an int, since you are not returning a pointer to an object that does not represent an error code, so this whole business about pointers is much ado about nothing. But if you return a pointer to an object that does not represent an error code, then the object may well not be part of this error code array.
    tieske likes this.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #20
    Registered User
    Join Date
    Apr 2012
    Posts
    7
    Quote Originally Posted by phantomotap View Post
    If you were to add "report a specific error condition" back you would still need a linear scan.
    It does, it has a single check to see whether there is an error, and only in the error case you would traverse the possible error codes to find out what exactly went wrong. This is no different than reporting some integer, or even using errno.

    Quote Originally Posted by phantomotap View Post
    That's why this is so sickening. It is broken in such a profound way that every attempt to fix it will only change the flavor of its "brokeness".

    This concept of yours is extremely brittle and broken beyond belief because everything you try to fix it just paints the curtains when the foundation is flawed.

    Again, I actually congratulate you on the concept. The concept is broken beyond belief. Willingness to pursue an insane concept is solid win.
    Could you please provide the argument instead of just ranting? I'm trying to learn why it is brittle and broken, and I do appreciate the input.

  6. #21
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,415
    Could you please provide the argument instead of just ranting?
    Yea, the fact that you think I'm just ranting lost you my interest.

    I may have been ranting, but my every criticism is real.

    Maybe instead of trying to rescue the concept with attempts to correct the code and waving my comments away with "He is a lunatic." you should take the time to reason about what I've said along with your code. While I am a lunatic, I am also very good at what I do.

    Soma

  7. #22
    Registered User
    Join Date
    Apr 2012
    Posts
    7
    Quote Originally Posted by laserlight View Post
    Well, in that case, why return a pointer? You might as well return an int, since you are not returning a pointer to an object that does not represent an error code, so this whole business about pointers is much ado about nothing. But if you return a pointer to an object that does not represent an error code, then the object may well not be part of this error code array.
    A now I get your comment. Maybe I should have been clearer in my initial post. It is very common with functions that return an integer, that an impossible range of outcomes is used as error signals. Consider a 'length' function that determines the length of some object or whatever and returns an int. As length should always be positive (lets assume that for this example), negative values may be returned to signal a problem with the object or input parameters. This is quite common practice.

    My intent was to get a similar behaviour, but in this case with a function that returns a pointer, instead of an int. So the example only shows the error returned, but obviously in non-example code, if there wouldn't be an error, it should return a pointer to a struct, string, object, whatever the function was to return on its 'good-path'.
    So only have a single return value, which encodes both proper return values (good-path) and multiple possible error codes (failure-path) instead of only NULL for an error.

    To be able to do this, the error code pointer may not ever be equal to a possible valid return value. Hence the consecutive array, any pointer within this memory area is an error, any outside is a valid value (presumed the function did what it was supposed to do). The macro
    MYLIB_ISERROR just checks whether the pointer is within the error area (= the array)

    I hope it makes more sense now.

  8. #23
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,302
    You're not telling me anything new, and my point in post #16 still stands.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  9. #24
    Registered User
    Join Date
    Apr 2012
    Posts
    7
    Quote Originally Posted by laserlight View Post
    You're not telling me anything new, and my point in post #16 still stands.
    I (wrongly) assumed pointers to be mere integer values denoting a memory address from 0 to end-of-memory, in byte order. How wrong I am; K&R, 2nd edition, Ch 5, p. 102;
    Quote Originally Posted by Kernighan and Ritchie
    "Pointers may be compared under certain circumstances. If p and q point to members of the same array, then relations like ==, !=, <, >=, etc., work properly. For example,
    p < q
    is true if p points to an earlier member of the array than q does. Any pointer can be meaningfully compared for equality or inequality with zero. But the behavior is undefined for arithmetic or comparisons with pointers that do not point to members of the same array. (There is one exception: the adress of the first element past the end of an array can be used in pointer arithmetic.)
    I would still expect it to work, but it can't be relied upon. So clear point why it can't be used.

    Finally got the (rather important and hence valuable) message, thanks for teaching and for your patience!

  10. #25
    Registered User
    Join Date
    Jun 2005
    Posts
    6,656
    Quote Originally Posted by manasij7479 View Post
    But errno may not be an object...but just an obfuscation..
    I was using "object" in a very generic sense: any entity with state or behaviour.

    Quote Originally Posted by manasij7479 View Post
    afaik. (It can link to a function call like mechanism, which implements the locking code, unless it is local to threads)
    Even if it was a function call, a function cannot protect itself from being called by multiple threads. As I said, I was using the term "object" very generically (not, for example, in a way that a C++ programmer might - this thread is in a C forum, after all).

    Quote Originally Posted by manasij7479 View Post
    My man page says:
    The 1999 C standard only says this, starting partway through Section 7.5 para 2.
    Code:
    and
          errno
    which expands to a modifiable lvalue  that has type int, the value of which is set to a positive error number by several library functions. It is unspecified whether errno is a
    macro or an identifier declared with external linkage. If a macro definition is suppressed in order to access an actual object, or a program defines an identifier with the name
    errno, the behavior is undefined.
    There is no reference to errno being thread-local. Then again, C99 states no requirements related to threads (it assumes a single thread of execution) nor to thread local storage. Given a disagreement between a man page and a standard, I'll argue the standard is correct.

    Multithreading support is actually optional in C11. For that reason, even if you have a compiler that supports C11, it is a fair bet that there would be no requirement that errno be in thread-local storage. That doesn't mean errno cannot be in TLS: it means that your man page is specific to a particular platform.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Sunshine, and read this, this, and this before posting again.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Return from incompatible pointer type
    By aladin in forum C Programming
    Replies: 2
    Last Post: 03-22-2009, 09:58 AM
  2. Replies: 6
    Last Post: 04-09-2006, 05:32 PM
  3. code error[return of function]
    By k4z1nh0 in forum C Programming
    Replies: 5
    Last Post: 03-08-2005, 07:19 PM
  4. error when returning template type~
    By black in forum C++ Programming
    Replies: 5
    Last Post: 06-01-2004, 02:33 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21