If we are writing a library with a function that should ultimately return a string of varying size, could be anything from several thousand KB or a few bytes.
Do you prefer if the function returns the string or manipulates a pointer argument to return the string? Or perhaps both?
If it were to return the string then of course it would have to return NULL on failure and perhaps set some global error variable, maybe errno.
But if it were to simply manipulate a pointer argument and put the string in there then it could return integer error codes.
I'm asking what you as C programmers prefer because this is my first real open source project and it will be a programming library put up for public use.
Personally, i think i'd prefer if the function only returned the pointer because in this case it must also take a struct argument.
This is the kind of pointless question i would only dare ask on an anonymous board for fear of humiliation among my cybernets peers.
Name:
Anonymous2007-11-05 16:20
>But if it were to simply manipulate a pointer argument and put the string in there then it could return integer error codes.
EXCEPTIONS, MOTHERFUCKER, DO YOU KNOW HOW TO THROW THEM?
Name:
Anonymous2007-11-05 16:26
>>3
He's choosing to limit himself to C, for what I can only assume are bad reasons. C is great for OS implementation and device drivers, but shit for string processing. Historically, he should be using something like Snobol or Icon; or nowadays Perl is probably the best choice.
Name:
Anonymous2007-11-05 16:38
Actually i'm writing a library in C because there is no such library for that purpose in C right now and i might need one further down the road.
A large part is hobbyism, i'm bored and a nerd so i do this in my free time.
I also have another question about performance though.
Let's say a function is to parse some encoded data and populate a large number of linked lists with information of this data.
Now the first thing i did was allocate memory to the first struct of the list, but it dawned on me that i would have to call malloc for every single piece of information taken from this encoded data. I might end up with a shitload of these structures.
So what i was wondering is if maybe i could allocate an array of these structures, since they're all the same, and still point to them in the linked list. If this works the way i intend it to, then it would decrease the number of calls to malloc.
These lists are not big anyways and they consist mostly of other pointers which will be allocated to so decreasing the number of calls to malloc here would make a difference i think.
Name:
Anonymous2007-11-05 17:16
>>4
You fail C is the ONLY language in existence, period!
>>1
Global error code in straight C?!?! You just want to return null. Also variable strings in C would be moderately worthless, since you pretty much have that anyway if you malloc on the heap. You can just realloc when need be, instead of calling some external function. You'd still need null checking either way, so it wouldn't cut down on any code.
Name:
Anonymous2007-11-05 17:26
>>6
I'm not sure what you mean with the variable strings statement.
Of course i will have to allocate memory, that's the whole point of the function to return a string that can be both small and big, how big is determined inside the function and i will allocate when i need it.
So you mean i should return NULL at errors, that's what i was going for so i think that's the best way really.
Thank you for your input.
Name:
Anonymous2007-11-05 17:53
>>7
I meant most C programmers would probably just use realloc in that situation, and would never rely on an external nonstandard function to in essence do the same exact thing.
Realloc is dynamically grabbing memory from the heap(Watch out trying to define a pointer to the stack and then running realloc), in essence resizing the string foo.
Also NULL is pretty much the standard 'error' for any C function that allocates memory.
Name:
Anonymous2007-11-05 18:00
Clarification: I guess realloc is external, but I just meant something not in the std libraries
Also NULL is pretty much the standard 'error' for any C function that allocates memory.
No it's not, implementations of malloc might return NULL or a unique pointer if an error occurs, else a valid pointer.
same for realloc and calloc.
You may ask "what the fuck?!"
yep.
I'm fairly certain ANSI C requires NULL to be returned on a malloc error. I've not personally seen an implementation that does otherwise, but I don't doubt they exist ;)
I do realize errno is available, and required to be set on failure for the the Unix98 standard, but in practice(At least what I've worked on) this is rarely used. Also I don't think this behavior is defined by ANSI.
Upon successful completion with size not equal to 0, malloc() shall return a pointer to the allocated space. If size is 0, either a null pointer or a unique pointer that can be successfully passed to free() shall be returned. Otherwise, it shall return a null pointer and set errno to indicate the error.
Name:
Anonymous2007-11-05 22:17
but is not wrong since calling malloc(0) should not raise an error condition.
Name:
Anonymous2007-11-06 10:14
ITT OMG OPTIMIZED
Name:
Anonymous2007-11-06 10:51
Yeah i was going to use realloc, of course, i just say malloc because i thought it was implied, sorry. Realloc isn't that far from malloc anyways, i haven't looked at the source of it in my libc but i'm pretty sure it uses malloc when it re-allocates the new pointer. That's besides the point though.
Ok thanks for all your input, i'll go with returning NULL, i've already started writing the function this way already.
I don't think he meant that ALL functions using malloc MUST return NULL, but if it's what programmers prefer then it matches my question.
Name:
Anonymous2007-11-06 12:18
>>11 I do realize errno is available, and required to be set on failure for the the Unix98 standard, but in practice(At least what I've worked on) this is rarely used. Also I don't think this behavior is defined by ANSI.
errno is part of the POSIX standard. Just because it's not part of the standard library doesn't mean you shouldn't use it. Even on non-unix systems errno is easily ported (even with windows).
Also, errno is anything but rarely used (see >>12). Many fundamental libraries such as the BSD sockets library use errno; along with most standard library functions on POSIX-compliant systems.
>>16 errno is part of the POSIX standard. Just because it's not part of the standard library doesn't mean you shouldn't use it. Even on non-unix systems errno is easily ported (even with windows).
It's not you moron.
<errno.h> is a standard header, check 7.1.2 on C99
to quote the c99 standard All identifiers with external linkage in any of the following subclauses (including the future library directions) are always reserved for use as identifiers with external linkage. 154) 154) The list of reserved identifiers with external linkage includes errno, math_errhandling, setjmp and va_end.
Name:
Anonymous2007-11-06 18:55
Depends on the nature of the library, I guess. I'd be more inclined to return an int error code and pass in a pointer to be filled ala the sockets API.