Hi Bill, Right, this is what C & C++ system libraries do - they don't touch the pointer variable passed into them.
Examples: realloc(), free() - the pointer is just a variable that tells the library routine where to go to get the memory, but the pointer variable itself should not be changed by the library routine. Rayson ================================= Open Grid Scheduler / Grid Engine http://gridscheduler.sourceforge.net/ Scalable Grid Engine Support Program http://www.scalablelogic.com/ On Fri, May 11, 2012 at 2:28 PM, Bill Bryce <[email protected]> wrote: > Hi Rayson, > > Just to make sure I understand you. Do you mean..."It is more consistent not > to NULL pointers" because C programmers typically know that they should > handle this themselves? > > Regards, > > Bill. > > On 2012-05-11, at 1:34 PM, Rayson Ho wrote: > >> Hi Dan - welcome back! >> >> I also think that it is more consistent to not store NULL a pointer. >> >> That interface is way easier for normal programmers to understand as >> the most common memory allocation routines are malloc() & free(). >> >> Rayson >> >> ================================= >> Open Grid Scheduler / Grid Engine >> http://gridscheduler.sourceforge.net/ >> >> Scalable Grid Engine Support Program >> http://www.scalablelogic.com/ >> >> >> On Fri, May 11, 2012 at 12:47 PM, Daniel Templeton <[email protected]> >> wrote: >>> The main argument against NULLing the pointer is really just principle of >>> least astonishment -- routines in C don't typically do that, especially not >>> in OS libraries. Because there's such a large body of function calls that >>> don't do it, throwing in some that do, can make your code confusing. Did >>> you forget to NULL that pointer, or was it done in the library? NULLing the >>> pointer is more practical, but only if everyone does it that way. I would >>> vote to conform to what the majority of libraries already do. >>> >>> (Yes, I really did just respond to a DRMAA email!) >>> >>> Daniel >>> >>> >>> On 5/11/12 7:51 AM, Daniel Gruber wrote: >>>> >>>> Am 11.05.2012 um 16:27 schrieb Klauck, Stefan: >>>> >>>>> Hi Daniel >>>>> >>>>> >>>>> On May 11, 2012, at 3:17 PM, Daniel Gruber wrote: >>>>> >>>>>> Hi Stefan, >>>>>> >>>>>> Am 11.05.2012 um 14:49 schrieb Klauck, Stefan: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I put my comments below. >>>>>>> >>>>>>> Best regards >>>>>>> Stefan >>>>>>> >>>>>>> >>>>>>> On May 9, 2012, at 4:47 PM, Daniel Gruber wrote: >>>>>>> >>>>>>> For the current public comment period I've following issues: >>>>>>> >>>>>>> 295: drmaa2_list_get(.., int pos) -> pos should be const, the >>>>>>> implementation does not need to change it >>>>>>> - 297 int pos -> same >>>>>>> >>>>>>> The 'const' is not really necessary in the header file since the >>>>>>> implementation file can add the const, too. >>>>>>> >>>>>>> The following example is legal c code: >>>>>>> >>>>>>> //foo.h >>>>>>> void foo(int bar); >>>>>>> >>>>>>> //foo.c >>>>>>> void foo(const int bar); >>>>>>> >>>>>> But you will loose the advantage of pushing a const into the function. >>>>> >>>>> Do you mean that you do not force the implementation to use a const? >>>> >>>> Now I'm lost :) Yes, I want to have the implementations that they are >>>> forced to use the const. Hence I wan't to have this in the spec like the >>>> other consts there. This would allow DRMAA application implementers >>>> to pass a const. Having const in the innermost functions is always a >>>> good idea in order to avoid bad casts. >>>> >>>>>> You could also avoid "bar" in the header (like void foo(int)), but this >>>>>> makes >>>>>> code hard to maintain. >>>>>> Since we have already "const" in the spec, in my >>>>>> eyes it would look in my eyes more consistent. >>>>>> >>>>> I agree. My point was that it is not really necessary to do not allow the >>>>> implementation to change the 'pos' value since the value is not returned >>>>> anyway. >>>>> Nevertheless, the implementation could add the 'const' for optimization… >>>> >>>> You're right, now we can force them to do so ;) >>>> >>>>>>> >>>>>>> - 549 char **substate -> the user has to free it with >>>>>>> "drmaa2_string_free()". Since it is just a string the user might >>>>>>> "forget" >>>>>>> this and use >>>>>>> a "normal" free. >>>>>>> >>>>>>> In the current mock implementation >>>>>>> https://github.com/troeger/drmaav2-mock/blob/master/drmaa2.c >>>>>>> drmaa2_string_free() is a normal free(), so that this would be ok >>>>>>> (except >>>>>>> for the NULL'ing). >>>>>> >>>>>> Indeed. Here it wouldn't be a problem. >>>>>> >>>>>>> Hence I would recommend to have a drmaa2_string type because all other >>>>>>> data (which has to be freed) is drmaa2 typed. >>>>>>> >>>>>>> >>>>>>> Sounds nevertheless reasonable. >>>>>>> >>>>>>> >>>>>>> General question: I would like to have the free functions to NULL the >>>>>>> freed pointers (in order to minimize the risk with >>>>>>> dangling pointers). Hence I would change *all* free methods to accept >>>>>>> ** arguments. Wouldn't this be reasonable? >>>>>>> Why should the user always do the NULL'ing itself? He might forget or >>>>>>> be just lazy and running later in problems, which >>>>>>> we could avoid easily. >>>>>>> >>>>>>> Example: >>>>>>> drmaa2_list_free(&list); >>>>>>> /* some code later, I want to do something with list again, but not >>>>>>> sure if it was freed already */ >>>>>>> ... >>>>>>> if (list == NULL) { >>>>>>> /* oh it was freed already */ >>>>>>> } else { >>>>>>> /* not feed */ >>>>>>> } >>>>>>> >>>>>>> >>>>>>> I had no opinion. Hence I googled the problem. >>>>>>> There are many conversations concerning this topic especially on >>>>>>> stackoverflow >>>>>>> e.g. >>>>>>> http://stackoverflow.com/questions/1879550/should-one-really-set-pointers-to-null-after-freeing-them >>>>>>> . >>>>>>> >>>>>>> Since the "NULL'ing" is controversial, I suggest to do not set the >>>>>>> pointer to NULL within the implementation. >>>>>>> Applications can still implement macros or wrapper functions (for >>>>>>> NULL'ing) to write portable code, in case they want to set freed >>>>>>> pointers to >>>>>>> NULL and rely on that. >>>>>> >>>>>> Can't see any valid argument against, sorry could read the full article >>>>>> in all details. >>>>>> I guess we've to vote :) >>>>> >>>>> You lose the address of the freed pointer. (That's why I would let the >>>>> application developer to decide.) >>>>> >>>>> example: >>>>> >>>>> drmaa2_list list_reference = list; >>>>> drmaa2_list_free(&list); >>>>> if (list == list_reference) // false >>>> >>>> Uhh, wasn't aware of this case (sorry, my mistake I wanted to say >>>> "couldn't read the full article in all details)...). >>>> Is such a reference to an pointer we've really needed in DRMAA apps? I'm >>>> wondering what >>>> would s.o. could do with this reference pointing to some (most likely) bad >>>> memory location. >>>> IMHO using a pointer after freeing is nothing s.o. should do by choice. >>>> Hence immediately after the list_free() the reference (if it is really >>>> needed) should be NULLed >>>> as well. >>>> >>>> Anybody who really wants to do that? Roger? Andre? >>>> >>>> Cheers, >>>> >>>> Daniel >>>> >>>> >>>> >>>>> Even though list and list_refernce are invalid pointers, it is not really >>>>> intuitive that the comparison evaluates to 'false'. >>>>> >>>>> In addition "if (list_reference == NULL)" is still 'false' >>>>> >>>>> >>>>> >>>>> Cheers >>>>> Stefan >>>>> >>>>>> Cheers, >>>>>> >>>>>> Daniel >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Daniel >>>>>>> >>>>>>> >>>>>>> Am 17.04.2012 um 11:16 schrieb Peter Tröger: >>>>>>> >>>>>>> Dear all, >>>>>>> >>>>>>> the DRMAAv2 C binding is now in final draft state. Attached you can >>>>>>> find the annotated and the official version of the specification, as >>>>>>> well as >>>>>>> the raw header file. >>>>>>> >>>>>>> Please provide your final comments on the mailing list until *April >>>>>>> 22nd* (this Sunday). In case, we will set up a conf call for last >>>>>>> discussions. Otherwise, the document will enter the OGF document >>>>>>> process on >>>>>>> next Monday. >>>>>>> >>>>>>> Thanks and best regards, >>>>>>> Peter. >>>>>>> >>>>>>> >>>>>>> >>>>>>> <drmaa-c-finaldraft-annotated.pdf><drmaa-c-finaldraft-official.pdf><drmaa2.h>-- >>>>>>> drmaa-wg mailing list >>>>>>> [email protected]<mailto:[email protected]> >>>>>>> https://www.ogf.org/mailman/listinfo/drmaa-wg >>>>>>> >>>>>>> >>>> -- >>>> drmaa-wg mailing list >>>> [email protected] >>>> https://www.ogf.org/mailman/listinfo/drmaa-wg >>> >>> >>> >>> -- >>> Get Apache Hadoop for the Enterprise: http://www.cloudera.com/downloads/ >>> Follow us @cloudera or http://www.facebook.com/cloudera >>> >>> >>> -- >>> drmaa-wg mailing list >>> [email protected] >>> https://www.ogf.org/mailman/listinfo/drmaa-wg >> -- >> drmaa-wg mailing list >> [email protected] >> https://www.ogf.org/mailman/listinfo/drmaa-wg > > William Bryce | VP of Products > Univa Corporation - 1001 Warrenville Road, Suite 100 Lisle, Il, 65032 USA > Email [email protected] | Mobile: 512.751.8014 | Office: 416.519.2934 > -- drmaa-wg mailing list [email protected] https://www.ogf.org/mailman/listinfo/drmaa-wg
