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.Originally Posted by tieske
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.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
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
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.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
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.
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.
Yea, the fact that you think I'm just ranting lost you my interest.Could you please provide the argument instead of just ranting?
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
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 macroMYLIB_ISERROR just checks whether the pointer is within the error area (= the array)
I hope it makes more sense now.
You're not telling me anything new, and my point in post #16 still stands.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
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;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!
I was using "object" in a very generic sense: any entity with state or behaviour.
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).
The 1999 C standard only says this, starting partway through Section 7.5 para 2.
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.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.
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.
